6.824 2005 Lecture 10: Key management

Review of Verisign (as opposed to SSL):
  Amazon sends Verisign proof of ID and a public key
  Verisign sends Amazon a certificate:
    { "www.amazon.com", expiration, Amazon public key } signed by Verisign
  Browsers ship containing Verisign's public key
  Browser can use SSL to check that we really connected to www.amazon.com
    or the entity that Verisign calls "www.amazon.com"
  Both sides can present Verisign certificates to SSL
    "client certificates"

Would we want to use SSL+Verisign for Athena authentication/authorization?
  many of the details are wrong for a workstation/server environment
  can't use Verisign certificates directly
    maybe they can identify MIT, but not each student
  how do users carry around private keys?
  how do you revoke certificates?

Kerberos takes a different approach to "key management"
  X wants a secure channel to Y, but they don't share crypto keys
  don't want to set up N^2 keys pairs in advance
  idea: everyone shares a key with a central Authentication Server
  X tells AS "I want to talk to Y"
  AS makes a session key, gives it to X, gives it to Y
    AS can talk securely to both X and Y
  now X and Y share a key, they can talk securely too

- Example: Kerberos

  - See Section 24.5 of Schneier, 2nd edition
  - Also RFC1510, which explains nonces (n in protocol below)

  - Kerberos based on symmetric-key system using secret keys and a
    centralized auhentication server.  The authentication server
    authenticates the client and helps in setting up an authenticated
    connection betwen the client and the server.

    From Kerberos V5 RFC:

       The authentication process proceeds as follows: A client sends
       a request to the authentication server (AS) requesting
       "credentials" for a given server.  The AS responds with these
       credentials, encrypted in the client's key.  The credentials
       consist of 1) a "ticket" for the server and 2) a temporary
       encryption key (often called a "session key").  The client
       transmits the ticket (which contains the client's identity and
       a copy of the session key, all encrypted in the server's key)
       to the server.  The session key (now shared by the client and
       server) is used to authenticate the client, and may optionally
       be used to authenticate the server.  It may also be used to
       encrypt further communication between the two parties or to
       exchange a separate sub-session key to be used to encrypt
       further communication.

   Client logs in and wants to talk to a server named Bob. C is Client,
   S is server, AS the Authentication Server, TGS is the ticket granting
   server.

   Typical scenario (this is really Kerberos v5):

   0. Client "c" types user-name to a workstation
   1. C -> AS:  "c", "tgs", n
   2. C <- AS:  {Kc,tgs , n}Kc , Tc,tgs
   3. Client types password Kc to the workstation.
   4. C -> TGS: {TS}Kc,tgs , Tc,tgs , "s", n
   5. C <- TGS: {Kc,s , n}Kc,tgs , Tc,s
   6. C -> S:   {TS}Kc,s , Tc,s
   7. C <- S:   {TS+1}Kc,s

   Tc,s: {"s", "c", Kc,s , expiration}Ks   [this is a "ticket"]

   What are the entites sure of at the start?
     Client: Kc (user's password)
     AS: Kc and Ktgs
     TGS: Ktgs and Ks
     Bob: Ks
  
   What can S conclude about source of msg in 6?
   How is S sure he isn't seeing a replayed request?
   What can C conclude about src of msg in 7?
   How is C sure she isn't seeing a replayed reply?
   How is C sure she is talking to the real AS?

   The protocol pushes all these questions back to the AS.
     How does the AS get correct password for Client?
     How does the TGS get server's key Ks?
     Kerberos changes key distribution from O(N^2) to O(N).

   Why the AS / TGS split?
     To avoid the workstation having to remember Client's password.
     TGS also needs to get server keys from AS's DB.

 - Suppose I want to implement an Access Control List (ACL) using Kerberos.
   For example, to control access to my directory on AFS.
   I want to list users who can read or write my directory.
   What exactly should I put in the ACL?
   That is, what is a Kerberos "identity"?
   Why does that make sense?

 - How can I revoke an account?
   Take it out of the AS's database.
   But user may still have a valid ticket, good for a day.

 - How can I revoke a user's authorization?
   Remove user from an ACL.
   Takes effect immediately?

 - What attacks might a Kerberos-based system be vulnerable to?
   Password-guessing based on recorded message #2. Could collect many of them.
   Replay within lifetime of authenticator.
   Attack the time synchronization system.
   If many users share e.g. athena.dialup.mit.edu, steal tickets from disk/memory.
   AS stores user passwords in the clear; break in and steal them all.
   User types password to workstation in clear; fake login: prompt.

 - Would Kerberos in practice make a big improvement to security?
   Compared to what? Non-cryptographic NFS and telnet?

 - Why not use Kerberos on the WWW in place of SSL/Verisign?
   Requires clients to have identities: no anonymous browsing.
   Only one identity space (realms sort of fixes this).
   Central authority involved in adding a new user or server.   

 - How does an MIT user get authenticated access to a CMU server?
   That is, how can the MIT user trust the results of /afs/cs.cmu.edu?
   Needs to get a ticket for cs.cmu.edu file server.

   It requires that the administrators at MIT and CMU exchange
   inter-realm keys, which registers the local TGS as a principle in
   the remote realm and vice versa.

   This means Kerberos inter-realm authentication is O(N^2), and
   must be done by administrators, not users.

   [as noted by the RFC better automatic solutions are needed if
   cross-realm access is common.]