authentication and key establishment (needham-schroeder, kerberos and kryptoknight) february 19,...
TRANSCRIPT
Authentication and Key Establishment(Needham-Schroeder, Kerberos and KryptoKnight)
February 19, 2003
Changho Choi
Agenda
Motivation Basic concept for the authentication and key establishment Needham-Schroeder Kerberos KryptoKnight Summary
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
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).
2-Party Mutual Authentication Protocol(2PAP)
Alice
Bob
1. NA
2. NB,MACBA(NA,NB,B) 3. MACAB(NA,NB)
NA,NB : One time random number (Nonce)MACAB, MACBA: Message Authentication Code with a shared key
KDC
Alice
Bob’sServer
1. A,B,NA2. {k,NA,B, {k,A}KB}KA
A,B: identities of hosts, KDC: Key Distribution CenterNA, NB : nonce
KA, KB: host keys shared by KDC and hostsk: session key for the host A and B{}k: Encryption with a key k
3. {k,A}KB
Needham-Schroeder
4. {NB}k5. {NB-1}k
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), {NA’}k should be appended to message (3),
and (4) should be replaced by {NA’-1, NB }k allowing A to verify B’s knowledge of k
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
Initial ticket exchanging
KDC
1. A,B,NA2. {k,NA,L,B}KA, {k,A,L}KB
A,B: identities of hostsNA: nonce, L: Life time
KA, KB: host keys shared by KDC and hostsk: session key for the host A and B{k,A,L}KB: Ticket
3. {A,TA,L,B}k, {k,A,L}KBAlice
Bob’sServer
Getting a Service Ticket
1. A,TGS,NA
2. {KA,TGS,NA}KA,{KA,TGS,A,L}KTGS
5. {AA}KA,B, {TA,B}KB
TGS
3. B, NA’, {A,L,TGS,TA}KA,TGS,{KA,TGS,A,L}KTGS 4. {KA,B,NA’}KA,TGS ,
{TA,B}KB
AA: A, L, B,TA
TA: Timestamp made by ATA,B: KA,B,A, L
KDC
AliceBob’sServer
UsuallyCo-located
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
Needham-Schroeder vs. Kerberos
Kerberos lifetime parameter is not present in N-S In N-S, (2) (which is corresponds to Kerberos ticket) is do
uble-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
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
Basic Key Distribution
Not secure with respect to key integrity Any intruder can modify the key distribution and cause A to extrac
t a key not issued by the KDC
Timeliness of the KDC’s response
Alice
1. NA
2. NK, MACA(NA,NK,KDC) KaNew
3. MACa(NA,NK)KDC
optional
Authenticated Key Distribution
2-Party Authenticated Key Distributiion Protocol(2PAKDP)
Braiding KDC’s nonce in flow 2 is hidden
Alice
NA
MACA(NA,NK,KDC), EA(MACA)NK
MACa(NA,NK)
KDCNK = Ka
New optional
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
)K,(N Mac),N,(NMac abaaaaab
A-B-K Pull scenario
A is either unable, unauthorized, or unwilling to contact the KDC
A B KDCaNA,N,N ba
abbbabbb
abaaabaa
K )(MacE A),,K,(NMac
,K )(MacE B),,K,(NMac
)B,N,(NMac,N
,K )(MacE B),,K,(NMac
baabb
abaaabaa
)K,(N Mac),K,(NMac abbbabaa
optional
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 BKDC
aN
B),N,(N Mac,N babb
A B),,,(NMac,N ,N baaba
abbbabbb
baab
K )(MacE A),,K,(NMac
,)N,(NMac
abbbabbb
abaaabaa
K )(MacE A),,K,(NMac
,K )(MacE B),,K,(NMac
B),N,(N Mac babb optional
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
abbbabb
abaaabaa
K )(MacE A),,K(TS, MacTS,
,K )(MacE B),,K,(NMac
B),N,(NMac,N baabb
K-A-B(t)
A BKDC B ,Na
abbb
abba
K )(MacE
A),,K(TS, MacTS,,N
)N,(NMac baab
Extension for Inter-Domain Protocol
Kerberos
TGSlocal
A B5. {AA}KA,B, {TA,B}KB
2. {KA,TGSrem}KA,TGS ,
{TA,TGSrem}KTGSrem
TGSremote
1. {AA}KA,TGS, {TA,TGS}KTGS , TGSrem
3. {AA}KA,TGSrem,
{TA,TGSrem}KTGSrem
,
B
4. {KA,B}KA,TGSrem,
{TA,B}KB
AliceRemoteServer
Key Exchange in Kerberos
CS.UMN.EDU
UMN.EDU
EDU
MIT.EDU
UMD.EDU
O(N2)
EDU
MIT.EDU UMN.EDU UMD.EDU
CS.UMN.EDUO(logN)
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 wit
h the outside without establishing a secure “context” Client B may have a policy requiring it to consult its own KDC fir
st before contacting A’s KDC
Assumption Existence of inter-domain keys
Keys that secure communication among KDCs in different domains
)B,N,(N Mac,N
,K )(MacE B),A,,K,(NMac
baabb
ab1212aba12 abbbabbb
ab1212aba12
K )(MacE A),,K,(NMac
,K )(MacE B),A,,K,(NMac
A-B-K inter-domain Protocol(Without Inter-KDC communication)
AB
KDC2
KDC1
aN
)N,(NMac baab
A,N,N ba
ab1212aba12
a
K )(MacE B),A,,K,(NMac
,N B,
abaaabaa K )(MacE B),,K,(NMac
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 h
osts
Protocols: A-B-K-K, K-K-A-B and K-K-A-B(t)
)B,N,(NMac,N
,K )(MacE B),,K,(NMac
baabb
abaaabaa abbbabbb
abaaabaa
K )(MacE A),,K,(NMac
,K )(MacE B),,K,(NMac
A-B-K-K Protocol
AB
KDC2
KDC1
ab1212ab212
abaaabaa
K )(MacE A),B,,K,(NMac
,K)(MacE B),,K ,(NMac
aN
A,N,N ba
B A,,N,N 2a
)N,(NMac baab
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
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
References J. Kohl, B. Neuman, and T. Ts’o. The Evolution of the Kerberos Auth
entication 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.