3.3 Kerberos 5

If you look strictly at the feature set, Kerberos 5 is an evolution of Kerberos 4. The Kerberos 5 protocol contains all of the functionality present in the Kerberos 4 protocol, but with many extensions. However, from an implementation perspective, Kerberos 5 is a completely new protocol, and looks nothing like Kerberos 4 on the inside. In this section, we'll examine the new features present in Kerberos 5 as well as the new infrastructure provided by the protocol to make these features work.

The Kerberos 4 protocol had its share of shortcomings: it had a rather obtuse structure (for example, instead of standardizing on one byte order, it had a flag to specify which byte order was used to send a particular message) and it wasn't expandable, since many of its fields had fixed sizes. This limitation led to other problems, most notably the dependence on single-DES encryption keys. At the time that Kerberos 4 was developed, a brute-force attack against DES was still prohibitively expensive in terms of both resources and time. As computer speed continues to grow exponentially, it is now within the realm of well-funded adversaries to mount a brute-force attack against DES. Therefore, a more secure encryption algorithm with a longer encryption key size is needed. Unfortunately, since all of the fields in Kerberos 4 are fixed size, there is no way to retrofit Kerberos 4 with another encryption algorithm.

Another feature that users and administrators alike demanded from a new version of Kerberos was support for credential forwarding and delegation. Credential forwarding enables users to transfer their tickets to a remote server once they are authenticated to it. For example, take a user who has just logged in remotely to an application server via Kerberized telnet. Using Kerberos 4, if the user wishes to authenticate to, say, a file server, from the application server, she's essentially stuck. She must re-login to Kerberos from the remote server through kinit to acquire a new Ticket Granting Ticket on the remote server. This introduces security problems, since in order to re-authenticate to Kerberos, the user must retype her password, which in the case of telnet, is probably being sent in clear text over the network. In addition, the system no longer provides single-sign-on.

Kerberos 5 introduces support for credential forwarding so that in the previous example, when the user logs into the remote application server, her Ticket Granting Ticket is securely transmitted to the remote server and can be used by applications on that remote server to transparently authenticate her to further Kerberos services.

However, with these enhancements and extensibility comes complexity. In order to create an extensible protocol that can be implemented on multiple platforms by multiple vendors, and ensure that all these implementations can interoperate, the Kerberos development team chose to use a technology known as ASN.1 to describe their new Kerberos 5 protocol. ASN.1 allows protocol designers to create protocols with an abstract language, automating implementation details and allowing for future extensions. We'll talk more about ASN.1 and how ASN.1 is used to define the Kerberos 5 protocol messages in a bit.

Kerberos 5 strives to be as compatible with older clients and application servers as possible. In order to ensure compatibility with old Kerberos 4 software, Kerberos 5 provides the Kerberos 5-to-Kerberos 4 ticket translator service (commonly known as krb524). This service takes a valid Kerberos 5 ticket as input (the only requirement is that the ticket and session key encryption types be single-DES, as that is the only encryption type supported in Kerberos 4) and creates a valid Kerberos 4 ticket as output. By using the krb524 daemon, an organization can incorporate older Kerberos 4 services into a more modern Kerberos 5 infrastructure.

The Kerberos 5 protocol is under constant revision and development. The Kerberos home page at http://www.kerberos.isi.edu is the official home of the Kerberos Clarifications, a new set of documents being drafted to supersede the current RFC 1510. The Kerberos Clarifications documents are considered the definitive source for information on the Kerberos protocol.

3.3.1 The World's Shortest ASN.1 Tutorial

ASN.1 is an acronym for Abstract Syntax Notation One. It defines a methodology for describing protocol definitions in an abstract notation, and then provides several methods to convert those abstract definitions into a stream of bytes for transmission over a communications network. Several protocols use ASN.1 to define their protocols; along with Kerberos 5, SNMP and LDAP are popular protocols that use ASN.1.

As we saw earlier with the Kerberos 4 protocol definition, extensibility is an important attribute when designing protocols. No protocol remains static; it is much more efficient for both the implementer and users if a protocol has forward and backward compatibility built in from the start. A manually designed and coded protocol design such as that in Kerberos 4 is very difficult to add onto later, unless extreme care is undertaken during the design of the initial protocol. In addition, manual coding of the network encoding and decoding modules leads to bugs that then lead to trouble with interoperability when new implementations must work around or conform to bugs in the initial implementation. ASN.1 can help with both of these problems.

ASN.1 provides a grammar with which protocol designers can describe an application's protocol. ASN.1 also provides several built-in types such as INTEGER, representing an arbitrary integer number, and OCTET STRING, representing a string of characters. By chaining together these basic types to build more complex types, implementers can design what is referred to as the abstract syntax of their protocol, that is, a textual description of the protocol in an easily parseable form. The grammar used to describe this abstract syntax is similar to the BNF (Backus-Naur Form) commonly used to describe computer languages. Here's a sample ASN.1 definition:

   Realm ::=           GeneralString
   PrincipalName ::=   SEQUENCE {
                       name-type[0]     INTEGER,
                       name-string[1]   SEQUENCE OF GeneralString
   }

These are the two ASN.1 definitions in Kerberos 5 that define the parts of a Kerberos 5 principal. The Realm definition is fairly straightforward; a realm can be defined as a string of characters. The PrincipalName consists of a type (which indicates a style of name—Kerberos 5 defines several, including the traditional Internet-style names in the form of user@REALM and X.500) and an ordered sequence of strings, representing the components of the Kerberos principal. With Realm and PrincipalName defined, future ASN.1 definitions can use these types in more complex structures, such as a ticket structure or authenticator structure.

Now that we have this abstract syntax in place, we need some way to transmit and receive data that conforms to our syntax. For example, if we want to send and receive a set of PrincipalNames over the network, we need some sort of rule that specifies how to encode strings, integers, and sequences of strings (we want to ensure we get things in the right order, too!). As it turns out, there are several different standards related to encoding ASN.1 data for transmission, but the one that Kerberos uses is the Distinguished Encoding Rule, or DER. DER takes an ASN.1 data structure—say, a PrincipalName with its fields filled in by an application—and converts it into transfer syntax, or a series of bytes that can be sent to another application that speaks the same ASN.1-based protocol.

I won't bore you with details of how DER does its dirty work, but it works on a simple principal: the so-called TLV rule. TLV refers to type, length, value—the three pieces of information that are sent for every data field in an ASN.1 structure. The type refers to the ASN.1 type that the data represents: a byte constant is assigned to GeneralStrings to mark them as such, another byte represents INTEGER data, and so on. In addition, labels can be added to the types of each field, as indicated by the square brackets above. The labels ensure that the ordering of the data is preserved, and that the recipient can identify any optional or missing data. The length of the encoded data is sent next, and finally the data itself. By sending all of this information, a receiving host can reconstruct the original data structure from the transfer syntax.

With an ASN.1 abstract syntax in place, a specialized ASN.1 compiler can read the abstract syntax and generate program code that converts a given data structure that matches the abstract syntax into transfer syntax, and vice versa. The ASN.1 compiler automates the troublesome process of creating code to send and receive encoded protocol messages, giving the protocol implementer more time to write the program logic dedicated to their protocol.

Readers with an interest in learning more about ASN.1 can read the Layman's Guide to ASN.1, BER, and DER, which is available in several formats from the RSA Laboratories web site at http://www.rsasecurity.com/rsalabs/pkcs/index.html. In addition, a freely downloadable book documenting ASN.1 is available in PDF format from http://www.oss.com/asn1/dubuisson.html for those interested in more technical details.

3.3.2 The Authentication Server and the Ticket Granting Server

The idea behind the AS and TGS exchanges are unchanged in Kerberos 5. The name of the Ticket Granting Server changes slightly, thanks to the different principal naming conventions in Kerberos 5. For example, the Ticket Granting Server principal name in Kerberos 5 for the WEDGIE.ORG realm is krbtgt/WEDGIE.ORG@WEDGIE.ORG.

There are some protocol level details that have been changed in Kerberos 5, however. We've already discussed the most important one, namely, the use of ASN.1 to formally describe and encode the new protocol. In addition, the other protocol-level change that was made during the development of Kerberos 5 was to eliminate the double encryption that occurs during the Authentication Server and Ticket Granting server KDC replies. Recall from the discussion of the Kerberos 4 protocol above that there were essentially two layers of encryption in either an AS or TGS reply; the ticket, encrypted with the service's key, is contained within a reply message encrypted with the user's key.

This double encryption proves to be unnecessary, so Kerberos 5 concatenates the two encrypted messages one after the other instead of nesting the ticket inside of the reply message. This step improves efficiency and performance, and does not reduce the security of the messages. As the messages are still both encrypted with their respective keys, they are unreadable to attackers who do not have the relevant encryption keys to decrypt the messages.

3.3.3 New Encryption Options

The new multiple encryption type support in Kerberos 5 also means that there can be more than one encryption type used in a given Kerberos protocol transaction. A separate encryption type can be used in each of the following messages:

Ticket

The encryption type associated with the ticket is the encryption type used to encrypt the service ticket in the TGS or AS reply. Since the ticket can only be decrypted by the service, as it is encrypted with the service's encryption key, the ticket encryption type is determined by the highest strength encryption supported by the service for which the ticket is issued.

Reply

The encryption type of the reply from the KDC to the client refers to the part of the reply encrypted with the user's encryption key. Since the client must decrypt the reply, the reply encryption type is determined by the highest strength encryption the client supports.

Session key

Since the session key is shared between the client and the application server, the encryption type of the session key is the maximum-strength encryption algorithm that is supported by both the service and the client. For example, if the client supports single and triple DES but the service only supports single DES, then the KDC will issue single DES session keys for this service.

A diagram showing where each encryption key comes into play in a typical TGS reply is shown in Figure 3-10.

Figure 3-10. Encryption types in a typical TGS reply

Why the separation? Namely, to support interoperation between different Kerberos 5 implementations, older Kerberos 4 based applications, and interoperability between Kerberos 5 implementations that support different encryption types.

This fine-grained control enables any combination of encryption type support to interoperate on a Kerberos network, as long as all three parties involved (the application server, the client, and the KDC) all support at least one encryption type in common. When a principal is created on a KDC, it typically stores a copy of its encryption key using all of the different encryption types that it supports. Therefore, the KDC can respond to requests using the most secure encryption type supported by each participating party.

Unfortunately, while this scheme is rather flexible, it can also lead to problems that are difficult to track down. We'll look more into encryption-type mismatch issues in Chapter 5.

3.3.4 Ticket Options

Kerberos 5 includes advanced features that allow users more control over their Kerberos tickets. The following flags have been added to Kerberos 5:

Forwardable tickets

A user can request a forwardable ticket. A forwardable ticket can be forwarded to another host later—hence the name—and the ticket is valid for use on the new host. A common special case is the forwardable Ticket Granting Ticket. A forwardable TGT can be forwarded to another host, and the original TGT can be used to acquire a new TGT on the target host, without requiring the user to enter his password in again. For example, if a user logs into one host using Kerberos authentication, the user now has to acquire a new TGT before using Kerberos software on the target host. If, instead, the user has a forwardable ticket and forwards his TGT to the target host as part of the login process, the user now has a copy of his TGT valid for any further Kerberos ticket requests from the new host. By requesting a forwardable TGT, users can enjoy the benefits of single sign on, even when arbitrarily nesting credential delegations.

Proxiable tickets

You can also set the proxiable flag on a ticket. Proxiable tickets are similar to forwardable tickets in that they can be transferred to another host. However, a proxiable TGT can only be used to acquire further service tickets; it cannot be used to acquire a new TGT on the target host. In this sense, proxiable tickets are less powerful than their forwardable counterparts, and are not used often in practice.

Renewable tickets

In Kerberos 4, ticket lifetimes were limited to reduce the window of vulnerability in case a user's credentials were stolen. Kerberos 5 introduces a two-tiered lifetime scheme that combines the benefits of longer lifetimes with the security of shorter lifetimes. When a user requests a renewable ticket, he is issued a ticket with a standard lifetime and a renewable lifetime. The ticket is valid only for the duration of the standard lifetime, but can be submitted back to the KDC for renewal any time before the ticket expires (at the end of the standard lifetime). The KDC can refuse to validate the ticket, if, for example, it has been reported compromised in the mean time. Otherwise, the KDC validates the ticket and returns another ticket. This process can be repeated until the ticket's renewable lifetime finally expires.

Postdated tickets

A postdated ticket is one which is not valid until some specified date in the future. If a postdated ticket is presented for validation before the start date embedded in the ticket, it will be refused. Postdated tickets are useful for jobs scheduled to be run some time in the future that require Kerberos authentication, such as batch or cluster jobs. This option is not commonly used in practice, and in fact some implementations, such as Microsoft's, do not support the issuing of postdated tickets.

3.3.5 Kerberos 5-to-4 Ticket Translation

To provide compatibility with older Kerberos 4 services, Kerberos 5 specifies a Kerberos 5-to-4 ticket translation service. This service, known as krb524, provides a way that Kerberos 5 clients can communicate with older Kerberos 4 services. It does not provide a way for Kerberos 4 clients to communicate with Kerberos 5 services or KDCs.

When a Kerberos 5 client wishes to contact a service that only understands Kerberos 4 tickets, the Kerberos libraries contact a machine running the krb524 daemon to provide Kerberos 4 compatible credentials to present to the service. When the krb524 daemon receives a request from a client, it decrypts the service ticket with the service's key, extracts the session key contained inside, and creates a new Kerberos 4 ticket for the same service and client, pasting in the session key from the original Kerberos 5 ticket.

Note that in this process, the session key contained inside of the original Kerberos 5 ticket must be a single DES key. The krb524 daemon will not create a new session key; instead, it only copies the session key from the current ticket to a new Kerberos 4 ticket. Since Kerberos 4 can only handle single DES key types, this session key must be a single DES key.

Also, the machine that runs the krb524 daemon does not necessarily have to be a Kerberos KDC. The krb524 daemon does, however, need access to the secret key of the Kerberos 4 services involved. This can be accomplished if the krb524 daemon is running on the same machine as one of the Kerberos KDCs. However, if this is not possible, for example, if your KDC is a Windows domain controller that does not support Kerberos 5-to-4 ticket translation, then the krb524 daemon can be run on a separate machine. The service keys for any Kerberos 4 services can be extracted to a keytab located on the machine running the krb524 daemon, so that it can decrypt the Kerberos 5 tickets and create a new Kerberos 4 ticket for the service.

3.3.6 Pre-Authentication

The original Kerberos 4 protocol was susceptible to offline dictionary and brute-force attacks, as we'll see in Chapter 6. This vulnerability stems from the fact that the KDC issues an encrypted TGT to any client for any principal (given that the requested principal exists in the Kerberos database). Since the KDC happily provides a ticket encrypted with the principals' secret key to any requestor, an offline attack can be mounted to determine the principal's secret key. This vulnerability is exacerbated by the fact that users typically choose poor passwords.

To make this attack more difficult, Kerberos 5 introduces pre-authentication (see Figure 3-11). Pre-authentication requires that requestors prove their identity before the KDC will issue a ticket for a particular principal. There are several types of pre-authentication defined by the Kerberos Clarifications document. However, only the encrypted timestamp (PA-ENC-TIMESTAMP) pre-authentication method is commonly implemented.

Figure 3-11. AS exchange with pre-authentication

Pre-authentication is controlled by KDC policy. If a user attempts to acquire initial tickets through the AS exchange, but the KDC requires pre-authentication, then the KDC will send a KRB_ERROR message instead of an AS_REP in reply to the client's AS request. This KRB_ERROR message tells the client that pre-authentication is required. The client generates the requisite pre-authentication data, and resends its AS_REQ message with the pre-authentication data appended. If the pre-authentication data is accepted by the KDC, it responds with an AS reply that includes the client's initial ticket. Otherwise, the KDC will return another KRB_ERROR message that indicates pre-authentication failed, and the client will not receive an initial Ticket Granting Ticket.

We'll explore the practical security aspects of pre-authentication in more detail in Chapter 6.

3.3.7 Other Protocol Features and Extensions

There are also several useful extensions that are currently on the standards track to enhance Kerberos. Two such proposals, so-called PKINIT and PKCROSS, introduce public-key encryption to strengthen the initial authentication of the user to the KDC, and cross-realm authentication, respectively. These proposals are not standardized yet, but some early implementations are already available. We'll see what benefits PKINIT and PKCROSS give over the standard initial authentication and cross realm capabilities built into the current Kerberos standard in Chapter 10.

3.3.8 String-to-Key Transformation

Just like Kerberos 4, Kerberos 5 requires a function that serves to transform a human-readable string password into an encryption key for internal use. However, Kerberos 5 makes several changes to this process, the most important resulting from the fact that Kerberos 5 supports any number of encryption algorithms with arbitrary key sizes. In addition, Kerberos 5 enforces the use of a salt, a piece of data added to the user's password in order to make it more resistant to brute force. Typically, this salt is the complete principal name—but other salts can be specified by the KDC.

3.3.9 Password Changing

The current status of password-changing protocols in Kerberos 5 is similar to that of Kerberos 4; unfortunately, as in Kerberos 4, password changing has been treated as an afterthought. The original Kerberos 5 specifications, as defined by RFC 1510, do not define a means by which clients can change their own passwords. Older implementations of MIT Kerberos 5 used the administrative protocol to perform password changes, but this is not interoperable between implementations as every implementation uses a different administrative protocol. A standard protocol for Kerberos 5 password changing was proposed as an Internet draft in 1998, referred to as the Horowitz password-changing protocol. The newer versions of MIT (1.2 and above) and Heimdal Kerberos, as well as the Windows 2000 and 2003 based Active Directory, support the Horowitz password-changing protocol. Other implementations, such as Solaris' SEAM, do not support this protocol and therefore are not interoperable with any other implementation for password changes.

A new draft proposal is now being discussed to replace the Horowitz password-changing protocol. This proposal, the Kerberos Set/Change Password Version 2, is the current Internet Draft proposal for Kerberos password changing. This new proposal has several advantages over the Horowitz password-changing protocol. First, it provides the capability for administrators to reset other users' passwords, as well as allowing users to change their own passwords. Additionally, this proposal allows for more fine-grained information to be returned to the client in the case of a rejected password. Since this proposal is still in development, readers interested in the details of the new Kerberos Set/Change Password Version 2 protocol can find more information at http://www.kerberos.isi.edu.