|
|
| Previous | Table of Contents | Next |
The Ticket Granting Service exchange between a client and the Kerberos Ticket Granting Server is initiated by a client when it wants to obtain authentication credentials for a given server. The server can be local or registered in a remote realm. It also is initiated when the client wants to renew or validate an existing ticket or obtain a proxy ticket.
The client must already have acquired a ticket for the Ticket Granting Service using the Authentication Server exchange. The Ticket Granting Ticket usually is obtained when a client initially authenticates to the system, such as when a user logs in. The message format for the Ticket Granting Service exchange is almost identical to that for the Authentication Server exchange. The primary difference is that encryption and decryption in the Ticket Granting Service exchange does not take place under the client’s key. Instead, the session key from the Ticket Granting Ticket or renewable ticket, or subsession key from an Authenticator is used. As with all application servers, expired tickets are not accepted by the Ticket Granting Service. After a renewable or Ticket Granting Ticket expires, the client must use a separate exchange to obtain valid tickets.
Note: The exchange consists of two messages: KRB_TGS_REQ from the client to Kerberos, and KRB_TGS_REP or KRB_ERROR in reply.
The KRB_TGS_REQ message includes information that authenticates the client, plus a request for credentials. The authentication information consists of the authentication header (KRB_AP_REQ), which includes the client’s previously obtained ticket-granting, renewable, or invalid ticket. In the Ticket Granting Ticket and proxy cases, the request can include one or more of the following:
The Ticket Granting Service reply ( KRB_TGS_REP) contains the requested credentials, encrypted in the session key from the Ticket Granting Ticket or renewable ticket, or if present, in the subsession key from the Authenticator (part of the authentication header). The KRB_ERROR message contains an error code and text that explains what went awry. The KRB_ERROR message is not encrypted. The KRB_TGS_REP message contains information that can be used to detect replays and associate it with the message to which it replies. The KRB_ERROR message also contains information that can be used to associate it with the message to which it replies. The lack of encryption in the KRB_ERROR message, however, precludes the capability to detect replays or fabrications of such messages.
Generation of KRB_TGS_REQ Message
Before sending a request to the Ticket Granting Service, the client must determine in which realm the application server is registered, using one of several ways:
If the realm to be used is obtained from a nameserver that is not authenticated, the danger of being spoofed becomes quite real. This might result in the use of a realm that has been compromised, and would result in an attacker’s ability to compromise the authentication of the application server to the client.
Note: For more information on spoofing, see Chapter 5, “IP Spoofing and Sniffing.”
If the client does not already possess a Ticket Granting Ticket for the appropriate realm, then one must be obtained. This is first attempted by requesting a Ticket Granting Ticket for the destination realm from the local Kerberos server. The Kerberos server may return a Ticket Granting Ticket for the desired realm.
Alternatively, the Kerberos server may return a Ticket Granting Ticket for a realm that is further along the standard hierarchical path to the desired realm. In this case, the client must repeat this step using a Kerberos server in the realm specified in the returned Ticket Granting Ticket. If neither is returned, then the request must be retried using a Kerberos server for a realm higher in the hierarchy. This request requires a Ticket Granting Ticket for the higher realm that must be obtained by recursively applying these directions.
In the sample company, if a user in PROJECTX.RESEARCH.ABC.COM wants to use services in PROJECTX.PAYROLL.ABC.COM, the software asks the local server at PROJECTX.RESEARCH.ABC.COM for credentials. If they are not forthcoming directly the server will return credentials for RESEARCH.ABC.COM. In turn, RESEARCH will return credentials for ABC.COM, which will return credentials for PAYROLL.ABC.COM. Finally he will get credentials for PROJECTX.RESEARCH.ABC.COM. Luckily for the user, this five-step process will all take place automatically.
After the client obtains a Ticket Granting Ticket for the appropriate realm, it determines which Kerberos servers serve that realm and contacts one. The list could be obtained through a configuration file or network service. As long as the secret keys exchanged by realms are kept secret, only denial of service can result from a false Kerberos server.
As in the Authentication Server exchange, the client may specify a number of options in the KRB_TGS_REQ message. The client prepares the KRB_TGS_REQ message, providing an authentication header as an element of the padata field, and including the same fields as used in the KRB_AS_REQ message along with several optional fields: the enc-authorization-data field for application server use and additional tickets required by some options.
In preparing the authentication header, the client can select a subsession key under which the response from the Kerberos server will be encrypted. If the client selects a subsession key, care must be taken to ensure the randomness of the selected subsession key. If the subsession key is not specified, the session key from the Ticket Granting Ticket is used. If the enc-authorization-data is present, it must be encrypted in the subsession key, if present, from the authenticator portion of the authentication header, or if not present, in the session key from the Ticket Granting Ticket.
After the message is prepared, it is sent to a Kerberos server for the destination realm.
| Previous | Table of Contents | Next |