Security Protocols with Conventional Cryptography - A Classical Introduction to Cryptography: Applications for Communications Security - page 142

AS Client Server

request C to S , N 1
←−−−−−−−−−−−−−−−−−−− pick N 1

C K C ( K , I S , N 1 , C K S ( K , I C ))
−−−−−−−−−−−−−−−−−−−→ pick K

C K S ( K , I C )
−−−−−−−−−−−−−−−−−−−→
C K ( N 2 )
←−−−−−−−−−−−−−−−−−−− pick N 2

)
−−−−−−−−−−−−−−−−−−−→

C K ( N 2 + 1

Figure 5.3. The Needham-Schroeder authentication protocol.

it is encrypted with K S . (Nobody else should be able to encrypt with this key, so this
seemingly suggests that symmetric encryption is used to provide authentication here.)
So S is sure that C requested the ticket to AS, and that AS generated K for both of
them.

This protocol, made in 1978, is important for historical reasons. It suffers, however,
from the following drawback, and it is no longer recommended. The problem here is
that when K gets leaked to an adversary because of a careless user, she can replay the
ticket message C K S ( K I C ) and thus impersonate C to S. The real problem is that S has

no means to be ensured that K is fresh. Actually, this protocol was originally aimed at
protecting against network outsiders. But the real problem comes from careless insiders.
Several improvements of this protocol have been proposed, including the protocol which
is used in Kerberos.

,

5.4.2 Kerberos

Kerberos is an improvement of the Needham-Schroeder authentication protocol. Two
versions are currently well spread: Kerberos Version 4 and Kerberos Version 5. The
latter was adopted as the Internet standard RFC 1510 (Ref. [105]). While the basic
Kerberos protocol works as depicted in Fig. 5.4, the complete protocol works as follows.
When a client wants to authenticate to a given server, the protocol proceeds as follows
(see Fig. 5.5).

1. The client sends a request to the authentication server (AS), also called the
Kerberos server.
2. The AS sends a credential—encrypted with the secret key of the client—to
the client, together with a grant —encrypted with the secret key of the TGS.
The TGS is the ticket granting server who issues short-term tickets. Both the
credential and the grant include one selected mid-term key K 0 , which is assumed
to be fresh, and a timestamp. This key is to be shared by the client and the TGS
only.
3. The client sends a request to the TGS with the grant.
4. The TGS sends a credential—encrypted with the secret key of the client—to
the client, together with a ticket —encrypted with the secret key of the server.