Return to the index of lecture notes
April 13, 2010 (Lecture 23)

Needham-Schroeder Authentication

The first major paper discussing mutual authentication was publsihed in 1978 by Needham and Schroeder. This proposed protocol uses a private key known to the owner and also to a trusted authentication server. The figure and sicussion below explain the protocol:

Steps in the protocol:

  1. Ticket Request: <A, B, NonceA>

    The intiator begins the authentication process by requesting a ticket from the trusted server. The ticket is going to be given to the other host, much like at the movie theatre, as a form of proof-of-identity. This request contains the name of the intiating client, the name of the target host, and a nonce. A nonce is basically a random number that is used to demonstrate the freshness of a request. The encrpyted reply will contain the same nonce to indicate that the reply is in reponse to the recent request. This deters playback attacks.

  2. Ticket Reply: <NA, B, KAB, {KAB, A}KB> KA

    In response to the inital request, the trusted host is going to generate a shared key, KAB that is to be used to encrpyt communication between the other two systems. This shared secret, as well as the ticket are the two critical components of the reply. Additionally, the nonce is included, to show freshness, as is the server name. The entire messaeg is encrpyted using the client's private key to esnure that no one else can read it.

    The ticket contains the same shared secret, as well as the name of the initiating client, encrypted with the other client's secret. This ticket will be used to communicate the shared secret to the other host. BUt, since it is encrypted with the other host's private key, no one can decrypt it to alter it.

  3. Auth Request: <{KAB,A}KB>

    After getting and decrpyting the reply from the authentication service, the client sends the ticket to the other system.

  4. Challenge: <{NB}KAB>

    After receiving the ticket the other side then generates a nonce, encrypts it using the shared key, and sends it back to the initiator.

  5. Challenge Reply: <{NB-1}KAB>

    By decrpyting the nonce, altering it in a predefined way, and sending it back, the initiator shows that it knows the shared key needed to decrpyt the nonce. This proves its identity. The response is also sent encrpyted using the shared key. Encrpyting the response decreases the likelihood of a plain-text style correlation attack, against the prior challenge.

Kerberos Authentication (Version 5)

Many of you may be somewhat familiar with the Kerberos Authentication used to access services on the CMU network. You use kerberos to prove your identity to the services that you use, such as telnet, rlogin, ftp, &c. It also provides you an assurance that the service is actually the service that you expect.

This protocol is based on the Needham Schroder protocol discussed above. It strengthens the original protocol by adding a nonce to the message which communicates the ticket between the two regular systems (not the system with all of the private secrets). This prevents a replay attack. It also pays much more attention to time. Instead of issuing what amounts to a permanent ticket, all tickets expire. It is also possible to request a ticket that is not immediately valid, making reservations possible. Whereas the Needham-Schroeder protocol was designed for peer-to-peer mutual authentication, Kerberos was designed for client-server mutual authentication.

The first step is to contact the Authentication Service (AS) of the Key Distribution Centre (KDC) and obtain what is called a Ticket-Granting Ticket. In general a ticket is a temporary device that allows a specific user access to a specific service over a specific period of time. The ticket-granting ticket is a special ticket that will allow the client to access the Ticket Granting Service (TGS). The TGS in turn issues tickets valid for specific services on specifc servers, e.x. ftp, telnet, &c.

Each user or service, known as a principle, has a secret, such as a DES encrypted password. The secrets of all principles are known to the AS. The secrets of all services are known to the TGS.

(1) AS_REQUEST

The first step in accessing a service that requires Kerberos authentication is to obtain a ticket-granting ticket. To do this, the client sends a plain-text message to the AS:

<client id, KDC id, requested ticket expiration, nonce1>

(2) AS_REPLY

The AS then creates a new secret, Kc,TGS to be shared between the client and the TGS. It then encrypts this secret along with the nonce using the user's private key, Kc. This is then sent along a ticket for use by the client at the TSC, ticketc, tgs. This ticket is encrypted using the TGS's private key, KTGS. The AS can encrpyt these messages using these private secrets, because it knows all of the secrets.

<{Kc, none1}Kc,TGS, {ticketc,tgs}KTGS>
Once the client has the reply, it can decrpyt the first part of the message and inspect the nonce. This nonce makes it a little more difficult for a replay attack to occur, but in this capacity it is weak, since it is sent in plain-text the first time.

The client also knows the shared secret that will be used to de/crpyt messages exchanged with the TGS. It has ticket to prevent to the TGS. This ticket was encrpyted b the AS using the TGS's private key -- the client can neither read it, nor alter it -- just present it.

The tickets contain the following information:

ticketx,y = {x, y, beginning valid time, expiration time, Kx,y}

The ticket granting ticket is normally valid for about 8 hours.

(3) TGS_REQUEST

The TGS request asks the TGS for a ticket to communicate with a a particular service.

<{authc}Kc, TGS, {ticketc, TGS}KTGS, service, nonce2>

The TGS will be able to decrypt both the ticket using its private key and will know that it has not been forged, since only it and the AS know its private secret.

{authc} is an authenticator. It just contians the name of the sender and a timestamp. It is this timestamp that can cause the "Time Out Of Bounds" errors while trying to get a ticket granting ticket. The authenticator is only valid within a 5 minute window of the timestamp...+/- 2.5 minutes. Again, thsi is a guard against a replay attack.

(4) TS_REPLY

The reply to the client will contain the requested ticket -- this time encrypted with the service's private secret, to prevent forgery by clients. As before, the ticket contains Kc,service.

Another component of the message has two fields: Kc,service and the nonce that was used for the request. This component is encrypted using Kc, TGS. The client decrpyts it, verifies the nonce, and learns the secret that it will use to communicate with the service.

<{Kc,service, nonce2}Kc, TGS, {ticketc, service}Kservice >

(5) APP_REQ

Much as before, the application presents the encrypted ticket to the service, as well as a request and a nonce.

<{authc}Kc,service, {ticketc, service}Kservice, request, nonce3>

(6) APP_REPLY

As well as the reply to the request, the service sends back the nonce that it received with the request, encrpted using the shared secret. This assures the client that the request was answered by the appropriate service, not an imposter.

<{nonce3}Kc,service, response>