Download presentation
Presentation is loading. Please wait.
Published bySandra Day Modified over 9 years ago
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.
Similar presentations
© 2025 SlidePlayer.com Inc.
All rights reserved.