2. 2
AUTHENTICATION SERVERS (I)
• Their mission is:
(a) To check identity of all users
(b) To prevent unauthorized accesses
• Traditional solution is to use a pair
(userid, password)
– Very bad in a LAN environment
– Too vulnerable to snooping
3. 3
AUTHENTICATION SERVERS (II)
• Another bad solution is to trust the kernel of
sender’s machine:
– Solution used by rlogin, rsh, rcp
– Like trusting a foreign passport
– Only works in well-controlled networks
– Suffers from domino effect :
• Gaining full access to one machine gives
full access to whole network
4. 4
CRYPTOGRAPHY (I)
1. Conventional Cryptography
– Uses same key for coding and encoding
• Key could be a secret alphabet
– We now use much more complex schemes
and much bigger keys
– Major problem is key distribution
• Very hard without a trusted channel
5. 5
Example
• Assume we have a random stream of bits:
r0 , r1 , r2 , r3 , ...
• We convert our message into a bit stream:
m0 , m1 , m2 , m3 , ...
• Encode the message bitwise using XOR:
ci = mi ⊕ ri for i = 1, 2, 3 , ...
• Impossible to break if random bit stream is
truly random and never reused
6. 6
CRYPTOGRAPHY (II)
2. Public-Key Cryptography
– Uses two keys:
(a) A public key to encode: KP
(b) A secret key to decode: KS
– It is not possible to compute KS knowing KP
• The function KP = f ( KS) is said to be hard
to invert:
7. 7
CRYPTOGRAPHY (II)
– We should have
• { { cleartext }KP }KS= cleartext
• { { cleartext }KS }KP= cleartext
– Requires very long keys
– Cannot pick an arbitrary secret key
– Much slower than conventional cryptography
8. 8
Example
• Assume A knows KP,B and B knows KP,A
– A can send to B a secret message:
{ text } KP,B
– A can send to B a message that is signed:
A, { text } KS,A
– A can send to B a signed secret message:
{ A, { text }KS,A } KP,B
9. 9
Application
• Can combine conventional cryptography and
public-key cryptography
– A uses public-key cryptography to send to B a
signed secret message containing a session
key KS
– A and B use this session key KS to continue
their dialogue
10. 10
KERBEROS
• Authentication server using conventional keys
• The Kerberos server has
– The key of each user
– The key of the ticket granting service (TGS)
• Authentication is a two-step process
– Get from kerberos a ticket for the TGS
– Get from TGS the ticket for a given server
12. 12
General Assumptions (I)
• Cannot trust the network:
– Intruders can listen to all messages and
replay them later
• Can trust the time service
– No intruder can reset any clock backward by
more than a few minutes
13. 13
General Assumptions (II)
• Client c can trust the workstation WS on which
she is logged on:
– Cannot do encryption without a safe place to
encode and decode messages
• Assumes the workstation is controlled by the
client
– Not true for public workstations
14. 14
Step 1
• Client provides WS with its ID c:
c → WS: c
WS sends to Kerberos a request for a ticket for
the TGS:
WS → K: c, tgs
15. 15
Step 2
• Kerberos sends to WS a ticket Tc,tgs and a random
session key Kc,tgs:
K → WS: { Kc,tgs, { Tc,tgs }Ktgs }Kc
Both items are encrypted with the client key Kc
Ticket is encrypted with the secret key of the
ticket granting service to prevent tampering by
client
16. 16
The ticket (I)
• Note that the encrypted ticket is encrypted a
second time by the client key KC
– In more recent versions of Kerberos
K → WS: { Kc,tgs}Kc, { Tc,tgs}Ktgs
17. 17
The ticket (II)
• Tc,tgs = c, tgs, addr, timestamp, life, Kc,tgs
• It contains
– The client's name c
– The name of the ticket-granting service tgs
– The IP address of the client addr
– The current time timestamp
– A ticket lifetime life
– The random session key K c,tgs
18. 18
Step 3
• When WS receives Kerberos reply, it prompts
the client c for her password and uses it to
compute the user key
Kc = fn(password)
and uses Kc to decrypt the message
20. 20
Step 3 (continued)
• WS then sends to the TGS
– The name of the service s the client wants to
utilize
– The encrypted ticket Tc,tgs
– An authenticator Ac,tgs encrypted with Kc,tgs
WS → TGS: s, { Tc,tgs}Ktgs, { Ac,tgs}Kc,tgs
21. 21
The authenticator (I)
• Any intruder could replay a ticket that has
already be submitted to TGS
• Authenticator contains
– The client name c
– Its address addr
– The current time timestamp
Ac,tgs = c, addr, timestamp
• Authenticator is encrypted with Kc,tgs
22. 22
The authenticator (II)
• Authenticator provides proof that WS was able
to obtain the session key Kc,tgsby decrypting
message number 2 using the right client key KC
• To detect replays of authenticators, TGS
– Rejects authenticators that are too old
(say, by more than five minutes)
– Keeps track of all recently received
authenticators
23. 23
Step 4
• The TGS replies by sending to the workstation
– A ticket T cs for the service s
– A new random session key Kc,s
TGS → WS: { Kc,s, { Tc,s}Ks}Kc,tgs
encrypted with the session key Kc,tgsshared by the
client and the ticket granting service
24. 24
Step 4 (continued)
• Tc,s contains
– The user's name c
– The name of the service s
– The IP address of the client addr
– The current time timestamp
– A new lifetime life
– A new random session key Kc,s
• Tc,s is encrypted with the secret key of server s
25. 25
Step 5
• WS then sends to server S
– the encrypted ticket Tc,s
– an authenticator Ac,s encrypted with Kc,s
WS → S: { Tc,s}Ks, { Ac,s }Kc,s
26. 26
Step 5 (continued)
• Authenticator contains
– the client name c
– its address addr
– the current time timestamp
Ac,s = c, addr, timestamp
• Authenticator is encrypted with the session key
Kc,s shared by client and server
27. 27
Step 6
• If client wanted to authenticate server, the
server replies with the authenticator time stamp
plus one:
s→WS: { timestamp + 1 }Kc,s
encrypted with the session key Kc,s
• This proves that s was able to obtain the session
key Kc,sby decrypting message number 5 using
its server key Ks
28. 28
Picking ticket lifetimes
• There is a trade-off in determining the optimal
ticket lifetime:
– Short ticket lifetimes make the system more
secure
• Less delay between password change and
full effect of action
– Short ticket lifetimes also make the system
less convenient for its users.
29. 29
The Kerberos server (I)
• Most critical part of the system
– If it is compromised, all user passwords are
lost
– If it is unavailable, nobody will be able to log
in
• A compromised TGS would only force all users
to repeat the Kerberos login procedure
30. 30
The Kerberos server (II)
• The Kerberos server is normally replicated on
several sites:
– No single point of failure
– More difficult to maintain key secrecy
• There is a single primary site and it is the only
than can accept key change requests
– Changing passwords is not a critical task
31. 31
LIMITATIONS
• Must maintain
– secrecy of keys
– integrity of time service
• Client must trust the workstation on which she is
logged in
• Does not protect clients and servers against
denial of service attacks
32. 32
OTHER SOLUTIONS (I)
• Could use a pair public key/private key
– private keys cannot be generated from an
arbitrary password
– impossible to memorize
– must store them somewhere
• key ring of PGP is encrypted using a strong
conventional encryption algorithm
33. 33
OTHER SOLUTIONS (II)
• Could use one-time passwords
– Use a different password at each log in
– Passwords can be managed by a smart card
– User must always carry it with her
– Some systems also require a password to use
the card and disable card after enough
unsuccessful trials
• Must keep card in a rigid container
34. 34
OTHER SOLUTIONS (III)
• SSH-2 uses
– Diffie-Hellman key exchange
• Uses public keys and private keys
• Produces a symmetric session key
– Strong integrity checking via message
authentication codes.
35. 35
OTHER SOLUTIONS (IV)
• Two-factor authentication
– Must provide
• Something you know (a password)
• Something you have (a dongle or a phone)
– Google two-factor authentication:
• Enter first name and password
• Google sends a six-digit code to your
phone that you must then enter
36. 36
CONCLUSIONS
• Kerberos offers one of the best solutions for
authentication in distributed systems
– Does not require any special equipment
– Does not significantly alter the user interface
• Main drawback is that the user must trust the
workstation on which she is logged in
– Works best for personal workstations
