2.5.4.2.1 Client Authentication

This use case describes how a server application authenticates the user identity of the client application before it grants access to its protected resources or services.

Client authentication use case

Figure 22: Client authentication use case

Goal: To verify the identity of the client application.

Context of Use: The user has to access a service on a network that requires verification of client identities.

Direct Actor: The client application.

Primary Actor: The user.

Supporting Actors: AA1, AA2, the server application, Account DB #1, and Account DB #2.

Preconditions:

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

  • The identity of the client application is configured in Account DB #1, and the identity of the server application is configured in Account DB #2.

  • The client application, server application, AA1, and AA2 can communicate with each other.

Minimal Guarantee: When client authentication fails, the client application receives an error message that indicates the reason for the failure.

Success Guarantee: The server application has verified the identity of the client application.

Trigger: The user has to access a protected resource or a service on the server computer that resides in domain2.

Main Success Scenario: Negotiation leads to the use of Kerberos.

  1. The client and server application negotiate, as described in section 2.5.5.2, and agree on Kerberos as the authentication protocol.

  2. The identity of the client application is proven to AA1, as described in section 2.5.5.1.

  3. The client application sends the target server application's identity and the TGT material that was obtained in step 2 to AA1 to request a service ticket for the server application.

  4. AA1 cannot issue the service ticket for the identity of the server application because the server identity is not defined in Account DB #1; therefore, AA1 replies with a referral ticket to AA2, as described in [Referrals].

  5. When the client application receives the referral ticket, the client application locates AA2 and sends the TGS request with the received referral ticket.

  6. AA2 decrypts the referral ticket by using the inter-domain key that is shared between AA1 and AA2, detects that the referral ticket contains a request for a service ticket for the server application, generates the service ticket, and returns it to the client.

Postconditions: The identity of the client application is proven to the server application. Both the client and the server applications have a shared session key for further secure communication.

Extensions: None.