mediated authentication with kdc, and...
TRANSCRIPT
Mediated Authentication with KDC, and
Kerberos
• Readings
– Sections 11.4, 13.1 – 13.11
1
Distributing Authentication Keys
• Secret keys
– In a large network, it is infeasible to assume that each pair
of nodes share a secret key.
– Idea: Use a central server to distribute keys, the Key
Distribution Center (KDC).
• Analogy: In a LAN, often the password database is
stored in a single server
• Public/private keys
– Certificate authorities (CA)
2
Using a KDC
• Entity A contacts the KDC and uses KA (shared key with KDC) to authenticate herself and request a key for use with entity B.
• KDC generates a session key KAB for use between A and B.
• KDC then:– encrypts the session key and sends it securely to A (using KA).
– encrypts the session key with KDC’s shared key KB with Bob, and sends it securely to B directly or more simply to A to give to B.
• A decrypts the session key and contacts B, giving him the encryption of the session key computed by the KDC if not sent directly to B.
• Some potential pitfalls– KDC may impersonate users, so it must be entirely and completely
trusted.
– KDC is a performance bottleneck as well as a single point of failure.
3
Basic KDC Sequence without mutual
authentication between Alice and Bob
4
Alic
e
KD
C
IDA ,may I talk to Bob?
KA{KAB, KB{KAB, IDA}}
Bo
b
Hello Bob, this is Alice: KB{KAB, IDA}
KDC could alternatively send shared
session key to Bob directly
Multiple KDCs
5
Alic
e
Alic
e’s
ho
me
KD
C1
May I talk to KDC2?
KA{KA2}, K12 {KA2} B
ob
’s h
om
e K
DC
2
May I talk to Bob? K12 {KA2}
KA2{KAB}, KB {KAB} Bo
b
Hello Bob: KB {KAB}
A Global KDC infrastructure
• If each organization wishes to set up a KDC, it
becomes infeasible for each to have a key shared
with all the others
• KDCs need to authenticate other KDCs
– Hierarchical infrastructure, with root KDC
– Trust graphs, with varying trust levels
• KDC1 does NOT trust KDC2
• KDC1 trusts KDC2 to authenticate KDC2 users
• KDC1 trusts KDC2 to authenticate any users
• KDC1 trusts KDC2 to introduce trusted KDCs
6
Needham and Schroeder Protocol
• Published in 1978
– Seminal paper on cryptographic protocols
• Identified several "canonical" protocols including for
authentication
• Accidentally illustrated the first canonical protocol flaw
found
– The flaw was found two years later
– The flaw reflects a very unlikely attack
– Nonetheless, it illustrates how hard it is to produce reliable
cryptographic protocols.
7
Needham-Schroeder Secret Key Protocol
8
Alic
e
S =
KD
CKas{na, B, Kab, Kbs{Kab,A}}
Bo
b
Kbs{Kab, A}, Kab{n2}
(A, B, na)
Kab{nb-1}
Kab{n2-1, nb}
Note: a ticket is in red
Needham-Schroeder Secret Key Protocol
9
A =>S: (A,B,na)
S =>A: Kas{na, B, Kab, Kbs{Kab,A}}
A =>B: Kbs{Kab, A}, Kab{n2}
B =>A: Kab{n2-1, nb}
A =>B: Kab{nb-1}
Attack on Needham-Schroeder Protocol (Replay)
10
• Vulnerability: old (session) keys are still valuable
Initial session
A =>S: (A,B,na)
S =>A: Kas{ na, B, Kab , Kbs{Kab, A} }
A =>B: Kbs{Kab, A}, Kab{n2}
-- This message establishes the session key
B =>A: Kab{n2-1, nb}
A =>B: Kab{nb-1}
• The malicious intruder can
– captures the key interchange messages and the ensuing session.
– compromises (obtains) old key Kab ,
– initiates a new session with Bob.
Attack on Needham-Schroeder Protocol
11
Initial session
A =>S: (A,B,na)
S =>A: Kas{ na, B, Kab, Kbs{Kab,A} }
A =>B: Kbs{Kab, A}, Kab{n2}
B =>A: Kab{nb}
A =>B: Kab{nb-1}
B =>A: Kab{nb'} [intercepted by T]
T =>B: Kab{nb'-1}
T =>B: Kbs{Kab, A}
Replay session: (Trudy knows Kab)
Result of the Attack and Corrections
• Bob believes that he is in a secure session with Alice, but he is actually in a secure session with Trudy, i.e. Trudy has masqueraded as Alice.
• Corrections– Forcing initiator to talk to KDC first (expanded Needham-
Schroeder protocol)
– Use of a timestamp (in Kerberos)
12
Expanded Needham-Schroeder Protocol
13
Alic
e
S =
KD
CKas{na, B, Kab, Kbs{Kab,A, N1}} Bo
b
Kbs{Kab, A, N1}, Kab{n2}
(A, B, na), Kbs{N1}
Kab{nb-1}
Kab{n2-1, nb}
I want to talk to you
Kbs{N1}
Kerberos
• Trusted 3rd party authentication service
• Designed at MIT in the 1980’s
• Secret key based service providing authentication and
access control policy
• Versions 4 & 5 in use
• Based on the work by Needham and Schroeder
• Widely used
• stateless
14
KERBEROS: the name
Kerberos (demon of the pit):
Monstrous three-headed dog (sometimes said to have
fifty or one-hundred heads), (sometimes) with a
snake for a tail and innumerable snake heads on his
back.
Kerberos guarded the gate to Hades (the Greek
underworld) and ensured that the dead could not
leave and the living could not enter.
The Roman name is Cerberus
15
Kerberos Components
• Key Distribution Center (KDC)– Runs on a physically secure node
– Authenticates clients of the authentication service – called principals
– Provides session keys for principals wanting to use a network service such as a file service
• Clients and Servers– A client can be a program or a person
– A server, typically a program, provides an abstract service
– Principals are clients of authentication service – each principal is assigned a secret key (symmetric key encryption system)
• Users– Human being using a service
– Has a password that is turned into a secret key through a one way function
16
Kerberos (V4)
• Trusted Server – KDC– Shares a master key with each principal– KDC implements both an Authentication Server (AS)
and a Ticket Granting Server (TGS)
• Ticket – issued to one entity (a client) to be used to securely pass information to another entity (a server) encrypted in the master key of the server.
• Authenticator - information to prove that a client presenting a ticket is actually the one to whom the ticket was issued. – Authenticator is often the session key encrypted
information that can be compared against information in the ticket
• Authenticators and tickets are both credentials
17
The KDC
• AS (authentication server):
– Authenticates users based on their master keys, hands off
session keys for secondary authentication: ticket-granting
tickets (TGT).
• TGS (ticket granting server):
– Performs secondary authentication based on the TGT keys,
hands off tickets for principals to communicate with
kerberized network services.
18
KDC Configuration
• The KDC database is kept encrypted under KDC’s
own master key.
• Users have passwords, their master key is derived
from them
• Kerberized network servers need to store their
master key somehow.
• All master keys are stored in the KDC database
(except KDC’s own.)
19
First Step: Get a TGT
20
�Alice
Work
statio
n
KD
C
Alice,
password [AS_REQ]
Alice needs TGT
[AS_REP]:
KA{SA,TGT}
Create SA ,
Compute TGT=
KKDC{Alice,SA}
Derive KA,
Recover TGT,
SA
Getting a Service Ticket
21
�Alice
Work
statio
n
KD
Crlogin Bob
[TGS_REQ]:
Talk to Bob,
TGT, auth
[TGS_REP]:
SA{Bob,KAB,T}
SA from TGT,
Decrypt auth,
check t-stamp,
Create KAB, T =
KB{Alice, KAB}
use SA to
Decrypt
KAB, T
auth =
SA{timestamp}
Contents of a Ticket
• Alice's name
• Alice's instance
• Alice's realm
• Alice’s network layer address
• Session key (Alice –Bob)
• Ticket lifetime – units of 5 minutes
• Timestamp - when ticket made by KDC
• Bob's name
• Bob's instance
• Padding – ticket length multiples of 8 octets
22
Using the Ticket
23
�Alice
’s work
statio
n
�Bob
[AP_REQ]:
T = KB{Alice,KAB},
auth’ = KAB{timestamp}
[AP_REP]
KAB{timestamp+1}
Replicating KDCs
• To alleviate bottlenecks, replicate KDC:
– One KDC is master database, to add or remove users, and
change passwords
– Other KDCs use database as read-only
• A master KDC establishes a realm. Inter-realm
authentication supported:
– KDC1 registers KDC2 as a principal
– KDC1 enables other principals to access KDC2 as a
kerberized service.
24
Realms
25
KDC 2
KDC 1
Realm 1
Realm 2
Realm Rules
Inter-Realm Authentication: 1
26
�Alice
@W
onderla
nd
Work
statio
n
KD
C
Dorothy@Oz
[TGS_REQ]:
(for O = Oz’s KDC)
TGT, auth
[TGS_REP]:
SA{O,KAO,T}
SA from TGT,
Decrypt auth,
check t-stamp,
Create SAO, TO =
KO{Alice, SAO}use SA to
Decrypt
SAO, T
auth =
SA{timestamp}
Inter-Realm Authentication: 2
27W
ork
statio
n
Oz’s K
DC
[TGS_REQ]:
TO, auth’, Dorothy
[TGS_REP]:
SAO{Dorothy,KAD,T}
SAO from TO,
Decrypt auth’,
check t-stamp,
Create KAD, T =
KD{Alice, KAD}use SAO to
Decrypt
KAD, T
auth’ =
SAO{timestamp}
Encryption for both Privacy and Integrity
• Plaintext Cipher Block Chaining (PCBC)
– Also called propagating Cipher Block Chaining
• In Kerberos (V4), some recognizable data added at
end of message
28
PCBC Decryption
• Modification in a block cipher i will affect all plaintext
blocks starting from block i to the end
29
Kerberos V5
• More resistant to determined attacks over the
network
• More flexible
– Support for forwardable, renewable, and postdatable tickets.
– Kerberos tickets can now contain multiple IP addresses and
addresses for different types of networking protocols.
– Other encryption algorithms beside DES can be used.
– Support for replay caches, so authenticators are not
vulnerable to replay.
– Support for transitive cross-realm authentication.
30
Kerberos Operations Review
Get a TGT (initially done)
Get a ticket / session key to B
Start a session to B
Get a ticket /session to Sremote
Get a ticket /session to Bremote
Start an inter-realm session to
Bremote
A => S: AS_REQ
S => A: AS_REP
A => S: TGS_REQ
S => A: TGS_REP
A => B: AP_REQ
B => A: AP_REP
A => Slocal: TGS_REQ
Slocal => A: TGS_REP
A => Sremote: TGS_REQ
Sremote => A: TGS_REP
A => Bremote: AP_REQ
Bremote => A: AP_REP 31
Reading Assignment
• Chapter 15
32