z/OS Security Server RACF Security Administrator's Guide
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


The secure handshake

z/OS Security Server RACF Security Administrator's Guide
SA23-2289-00

A network protocol where a z/OS® application is playing the role of the client or the server is shown in Figure 1. Each party, both client and server, has its own certificate, a matching private key, and a list of trusted certificate-authority certificates. When the client needs to authenticate itself to the server to be able to perform a transaction, both the server and client need to verify one another. The protocol for a secure handshake for mutual verification begins with the parties exchanging certificates. Each party then separately validates the other's certificate to make sure that its signature is valid, that the subject name in the certificate is correct, and that the certificate originated from a trusted certificate authority. If successful, each party must prove to the other that it owns the private key that matches its public key certificate. This step establishes proof of possession and can be accomplished by having each party sign a known unique value, such as a hash of the message traffic between the two parties. If each signature can be validated using the associated public key, the proofs are successful. The final step in this handshake is for one of the parties to generate a random symmetric key, encrypt it using the other party's public key, and send it to the other party. This random symmetric key can then be used to encrypt the data for the remainder of the session. Once the secure handshake is complete, secure transactions can be safely handled in the z/OS environment between this client and server.
Figure 1. A high-level view of a secure z/OS handshake using a public key network protocolA high-level view of a secure z/OS handshake using a public key network protocol

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014