Transcript KryptoKinght Protocol for Authentication and Key Distribution

Authentication and Key Establishment
(Needham-Schroeder, Kerberos and KryptoKnight)
February 19, 2003
Changho Choi
[email protected]
Agenda






Motivation
Basic concept for the authentication and key establishment
Needham-Schroeder
Kerberos
KryptoKnight
Summary
Motivation
How Securely?
Alice



Bob
Reliable authentication of communicating entities and
network users across an insecure network
Secure key establishment
Protect the privacy and integrity of communication
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


key agreement protocol: key establishment technique in which



one party creates, and securely transfers it to the other(s).
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)
1. NA
Alice
2. NB,MACBA(NA,NB,B)
3. MACAB(NA,NB)
Bob
NA,NB : One time random number (Nonce)
MACAB, MACBA: Message Authentication Code with
a shared key
Needham-Schroeder
KDC
1. A,B,NA
Alice
2. {k,NA,B, {k,A}KB}KA
3. {k,A}KB
4. {NB}k
5. {NB-1}k
Bob’s
Server
A,B: identities of hosts,
KDC: Key Distribution Center
NA, NB : nonce
KA, KB: host keys shared by KDC and hosts
k: session key for the host A and B
{}k: Encryption with a key 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,NA
2. {k,NA,L,B}KA, {k,A,L}KB
3. {A,TA,L,B}k, {k,A,L}KB
Alice
A,B: identities of hosts
NA: nonce,
L: Life time
KA, KB: host keys shared by KDC and hosts
k: session key for the host A and B
{k,A,L}KB: Ticket
Bob’s
Server
Getting a Service Ticket
KDC
Usually
Co-located
2. {KA,TGS,NA}KA,{KA,TGS,A,L}KTGS
1. A,TGS,NA
5. {AA}KA,B, {TA,B}KB
3. B, NA’,
Alice
{A,L,TGS,TA}KA,TGS,
{KA,TGS,A,L}KTGS
4. {KA,B,NA’}KA,TGS ,
{TA,B}KB
TGS
Bob’s
Server
AA: A, L, B,TA
TA: Timestamp made by A
TA,B: KA,B,A, L
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
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
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
1. NA
2. NK, MACA(NA,NK,KDC) KaNew
Alice

optional
KDC
Not secure with respect to key integrity


3. MACa(NA,NK)
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
Authenticated Key Distribution

2-Party Authenticated Key Distributiion Protocol(2PAKDP)
NA
MACA(NA,NK,KDC), EA(MACA)NK
MACa(NA,NK)

Alice
Braiding

NK = KaNew
KDC’s nonce in flow 2 is hidden
optional
KDC
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
A-B-K Pull scenario

A is either unable, unauthorized, or unwilling to contact the
KDC
A
B
Na
Mac a (N a , K ab , B), E a (Mac
N b , Mac
Mac
ab
ab
a
)  K ab ,
KDC
Na ,Nb ,A
Mac a (N a , K ab , B), E a (Mac
a
)  K ab ,
Mac b (N b , K ab , A), E b (Mac
b
)  K ab
(N a , N b , B )
(N a , N a ), Mac a (N a , K ab )
Mac a (N a , K ab ), Mac b (N b , K ab )
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
Na
KDC
A
N a , N b , Mac a (N a , b , B), A
Mac a (N a , K ab , B), E a (Mac
a
)  K ab ,
Mac b (N b , K ab , A), E b (Mac
b
)  K ab
Mac
ab
(N a , N b ) ,
Mac b (N b , K ab , A), E b (Mac
 b  Mac b (N a , N b , B)
B
N b , Mac b (N a , N b , B)
optional
b
)  K ab
Time-Based Push Scenario(K-A-B(t))

Connection between two parties is strictly controlled by servers in
highly sensitive communication systems


B is not available (i.e., is not on-line) at the time when A contacts the
KDC




Military system
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
K-A-B(t)
KDC
Na ,B
Mac a (N a , K ab , B), E a (Mac
a
)  K ab ,
TS, Mac b (TS, K ab , A), E b (Mac
b
)  K ab
A
B
N a ,TS, Mac b (TS, K ab , A),
E b (Mac
b
N b , Mac
ab
Mac
ab
)  K ab
(N a , N b , B)
(N a , N b )
Extension for Inter-Domain Protocol
Kerberos
TGSlocal
1. {AA}KA,TGS,
{TA,TGS}KTGS ,
TGSrem
Alice
2. {KA,TGSrem}KA,TGS ,
{TA,TGSrem}KTGSrem
A
5. {AA}KA,B, {TA,B}KB
Remote
B Server
4. {KA,B}KA,TGSrem,
3. {AA}KA,TGSrem,
{TA,B}KB
{TA,TGSrem}KTGSrem,
B
TGSremote
Key Exchange in Kerberos
CS.UMN.EDU
UMN.EDU
EDU
MIT.EDU
EDU
UMD.EDU
O(N2)
MIT.EDU
O(logN)
UMN.EDU
CS.UMN.EDU
UMD.EDU
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
A-B-K inter-domain Protocol
(Without Inter-KDC communication)
B
A
KDC2
Na
Na ,Nb ,A
KDC1
Mac
Mac
12
(N a , K ab , A, B), E 12 (Mac
N b , Mac
B, N a ,
Mac
12
(N a , K ab , A, B), E 12 (Mac
Mac a (N a , K ab , B), E a (Mac
a
12
ab
12
(N a , N b , B )
)  K ab
)  K ab
Mac
ab
(N a , N b )
12
(N a , K ab , A, B), E 12 (Mac
Mac b (N b , K ab , A), E b (Mac
)  K ab ,
b
12
)  K ab ,
)  K ab
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)
A-B-K-K Protocol
B
A
KDC2
Na
Na ,Nb ,A
KDC1
N a , N 2 , A, B
Mac a (N a , K ab , B), E a (Mac
Mac
12
a
(N 2 , K ab , B, A), E 12 (Mac
Mac a (N a , K ab , B), E a (Mac
a
)  K ab ,
12
)  K ab
)  K ab ,
N b , Mac
ab
(N a , N b , B )
Mac
ab
(N a , N b )
Mac a (N a , K ab , B), E a (Mac
a
)  K ab ,
Mac b (N b , K ab , A), E b (Mac
b
)  K ab
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
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.