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 other’s 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 A->S : A, B, NA A requests S to supply a key for communication with B S->A: {NA, B, KAB, {A, KAB} KB } KA S returns a message encrypted in A’s secret key, containing a newly generated key KAB, and a ticket encrypted in B’s secret key A->B: {A, KAB} KB A sends the ticket to B B->A: {NB} KAB B decrypts the ticket and uses the new key KAB to encrypt another nonce NB A->B: {NB - 1} KAB A demonstrates to B that it was the sender of the previous message by returning an agreed transformation of NB

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, KAB} KB 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 client’s 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 client’s 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 C->A: C,T, n Client C requests the Kerberos authentication server A to supply a ticket for communication with the TGS T 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 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 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 server’s secret key Ks).

Kerberos Protocol V Step C: issue a server request with a ticket 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