The Evolution of the Kerberos Authentication Service ==================================================== Kohl, Neuman, Tso's, 1991. Big Picture: The paper describes some problems with Ver 4 and the new features in Ver 5. Problems and solutions ---------------------- 1. Inflexible parameters/schemes Not appropriate universally: Fixed encryption scheme (DES), fixed network addressing scheme (IP), fixed encoding of messages, limited principal naming (fixed lengths, no .'s in names, etc.), maximum ticket-lives. Solutions: - Allow different encryption schemes. Each message is now tagged with an id reflecting the scheme in use. - Allow different network addressing schemes. Each message is similarly tagged with the scheme in use. - Standardize message encoding scheme to a universally accepted standard. - A different naming scheme with practically no restriction on size or characters allowed. - Allow arbitrary ticket lifetimes by changing the encoding of time for which a ticket is valid. 2. Authentication forwarding How do we allow credentials issued to one client to be forwarded to another host and used by another client? Solution: Allow a ticket to be valid for a different set of addresses than the TGT used in the request. 3. Inter-realm authentication Ver 4 allows inter-realm authentication. However, it requires n(n-1)/2 secret-keys (one for each pair of Key-Distribution-Centers). Managing so many keys is hard. Solution: Let realms cooperate through a hierarchy based on names of realms. A principal who wishes to contact a server in a foriegn realm, it "walks" up and down this tree, contacting each realm's KDC in turn. The paper does not give details regarding maintenance of such realms, delegation of authority, or even intricacies pertaining to this tree traversal. [How is the management complexity reduced to O(log n)?] 4. Authenticators and replay detection Kerberos uses timestamps as nonces to guard against replay attacks. A Ver 5 server has to maintain a cache of recently used tickets to thwart such an attack. There are situations where a sequence number can suffice as a nonce. This saves memory at the memory. The paper doesn't give an example where sequence numbers suffice.. it points to another paper. Other features in Ver 5 ----------------------- - Each ticket issued by the KDC is marked as such (distinguishing it from those issued by TGS). Some servers like password-changing-servers force a client to present such a ticket, which in turn, forces the client to type in her password. This prevents an attacker from walking to an unattended workstation and changing somebody's password. - Renewable long-lived tickets: Tickets are "renewable". They have two expiration times. The ticket expires as usual at the earlier time. But it can be renewed for a little longer by KDC (but not beyond the second expiration time). This allows tickets to be used for long periods of time. But lets KDC revoke it if it discovers something's amiss. - Authorization data A new field "authorization data" was added to tickets. This field is made tamper-proof by encryption. The idea is to allow a client to limit the abilities of a proxy, who is using a ticket on the client's behalf using the ticket forwarding mechanism described above. - Subsession keys Many clients make several connections with a server over the lifetime of a ticket. This leaves room for replay attacks if the server doesn't protect itself against it. Ver 5 allows negotiation of a subsession key, one per connection to ameliorate the problem. This has the added advantage that a server who wishes to broadcast data to multiple clients, can do so more efficiently by first negotiating a common subsession key with each client and encrypting each data packet just once. - Support for hand-held authenticators, making password guessing difficult.