How Does SSP Work in Juniper Networks NSM?

小fish

How Does SSP Work in Juniper Networks NSM?Knowledge Base ID:KB6952Version:2.0Published:07 Oct 2008Updated:07 Oct 2008Categories: Security
　　
　　[size=135%]Summary:

How Does SSP Work in Juniper Networks NSM? 　　
　　[size=135%]Problem or Goal:

NSM Secure communication with NSM
　　
　　[size=135%]Solution:

　　Secure Server Protocol (SSP) is comprised of two types of communication mechanisms in the NetScreen-Security Manager (NSM): machine-to-machine (m2m) and human-to-machine (h2m). The Device Server-to-GUI Server, and Device-to-Device Server use m2m connections, while the GUI-to-GUI Server uses the h2m connections. Both methods utilize RSA public key cryptography, Advanced Encryption Standard (AES) symmetric encryption, and SHA-1 based keyed hashing for authentication.
　　To initiate the m2m key exchange, a client sends its client ID and public key, signed by a one-time password (OTP), to the server. The server uses the same OTP to authenticate the client ID and public key, and responds with a client specific public key signed with the OTP, which the client uses to authenticate the public key.
　　A NetScreen security device can get its OTP in one of two ways. If a device is brand new and configured via NetScreen Rapid Deployment (NSRD), the administrator sets the OTP when the configlet is generated. If an existing device is imported into NSM, the OTP is generated and set by the Device Server during the initial telnet or SSH session at device creation.
　　The client and server then use a cryptographically strong random number generator to generate enough bits for an AES symmetric key and a Hashed Message Authentication Code (HMAC) key. These bits are then encrypted using their respective private keys, and exchanged with one another, and both client and server XOR their own bits with the received bits to produce the actual keys. These are used to encrypt and sign all subsequent messages.

　　Human-to-machine authentication is one-way; the client verifies the server's authenticity before encryption is established. After the encryption is established, the client can use the tunnel to pass login credentials, which can be authenticated locally or externally via a RADIUS server.
　　When a client attempts to connect to the server, a connection request is sent to the server. The server responds with its master public key, a 2048-bit RSA key used for all h2m communications, and a 32-bit control code. The user is presented with an MD5 fingerprint of this public key to compare to the fingerprint displayed at the time of the server installation. If this fingerprint matches, the public key is stored and the server is authenticated.
　　Once the client has authenticated the server, it responds with a message containing the control code, a symmetric key, and an HMAC key, which is encrypted with the public key from the server. The server checks the 32-bit control code to verify the authenticity of the packet, then stores the HMAC key and symmetric key, and responds with a hash of the decrypted message. From this point on, the client and server will use the symmetric key and HMAC for all communication.



　　
　　
　　[size=135%]Purpose:

Troubleshooting