184.108.40.206.3 Mutual Authentication
This use case describes how a client application and a server application authenticate each other before they establish secure communication.
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.
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
The identity of the client application is authenticated to the server application as described in the main or alternative scenarios of section 220.127.116.11.1, and the client application requests the server application to prove its identity to the client application.
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
The client application asks the server application to establish a secure session.
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.
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.
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.