Share via

2.5.4.1.3 Mutual Authentication

  • Article

This use case describes how a client application and a server application authenticate each other before they establish secure communication.

Mutual authentication use case

Figure 19: Mutual authentication use case

Goal: To authenticate the identities of the client and server application to each other.

Context of Use: The client and the server application have to establish a secure session.

Direct Actor: The client application.

Primary Actor: The user.

Supporting Actors: The AA, the server application, and the account DB.

Preconditions:

  • The identities of the client application and the server application are configured in the account DB.

  • The client application, the server application, and the AA can communicate with each other.

  • The user that started the client application is logged on to the client computer.

Minimal Guarantees: If client authentication fails, the client application receives an error message that indicates the reason for the failure. If server authentication fails, the server application receives an error message that indicates the reason for the failure.

Success Guarantee: The identities of the client and the server application are authenticated to each other.

Trigger: The user has to securely access the protected resources or services of the server application.

Main Success Scenario: Negotiation leads to Kerberos

  1. The identity of the client application is authenticated to the server application as described in the main or alternative scenarios of section 2.5.4.1.1, and the client application requests the server application to prove its identity to the client application.

  2. The server application returns the authenticator. It includes the client's time stamp ([RFC4120] section 3.2.4), which is encrypted with an agreed-on session key.

  3. The client application verifies the server application identity by decrypting the authenticator with the session key. If the verification succeeds, the server application is authenticated.

Alternative Scenario: Mutual authentication by using SSL/TLS

  1. The client application asks the server application to establish a secure session.

  2. The server application sends an X.509 certificate and a nonce to the client application.

  3. By using PKI services, the client application verifies the validity, the issuing authority, and the public key of the certificate and confirms that the DNS name in the certificate matches the DNS name of the server. The client application signs the server's nonce with the user's private key, generates a premaster secret, encrypts it with the public key of the server's X.509 certificate, and sends both the signed nonce and the encrypted premaster secret to the server, along with its X.509 certificate.

  4. By using PKI services, the server application verifies the validity, the issuing authority, and the public key of the certificate and confirms the signature on its nonce. If the signature verification succeeds, then the identity of the user is authenticated. The server application then decrypts the premaster key with the private key that is associated with its certificate, constructs a symmetric session key from the premaster secret and signs all of the previous messages with it, and sends the signature to the client.

  5. The client checks the signature. If the signature verification succeeds, then the identity of the server application is authenticated.

Postcondition: Both the client and the server application have a shared session key with which to establish a secure session.

Extensions: None.