2. Authentication and Key Establishment (Needham-Schroeder, Kerberos and KryptoKnight) February 19, 2003 Changho Choi choi@cs.umn.edu

3. Agenda Motivation Basic concept for the authentication and key establishment Needham-Schroeder Kerberos KryptoKnight Summary

4. Motivation Reliable authentication of communicating entities and network users across an insecure network Secure key establishment Protect the privacy and integrity of communication Alice Bob How Securely? Centralized key management and authentication

5. Concepts and Classification Key establishment: a shared secret becomes available to two or more parties, for subsequent cryptographic use. key transport protocol one party creates, and securely transfers it to the other(s). key agreement protocol: key establishment technique in which a shared secret is derived by two (or more) parties key pre-distribution vs. dynamic(session) key establishment Use of trusted servers trusted third party, trusted server, authentication server, key distribution center (KDC), key translation center (KTC) and certification authority (CA).

6. 2-Party Mutual Authentication Protocol (2PAP) Alice Bob 1. N A 2. N B,MAC BA (N A,N B,B) 3. MAC AB (N A,N B ) N A,N B : One time random number (Nonce) MAC AB, MAC BA : Message Authentication Code with a shared key

7. KDC Alice Bob ’ s Server 1. A,B,N A 2. {k,N A,B, {k,A}K B }K A A,B: identities of hosts, KDC: Key Distribution Center N A, N B : nonce K A, K B : host keys shared by KDC and hosts k: session key for the host A and B {} k : Encryption with a key k 3. {k,A}K B Needham-Schroeder 4. {N B }k 5. {N B -1}k

8. Needham-Schroeder Properties Protocol provides A and B with a shared key k with key authentication (4) and (5) provide entity authentication of A to B. If acceptable for A to re-use key k with B, A may securely cache (3) with k To prevent replay of (4), {N A ’} k should be appended to message (3), and (4) should be replaced by {N A ’-1, N B } k allowing A to verify B’s knowledge of k

9. Kerberos Enable network application to securely identify their peers Host A provides its identity by presenting a ticket to host B Tickets are issued by a trusted third party Key Distribution Center (KDC) There is a shared key between KDC and any host Ticket is valid for a finite interval called its lifetime Ticket contains session key, host’s identity and lifetime of the session key

10. Initial ticket exchanging KDC 1. A,B,N A 2. {k,N A,L,B}K A, {k,A,L}K B A,B: identities of hosts N A : nonce, L: Life time K A, K B : host keys shared by KDC and hosts k: session key for the host A and B {k,A,L}K B : Ticket 3. {A,T A,L,B}k, {k,A,L}K B Alice Bob ’ s Server

11. Getting a Service Ticket 1. A,TGS,N A 2. {K A,TGS,N A }K A,{K A,TGS,A,L}K TGS 5. {A A }K A,B, {T A,B }K B TGS 3. B, N A ’, {A,L,TGS,T A }K A,TGS, {K A,TGS,A,L}K TGS 4. {K A,B,N A ’ }K A,TGS, {T A,B }K B A A : A, L, B,T A T A : Timestamp made by A T A,B : K A,B,A, L KDC Alice Bob ’ s Server Usually Co-located

12. Kerberos Properties Since timestamps are used, the hosts must provide both secure and synchronized clocks If initial shared keys are password-derived, protocol is no more secure than secrecy of such password or their resistance to password-guessing attack Lifetime is intended to allow A to re-use the ticket A creates new authenticator with new timestamp and same session key k

13. Needham-Schroeder vs. Kerberos Kerberos lifetime parameter is not present in N-S In N-S, (2) (which is corresponds to Kerberos ticket) is double-encrypted Authentication here employs nonce rather than timestamp Since B has no way of knowing if k is fresh, should k ever be compromised, any party knowing it may both resend message (3) and compute a correct message (5) to impersonate A to B This situation is ameliorated in Kerberos by the lifetime parameter which limits exposure to a fixed time interval

14. KryptoKnight Objective Minimal, flexible and scalable authentication and key distribution for various network settings Basic Concepts and Design Issues Minimal resource Utilization Use hash function instead of encryption Minimize the number of messages Flexible operational scenarios Scalable design Use a nonce instead of time stamp

15. Basic Key Distribution Not secure with respect to key integrity Any intruder can modify the key distribution and cause A to extract a key not issued by the KDC Timeliness of the KDC’s response Alice 1. N A 2. N K, MAC A (N A,N K,KDC)  K a New 3. MAC a (N A,N K ) KDC optional

16. Authenticated Key Distribution 2-Party Authenticated Key Distributiion Protocol(2PAKDP) Braiding KDC’s nonce in flow 2 is hidden Alice NANA MAC A (N A,N K,KDC), E A (MAC A )  N K MAC a (N A,N K ) KDC N K = K a New optional

17. 3-Party Scenarios Assumption Two entities(A and B) want to authenticate with each other A and B have no shared secret There is a mutually-trusted KDC whom they each share a secret

18. A-B-K Pull scenario A is either unable, unauthorized, or unwilling to contact the KDC A BKDC optional

19. K-A-B Push Scenario Provide authentication on the forward flows to the KDC Direct handshake (2PAP) between A and B is no longer needed A B KDC optional

20. Time-Based Push Scenario(K-A-B(t)) Connection between two parties is strictly controlled by servers in highly sensitive communication systems Military system B is not available (i.e., is not on-line) at the time when A contacts the KDC In K-A-B and A-B-K, B need to maintain state – Nb, A’s name, etc K-A-B(t) requires B to start keeping state starting only from flow 3 B has no connection to, or is otherwise unable to contact the KDC (i.e, mobile entity) Hybrid (Partial Clock Synchronization) KDC-> A: Challenge-based, KDC->B: Time-based

21. K-A-B(t) A B KDC

22. Extension for Inter-Domain Protocol

23. Kerberos TGS local A B 5. {A A }K A,B, {T A,B }K B 2. {K A,TGS rem }K A,TGS, {T A,TGS rem }K TGS rem TGS remote 1. {A A }K A,TGS, {T A,TGS }K TGS, TGS rem 3. {A A }K A,TGS rem, {T A,TGS rem }K TGS rem, B 4. {K A,B }K A,TGS rem, {T A,B }K B Alice Remote Server

24. Key Exchange in Kerberos CS.UMN.EDU UMN.EDU EDU MIT.EDU UMD.EDU O(N 2 ) EDU MIT.EDUUMN.EDUUMD.EDU CS.UMN.EDU O(logN)

25. Inter-Domain protocols Kerberos Problem Puts most of the load on the initiating client Client A may be a mobile unit: no connection to its own KDC Client A may have a policy prohibiting it from communicating with the outside without establishing a secure “context” Client B may have a policy requiring it to consult its own KDC first before contacting A’s KDC Assumption Existence of inter-domain keys Keys that secure communication among KDCs in different domains

26. A-B-K inter-domain Protocol (Without Inter-KDC communication) A B KDC2 KDC1

27. With Inter-KDC communication Environments One of hosts (A or B) has no connection to its own KDC Software size at one or both hosts is critical Hide the inter-domain-ness of the protocol The burden and complexity due to inter-domain issues can be isolated in KDCs KDCs can communicate among themselves more efficiently than hosts Protocols: A-B-K-K, K-K-A-B and K-K-A-B(t)

28. A-B-K-K Protocol A B KDC2 KDC1

29. Disadvantages in inter-KDC communication Sacrifice of the KDC’s stateless nature KDC2 has to keep state between flows At least A, B, Kab and Na must be kept Alternatively, KDC2 can “export” the state information Including the state variables in the flow to KDC1 KDC1 then simply echoes them back in its reply

30. Summary Supporting a flexible range of network configurations, avoiding reliance on tightly-synchronized clocks or counters Minimizing message sizes and cryptographic operations Light-weight protocol in terms of resource usage and suitable for low-end devices with limited memory and processing capability

31. References J. Kohl, B. Neuman, and T. Ts’o. The Evolution of the Kerberos Authentication Service. In F. Brazier and D. Johansen, editors, Distributed Open Systems. IEEE Computer Society Press,1994. R. Bird, I. Gopal, A. Herzberg, P. Johnson, S. Kutten, R. Molva, and M. Yung, “The KryptoKnight Famliy of Light-Weight Protocols for Authentication and Key Distribution,” IEEE/ACM Transactions on Networking, vol. 3, no. 1, pp. 31-41, 1995. P. Janson, G. Tsudik, and M. Yung. Scalability and flexibility in authentication services: the KryptoKnight approach. In Proc. of IEEE INFOCOM, pages 725--736, April 1997.