Standards

1. Standards Kerberos V4

2. Goals of Kerberos • Kerberos is a network authentication protocol created by MIT which uses symmetric key cryptography to authenticate users to network services — eliminating the need to send passwords over the network. When users authenticate to network services using Kerberos, unauthorized users attempting to gather passwords by monitoring network traffic are effectively thwarted. • Advantages: • Most conventional network systems use password-based authentication schemes. Such schemes require a user to authenticate to a given network server by supplying their user name and password. Unfortunately, the transmission of authentication information for many services is unencrypted. For such a scheme to be secure, the network has to be inaccessible to outsiders, and all computers and users on the network must be trusted and trustworthy. • Even if this is the case, once a network is connected to the Internet, it can no longer be assumed that the network is secure. An attacker who gains access can use a simple packet analyzer, also known as a packet sniffer, to intercept usernames and passwords sent in this manner, compromising user accounts and the integrity of the entire security infrastructure. • The primary design goal of Kerberos is to eliminate the transmission of unencrypted passwords across the network. If used properly, Kerberos effectively eliminates the threat packet sniffers would otherwise pose on a network.

3. Disadvantages Although Kerberos removes a common and severe security threat, it may be difficult to implement for a variety of reasons: • Migrating user passwords from a standard UNIX password database, such as /etc/passwd or /etc/shadow, to a Kerberos password database can be tedious, as there is no automated mechanism to perform this task. For more information, refer to question number 2.23 in the Kerberos FAQ online at the following URL: http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html. • For an application to use Kerberos, its source must be modified to make the appropriate calls into the Kerberos libraries. For some applications, this can be quite problematic due to the size of the application or its design. For other incompatible applications, changes must be made to the way in which the server and client side communicate. Again, this may require extensive programming. Closed-source applications that do not have Kerberos support by default are often the most problematic. • Kerberos assumes that you are a trusted user using an untrusted host on an untrusted network. Its primary goal is to prevent plain text passwords from being sent across that network. However, if anyone other than the proper user has access to the one host that issues tickets used for authentication — called the key distribution center (KDC) — the entire Kerberos authentication system is at risk of being compromised. • Kerberos is an all or nothing solution. If you decide to use Kerberos on your network, you must remember that any passwords transferred to a service which does not use Kerberos for authentication are at risk of being captured by packet sniffers. Thus, your network gains no benefit from the use of Kerberos. To secure a network with Kerberos, one must either use kerberized versions of all client/server applications which send unencrypted passwords or not use any such client/server applications at all.

4. Terminology • ciphertext • Encrypted data. • client • An entity on the network (a user, a host, or an application) that can get a ticket from Kerberos. • credential cache or ticket file • A file which contains the keys for encrypting communications between a user and various network services. Kerberos 5 supports a framework for using other cache types, such as shared memory, but files are more thoroughly supported. • crypt hash • A one way hash used to authenticate users. While more secure than plain text, it is fairly easy to decrypt for an experienced cracker. • GSS-API • The Generic Security Service Application Program Interface [RFC-2743] is a set of functions which provide security services which clients can use to authenticate to servers and which servers can use to authenticate to clients without specific knowledge of the underlying mechanism. If a network service (such as IMAP) uses GSS-API, it can authenticate using Kerberos. • key • Data used when encrypting or decrypting other data. Encrypted data cannot be decrypted without the proper key or extremely good guessing. • Key Distribution Center (KDC) • A service that issues Kerberos tickets, usually run on the same host as the Ticket Granting Server • key table or keytab • A file that includes an unencrypted list of principals and their keys. Servers retrieve the keys they need from keytab files instead of using kinit. The default keytab file is /etc/krb5.keytab. The KDC administration server, /usr/kerberos/sbin/kadmind, is the only service that uses any other file (it uses /var/kerberos/krb5kdc/kadm5.keytab).

5. Terminology (cont.) • kinit • The kinit command allows a principal who has already logged in to obtain and cache the initial Ticket Granting Ticket (TGT). For more on using the kinit command, see its man page. • principal • The principal is the unique name of a user or service that can authenticates using Kerberos. A principal's name is in the form root[/instance]@REALM. For a typical user, the root is the same as their login ID. The instance is optional. If the principal has an instance, it is separated from the root with a forward slash ("/"). An empty string ("") is considered a valid instance (which differs from the default NULL instance), but using it can be confusing. All principals in a realm have their own key, which for users is derived from a password or is randomly set for services. • realm • A network that uses Kerberos, composed of one or more servers called KDCs and a potentially large number of clients. • service • A program accessed over the network. • ticket • A temporary set of electronic credentials that verify the identity of a client for a particular service. • Ticket Granting Service (TGS) • A server that issues tickets for a desired service which are in turn given to users for access to the service. The TGS usually runs on the same host as the KDC • Ticket Granting Ticket (TGT) • A special ticket that allows the client to obtain additional tickets without applying for them from the KDC. • unencrypted password • A plain text, human-readable password.

6. 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

7. 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.

8. 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.

9. 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.

10. 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

11. [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}

12. 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

13. 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

14. 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

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

16. Kerberos Architecture • Kerberos architecture consists of three key components: • client software • authentication server software • application server software