Kerberos

1. Kerberos

2. What is Kerberos? • Kerberos is an authentication service developed at MIT. Its purpose is to allow users and services to authenticate themselves to each other. • There are many ways to establish one's identity to a service. The most familiar is the user password. One "logs in" to a server by typing in a user name and password, which ideally only the user (and the server) know. The server is thus convinced that the person attempting to access it really is that user. • The password must transit that network in the clear--that is, unencrypted. That means that anyone listening in on the network can intercept the password, and use it to impersonate the legitimate user. • The key innovation underlying Kerberos is the notion that the password can be viewed as a special case of a shared secret--something that the user and the service hold in common, and which (again ideally) only they know. Establishing identity shouldn't require the user to actually reveal that secret • In Kerberos, that secret is used as an encryption key. In the simplest case, the user takes something freshly created, like a timestamp (it need not be secret), and encrypts it with the shared secret key. This is then sent on to the service, which decrypts it with the shared key, and recovers the timestamp. If the user used the wrong key, the timestamp won't decrypt properly, and the service can reject the user's authentication attempt. Ref: http://www.isi.edu/~brian/security/kerberos.html

3. Basics of Kerberos • Kerberos's fundamental approach is to create a service whose sole purpose is to authenticate. This is that it frees the services from having to maintain their own user account records. • The key to this approach is that both user and service implicitly trust the Kerberos authentication server (AS); the AS thus serves as an introducer for them. • In order for this to work, both the user and the service must have a shared secret key registered with the AS; such keys are typically called long-term keys, since they last for weeks or months. • Steps in authenticating a user to an end service. • (1) User sends a request to the AS, asking it to authenticate him to the service. • (2) AS generates a new, random secret key that will be shared only by the user and the service. It sends the user a two-part message. One part contains the random key along with the service's name, encrypted with the user's long-term key (credentials); the other part contains that same random key along with the user's name, encrypted with the service's long-term key (ticket). • (3) User generates a fresh message, such as a timestamp, and encrypts it with the session key. This message is called the authenticator. He sends the authenticator, along with the ticket, to the service. The service decrypts the ticket with its long-term key, recovers the session key, which is in turn used to decrypt the authenticator. The service trusts the AS, so it knows that only the legitimate user could have created such an authenticator.

4. The Ticket Granting Server • One of the inconveniences of It can be inconvenient if multiple services are used. • Kerberos resolves this problem by introducing a new service, called the ticket granting server (TGS). The TGS is logically distinct from the AS, although they may reside on the same physical machine. (They are often referred to collectively as the KDC--the Key Distribution Center, from Needham and Schroeder [1].) The purpose of the TGS is to add an extra layer of indirection so that the user only needs to enter in a password once; the ticket and session key obtained from that password is used for all further tickets. • So, before accessing any regular service, the user requests a ticket from the AS to talk to the TGS. This ticket is called the ticket granting ticket, or TGT; it is also sometimes called the initial ticket. The session key for the TGT is encrypted using the user's long-term key, so the password is needed to decrypt it from the AS's response to the user. • After receiving the TGT, any time that the user wishes to contact a service, he requests a ticket not from the AS, but from the TGS. Furthermore, the reply is encrypted not with the user's secret key, but with the session key that came with the TGT, so the user's password is not needed to obtain the new session key (the one that will be used with the end service). • The advantage this provides is that while passwords usually remain valid for months at a time, the TGT is good only for a fairly short period, typically eight or ten hours. Afterwards, the TGT is not usable by anyone, including the user or any attacker. This TGT, as well as any tickets that you obtain using it, are stored in the credentials cache. [1] R. M. Needham and M. D. Schroeder, "Using Encryption for Authentication in Large Networks of Computers," Communications of the ACM, Vol. 21 (12), pp. 993-99. Last modified 30 March 2006.

5. Cross-Realm Authentication • As the network grows, the number of requests grows with it, and the AS/TGS becomes a bottleneck in the authentication process. For this reason, it often makes sense to divide the world into distinct realms. These divisions are often made on organizational boundaries, although they need not be. Each realm has its own AS and TGS. • To allow for cross-realm authentication--that is, to allow users in one realm to access services in another--it is necessary first for the user's realm to register a remote TGS (RTGS) in the service's realm. Such an association typically (but not always) goes both ways, so that each realm has an RTGS in the other realm. This now adds a new layer of indirection to the authentication procedure: First the user contacts the AS to access the TGS. Then the TGS is contacted to access the RTGS. Finally, the RTGS is contacted to access the end service. • Actually, it can be worse than that. In some cases, where there are many realms, it is inefficient to register each realm in every other realm. Instead, there is a network of realms, so that in order to contact a service in another realm, it is sometimes necessary to contact the RTGS in one or more intermediate realms. These realms are called the transited realms, and their names are recorded in the ticket. This is so the end service knows all of the intermediate realms that were transited, and can decide whether or not to accept the authentication. (It might not, for instance, if it believes one of the intermediate realms is not trustworthy.) • This feature is new to Kerberos in Version 5. In Version 4, only peer-to-peer cross-realm authentication was permitted. In principle, the Version 5 approach allows for better scaling if an efficient hierarchy of realms is set up; in practice, realms exhibit significant locality, and they mostly use peer-to-peer cross-realm authentication anyway. However, the advent of public-key cryptography for the initial authentication step (for which the certificate chain is recorded in the ticket as transited "realms") may again justify the inclusion of this mechanism.

6. Obtaining a Session key and Ticket Granting Ticket (TGT) Invents key SA Finds Alice’s master KA TGT=KKDC{“Alice”,SA} AS_REQ Alice, Password Alice Workstation KDC AS_REP KA: Alice’s master key SA: Session key for Alice TGT: Session key, user’s name, expiration time; encrypted with KDC’s master key AS: Authentication server TGS: Ticket Granting Server KA{SA,TGT} KDC AS TGS

7. [AP_REQ] Alice’s Workstation Bob Alice Asks to Talk to a Remote Node Alice wants to talk to Bob TGT=KKDC{“Alice”, SA} Authenticator=SA{timestamp} Invents key KAB Decrypts TGT to get SA Decrypts authenticator Verifies timestamp Finds Bob’s master key KB Ticket to Bob=KB{“Alice”,KAB} rlogin Bob [TGS_REQ] Alice Workstation TGS [TGS_REP] SA{“Bob”, KAB, ticket to Bob} Ticket to Bob = KB{“Alice”, KAB} Authenticator=KAB{timestamp} Decrypts ticket to get KAB Decrypts authenticator Verifies timestamp [AP_REP] KAB{timestamp+1}

8. Interrealm Authentication Realm B Realm A Bob Alice KDC B KDC A TGS_REQ Alice KDC A credentials TGS_REQ KDC B credentials Bob AP_REQ

9. Formats - Example • Tickets: KDC issues a ticket to Alice for Bob Alice’s name Alice’s instance Alice’s realm Alice’s network layer address Session key for Alice < --- > Bob Ticket lifetime, units of 5 minutes KDC’s timestamp when ticket made Bob’s name Bob’s instance Pad of 0’s to make ticket length multiples of eight octets

10. Kerberos V5 • Delegation of Rights: Ability to give someone else access to things you are authorized to access. • Usually limited in time or limited in scope • Kerberos V5 allows delegation by Alice asking TGT with a network layer address (or multiple addresses) different from hers. • First, Alice gets a normal session key and a TGT with her network layer. • When later Alice decides to delegate to Bob, she requests a new TGT from the KDC---with a new network layer address

11. Hierarchy of realms A C B G D E H I F J