AUTHENTICATION AND

KEY DISTRIBUTION

Xiaoou Zhang
Outline
Overview
Authentication Protocols
Design of Authentication Protocols
Needham-Schroeder Protocol
Kerberos Protocol Version V
References

Overview [1]
Authentication is the process of verifying the identity of
an object entity.
Password verification: one-way verification
Two way authentication: both communicating entities
verify each others identity
This type of mutual authentication is important for
communication between autonomous principals under
different administrative authorities in a client/server or
peer-to-peer distributed environment.

Overview [2]
Cryptography is used in support of mechanisms for
authenticating communication between pairs of
principals
If a principle can successfully decrypt a message, he
can infer that the sender of the message possessed the
corresponding encryption key and hence deduce the
identity of the sender if the key is known only to two
parties. Thus if keys are held in private, a successful
decryption authenticates the decrypted message as
coming from a particular sender.
Authentication Protocols [1]

Authentication protocols are all about distribution
and management of secret keys.

Key distribution in a distributed environment is
an implementation of distributed authentication
protocols.

Design of Authentication
Protocols [1]
Many authentication protocols have been proposed
All protocols assume that some secret information is
held initially by each principal.
Authentication is achieved by one principal
demonstrating the other that it holds that secret
information.
All protocols assume that system environment is very
insecure and is open for attack. So any message
received by a principal must have its origin authenticity,
integrity and freshness verified.

Design of Authentication
Protocols [1]
To achieve these goals, most protocols need to
rely on an authentication server.
Capable: Authentication server delivers good-quality
session keys and distribute them to the requesting
principals securely.
Trustworthy: Authentication server maintains a table
containing a name and a secret key for each principle.
The secret key is used only to authenticate client
processes to the authentication server and to transmit
messages securely between client processes and the
authentication server.
Design of Authentication
Protocols [1]
Protocol are divided into two categories to verify
the freshness of a message.

First category uses nonce and challenge/
response handshake to verify freshness.

Second category uses timestamps and assumes
that all machines in distributed system are clock-
synchronized.
Needham-Schroeder Protocol [2]
This original work includes secret-key protocol
and public key protocol

Public-key protocol does not depend on the
existence of authentication server and is hence
more suitable for use in networks with many
independent management domains.

Secret-key protocol provides a solution to
authentication and key distribution based on
an authentication server

Needham-Schroeder Secret-key
Protocol [3]
The protocol is based on the generation
and transmission of ticket by the
authentication server.
A ticket is an encrypted message
containing a secret key for use in
communication between A and B
Needham-Schroeder Secret-key
Protocol
1. A->S : A, B, N
A
A requests S to supply a key for communication with B
2. S->A: {N
A
, B, K
AB
, {A, K
AB
} K
B
} K
A
S returns a message encrypted in As secret key, containing a
newly generated key K
AB
, and a ticket encrypted in Bs secret key

3. A->B: {A, K
AB
} K
B
A sends the ticket to B
4. B->A: {N
B
} K
AB
B decrypts the ticket and uses the new key K
AB
to encrypt another
nonce N
B
5. A->B: {N
B
- 1} K
AB
A demonstrates to B that it was the sender of the previous
message by returning an agreed transformation of N
B
Weakness

If session key between A and B is compromised, and the
ticket to B is recorded, an intruder can impersonate A by
carrying out last 3 steps.

The weakness can be remedied by adding a timestamp
to message3, so that it becomes. A->B: {A, t, K
AB
} K
B
B decrypts this message and checks that t is recent. This
is the solution adopted in Kerberos

Kerberos Protocol V [2]
Based on Needham-Schroeder but uses
timestamps
It is included in the OSF Distributed Computing
Environment (DCE) and in the windows 2000 as
the default authentication service
A Kerberos server is known as a Key
Distribution Centre (KDC). Each KDC has an
authentication service (AS) and a Ticket
Granting service (TGS)
Kerberos Protocol V [2]
Kerberos deals with three kinds of security object:
Ticket: a token issued to a client by the Kerberos ticket-granting
service for presentation to a particular server, verifying that the
sender has recently been authenticated by Kerberos. Tickets
include an expiry time and a newly generated session key for the
use by the client and the server

Authenticator: a token constructed by a client and sent to a
server to prove the identity of the user and the currency of any
communication with a server. It contains clients name and a
timestamp and is encrypted in the appropriate session key

Session key: a secret key generated by Kerberos and issued to
a client for use when communicating with a particular server.

Kerberos Protocol V
Briefly, the client authenticates to AS using a secret key
and receives a ticket from the AS. Later the client can
use this ticket to get additional tickets from TGS for
server.
A Kerberos ticket has a fixed period of validity starting at
time t1 and ending at time t2. A ticket for a client C to
access a serve S takes the form:
{C,S, t1, t2, Kcs} Ks, which we denote as {ticket(C,S)} Ks
The clients name is included in the ticket to avoid
possible use by impostors
Kerberos Protocol V
Step A: obtain Kerberos session key and TGS ticket, once
per login session

1. C->A: C,T, n
Client C requests the Kerberos authentication server A
to supply a ticket for communication with the TGS T

2. A->C: {KcT, n, {ticket(C, T)} KT} Kc
A returns a message containing a ticket encrypted in
its secret key and a session key for C to use with T.



Kerberos Protocol V
To obtain a ticket for any server S, C constructs an
authenticator encrypted in KcT of the form:
{C, t} KcT, which we denote as {auth(C)} KcT

Step B: obtain ticket for a server S, once per client-server
session
3. C->T: {auth(C)}KcT, {ticket(C, T)} KT, S, n
C requests the ticket-granting server T to supply a
ticket for communication with another server S

4. T->C: {Kcs, n, {ticket(C,S)} Ks} KcT
T checks the ticket. If it is valid T generates a new
session key Kcs and returns it with a ticket for S
(encrypted in the servers secret key Ks).
Kerberos Protocol V
Step C: issue a server request with a ticket
5. C->S: {auth(C)} Kcs, {ticket(C, S)} Ks, request, n
C sends the ticket to S with a generated authenticator
for C and a request.

Step D: Authenticate server (optional)
S->C: {n} Kcs

Drawbacks [5]
Single point of failure: It requires continuous
availability of a central server. When the Kerberos
server is down, no one can log in. This can be
mitigated by using multiple Kerberos servers and
fallback authentication mechanisms.
Kerberos requires the clocks of the involved hosts
to be synchronized. The tickets have a time
availability period and if the host clock is not
synchronized with the Kerberos server clock, the
authentication will fail. The default configuration
requires that clock times are no more than 10
minutes apart.
References
[1] Distributed Operating Systems and Algorithms by Randy Chow and
Theodore Johnson, addison-wesley, 1997

[2] DISTRIBUTED SYSTEMS CONCEPTS AND DESIGN by George
Coulouris, Jean Dollimore, Tim Kindberg, addison-wesley, 2001

[3] http://en.wikipedia.org/wiki/Needham-Schroeder_protocol, May 2008

[4] http://web.mit.edu/kerberos/, 2007/10

[5] http://en.wikipedia.org/wiki/Kerberos_(protocol), October 2008