Kerberos Authentication Model: Details

The Kerberos authentication model relies on a secret-key symmetric encryption scheme (DES in the case of Kerberos IV, DES/IDEA/etc. in the case of Kerberos V) and the concept of dual encryption to provide secure authentication across a possibly insecure network. Authentication tickets are delivered to Kerberos clients encrypted in two keys -- one which both the client user and the ticket granting service know (either the user's password or a session key -- see below) and one which both the ticket-granting service and the target service know.

If a client machine is able to decrypt a ticket encrypted in the user's password, the user of the client may be considered authenticated (since only he and the authentication service know the user's password). If a target service is able to decrypt an encrypted ticket using its own secret key, the service may presume that the user who presented the ticket is authentic, since only the ticket-granting service and the target service have knowledge of the target service's secret key.

This allows authentication to occur under the Kerberos model without any password information passing over a possibly insecure network and without any one system or party in the Kerberized exchange having access to enough information to impersonate any other system or party.

Kerberos authentication can be viewed as a six-step process. Below is our Figure III, again, graphically depicting the steps involved in a typical Kerberized authentication session:


GRAPHIC DETAILS OF THE KERBEROS AUTHENTICATION PROTOCOL

Figure III


In Step 1, the user wishing access to an authenticated target service provides his principal (username) and his password to the client system he is using. Note that the client system has no record of the user's principal *or* password -- it merely accepts a [principal,password] pair provided by the user.

In Step 2, the client system sends a request to the Kerberos Initial Ticketing Service requesting a ticket-granting ticket for the user whose principal it has been given. This request is totally unauthenticated.

In Step 3, the Initial Ticketing Service creates a unique session key (Ksession) for later use during the user's authenticated session and sends back to the client a dual-encrypted ticket-granting ticket and the session key in the form:

{{Ttgs,Ksession}Ktgs,Ksession}Kuser

The client then uses the agreed-upon string_to_key() function to convert the user's password into an encryption key and attempts to decrypt the ticket-granting ticket using that key. If the decryption succeeds, the client can be certain that the user is authentic, and the client records the TGT ({Ttgs,Ksession}Ktgs) for later use.

In Step 4, when the user attempts to use a particular target service, the client sends a service ticket request to the Kerberos ticket granting service. This request is in the form:

{TGT,{request,client-IP,time}Ksession}
(where TGT = {Ttgs,Ksession}Ktgs)

In Step 5, the Kerberos ticket-granting service uses its own secret key (Ktgs) to decrypt the TGT in the request it has received, then uses the session key (Ksession) in that TGT to decrypt the rest of the request. If the ticket-granting service is able to properly decrypt the ticket, it knows:

If the decryption is successful, then, the ticket-granting service accepts the user's authentication, generates a service-session key for later use in encrypting transactions between the client and the target service, and issues a service ticket for the requested target service. This is sent back to the client machine in the form:

{{Tservice,Kservice-session}Kservice,Kservice-session}Ksession

In Step 6, the client decrypts the service ticket it has received using the session key (Ksession) provided to it in Step 3 to yield the service-sesson key (Kservice-session) and an encrypted service ticket ({Tservice,Kservice-session}Kservice).

The client then presents the encrypted service ticket to the target service, which in turn decrypts it using its own secret key (Kservice). If the decryption works, the target service may presume that the user is authentic (since only an authenticated user would have access to a decryptable service key). The client and target service may choose to further secure their later communications by encrypting their conversations in the service-session key issued by the ticket-granting service (Kservice-session), since it is a secret known only to the client and the target service. This latter step, encrypting the authenticated conversation, has the added advantage of allowing the client and server to be certain of one another's identities -- an interloper attempting to sabotage the authenticated conversation would need to know the shared encryption key (Kservice-session) in order to properly encrypt data to inject into the conversation.

Steps 4, 5, and 6 may be repeated by the client in order to allow the user access to other Kerberized services without the user's having to re-enter his principal or password information. Kerberos tickets are, in that sense, a reusable proof of authentication.

For more details about the Kerberos authentication model and for a review of the advantages and weaknesses of the model, click here.

Next Page