Attacks

• tapping
• spurious messages injection
• replay

Design considerations

• No passwords are communicated over the network
• Cryptographic protection against spoofing
• Limited period of validity
• Timestamps to prevent replay attacks
  • timestamp is a sequence number
• Mutual Authentication
  • if client wants server to prove its identity, the server could reply the new_timestamp = timestamp + 1

Open Problems

• How to decide the correct lifetime for a ticket
• How to allow proxies
• How to guarantee workstation integrity
• Constant availability of a TRUSTED Ticket Granting Server
• Authenticity of servers is dependent on a trust relationship between the KDC and every server
• Requires timely transactions
• Subverted workstation can save and replay user passwords
• Vulnerable to Simple Password Attacks
• Scalability is an issue
• Every object has to be “Kerberized”

Reviews

• Why Authentication Services separates from Ticket Granting Services
  • prevent fake user get the real ticket, so we should let the client to decrypt the Ticket Granting Ticket firstly
• Why we need an authenticator besides the ticket
  • the ticket just shows person A has been granted the permission, but you could not assume the ticket holder is person A
    • the client could create the authenticator by itself easily
  • the ipaddr in the ticket is not useful: it assumes that the client could not move with a fixed ip

Notes

• Distribute shared secret to right people
• Who do you trust?
  • devices are not trustworthy
• What if publish the public key?
  • others may fake your public key
    • need third party or key distribution service