Authentication
Authentication |
|
The Kerberos protocol is comprised of three subprotocols. The subprotocol in which the KDC gives the client a logon session key and a TGT is known as the Authentication Service (AS) Exchange. The subprotocol in which the KDC distributes a service session key and a session ticket for the service is known as the Ticket-Granting Service (TGS) Exchange. The subprotocol in which the client presents the session ticket for admission to a service is called the Client/Server (CS) Exchange.
To see how the three subprotocols work together, let's look at how Alice, a user at a workstation, gets access to Bob, a service on the network.
Alice begins by logging on to the network. She types her logon name and her password. The Kerberos client running on Alice's workstation converts her password to an encryption key and saves the result in its credentials cache.
The client then sends the KDC's authentication service a Kerberos Authentication Service Request (KRB_AS_REQ). The first part of this message identifies the user, Alice, and the service for which she is requesting credentials, the ticket-granting service, as illustrated in Figure 11.5. The second part of the message contains preauthentication data that proves Alice knows the password. This data is usually a timestamp encrypted with Alice's long-term key, although the protocol permits other forms of preauthentication data.
Figure 11.5 AS Exchange
When the KDC receives KRB_AS_REQ, it looks up the user, Alice, in its database, gets her long-term key, decrypts the preauthentication data, and evaluates the timestamp inside. If the timestamp passes the test, the KDC can be assured that the preauthentication data was encrypted with Alice's long-term key and thus that the client is genuine.
After it has verified Alice's identity, the KDC creates credentials that the Kerberos client on her workstation can present to the ticket-granting service. First, the KDC invents a logon session key and encrypts a copy of it with Alice's long-term key. Second, it embeds another copy of the logon session key in a TGT, along with other information about Alice, such as her authorization data. The KDC encrypts the TGT with its own long-term key. Finally, it sends these credentials back to the client in a Kerberos Authentication Service Reply (KRB_AS_REP).
When the client receives the reply, it uses the key derived from Alice's password to decrypt her logon session key and stores the key in its credentials cache. Then the client extracts the TGT from the message and stores that in its credentials cache as well.
The Kerberos client on Alice's workstation requests credentials for the service, Bob, by sending a Kerberos Ticket-Granting Service Request (KRB_TGS_REQ), as illustrated in Figure 11.6. This message includes the user's name, an authenticator encrypted with the user's logon session key, the TGT obtained in the AS Exchange, and the name of the service for which the user wants a ticket.
Figure 11.6 TGS Exchange
When the KDC receives KRB_TGS_REQ, it decrypts the TGT with its secret key and extracts Alice's logon session key. The KDC then uses the logon session key to decrypt the authenticator and evaluates it. If the authenticator passes the test, the KDC extracts Alice's authorization data from the TGT and invents a session key for the client, Alice, to share with the service, Bob. The KDC encrypts one copy of this session key with Alice's logon session key. It embeds another copy of the session key in a ticket, along with Alice's authorization data, and encrypts the ticket with Bob's long-term key. The KDC then sends these credentials back to the client in a Kerberos Ticket-Granting Service Reply (KRB_TGS_REP).
When the client receives the reply, it uses Alice's logon session key to decrypt the session key to use with the service, and stores the key in its credentials cache. Then it extracts the ticket to the service and stores that in its cache.
The Kerberos client on Alice's workstation requests service from Bob by sending Bob a Kerberos Application Request (KRB_AP_REQ), as illustrated in Figure 11.7. This message contains an authenticator encrypted with the session key for the service, the ticket obtained in the TGS Exchange, and a flag indicating whether the client wants mutual authentication. (The Kerberos protocol can provide mutual authentication but does not require it. In Windows 2000, clients always ask for mutual authentication. Clients using other implementations of the protocol might not.)
Figure 11.7 CS Exchange
The service, Bob, receives KRB_AP_REQ, decrypts the ticket, and extracts Alice's authorization data and the session key. Bob uses the session key to decrypt Alice's authenticator and then evaluates the timestamp inside. If the authenticator passes the test, Bob looks for a mutual authentication flag in the client's request. If the flag is set, he uses the session key to encrypt the time from Alice's authenticator and returns the result in a Kerberos Application Reply (KRB_AP_REP).
When the client on Alice's workstation receives KRB_AP_REP, it decrypts Bob's authenticator with the session key it shares with Bob and compares the time returned by the service with the time in the client's original authenticator. If the times match, the client knows that the service is genuine, and the connection proceeds. During the connection, the session key can be used to encrypt application data, or the client and server can share another key for this purpose.
