This document describes an extension to the rxkad security module which adds a new type of authentication token based on the Kerberos protocol version 5 (defined in RFC1510 and its successors). The new token format, called ``proposal 2b'', is designed to be fully compatible with existing rxkad-capable clients. New tokens can be constructed by clients from standard Kerberos version 5 tickets, or provided in place of ordinary Kerberos version 4 tickets by a v5-to-v4 translation service such as that supported by the MIT and Heimdal KDC implementations.
An rxkad 2b token differs from normal tokens in two major respects. The first is in the format of the encrypted token data, and the second is in the kvno associated with each token. Both of these differences are completely transparent to rxkad clients; they are of importance only to the rxkad server and to the entity which creates the token. Note that the format of the 56-bit DES session encryption key does not change; this is important in maintaining compatibility with existing clients.
The first major difference between rxkad 2b tokens and traditional rxkad tokens is in the format of the encrypted ``token data''. In a traditional token, this data consists of a Kerberos version 4 ticket, encrypted in the server's secret key. Since this key is not known to the client, the entire token data is opaque to clients, and must be transmitted as-is.
An rxkad 2b token takes the form of the enc-part field from a Kerberos version 5 ticket. It is encoded as described for the EncryptedData type in section 6.1 of RFC1510, including the enclosing ASN.1 tag; this encoding was chosen to allow rxkad 2b tokens to be constructed simply by extracting the enc-part field from an existing ticket.
It is intended that existing rxkad client software be able to make use of rxkad 2b tokens (given them by some part of the authentication system) without modification. In order to preserve this feature and insure interoperability, certain restrictions are placed on the properties of the ticket used to construct an rxkad 2b token:
The second major difference between rxkad 2b tokens and traditional rxkad tokens is in the ``key version number'' associated with the token. This value traditionally carries the version number associated with the service key used to encrypt the Kerberos v4 ticket, which is used by the server to look up the correct key with which to decrypt the ticket.
As with previous extensions which have added new types of authentication tokens, rxkad 2b overloads the kvno field to identify a token type. An rxkad 2b token must be associated with the magic kvno value 213 (0xd5). This value was chosen fairly arbitrarily, subject to the constraint that it be within the 0-255 range supported in Kerberos version 4, so that it would be possible to issue rxkad 2b tokens to existing clients via a modified krb524 translation service. Within that constraint, the value 0xd5 was chosen in the hopes that it would be relatively unlikely to appear as the version of an existing Kerberos version 4 service key, and because it is the inverse of 0x2b.
Because the kvno field is overloaded to identify the token type, it is not possible to use it to represent the actual version of the service key used to encrypt the ticket. Instead, it is stored as part of the EncryptedData wrapper in the token itself, which contains information needed by the server in order to decrypt the ticket.
An rxkad server supporting this extension MUST be capable of receiving and correctly decoding both traditional Kerberos version 4 tickets and rxkad 2b tokens as described in this document; however, an implementation SHOULD allow support for traditional Kerberos version 4 tickets to be disabled as a matter of local policy. In addition, such a server MUST support standard Kerberos version 5 tickets, identified by the magic kvno 256, as described in rxkad-v5.
When an rxkad server supporting this extension receives a challenge response containing the magic kvno value 213, it is likely that the token contained in the response is in the rxkad 2b format described in this documentation; however, it is also possible that the token is a traditional Kerberos version 4 ticket with a service key version of 213. Therefore, a server receiving a token with kvno 213 MUST first try to process the token according to this document.
If the server is unable to decode the token as an rxkad 2b token, it MAY then attempt to decode the token as a traditional Kerberos version 4 ticket. This order is REQUIRED -- servers MUST NOT treat a token having kvno 213 as a Kerberos version 4 ticket before attempting and failing to decode it as an rxkad 2b token.
The Kerberos version 5 ticket format provides a number of new fields and features not found in the Kerberos version 4 tickets traditionally used by rxkad. These fields are to be handled as follows:
Implementation note: Because authorization data may contain restrictions on how a ticket may be used, Kerberos specifies that it must be treated as ``critical''; that is, a server must reject a ticket which contains any authorization data it does not understand. Ideally, rxkad should follow this rule, as indicated in the paragraph above. In practice, existing rxkad implementations currently ignore authorization data entirely.
The rxkad 2b token format is designed to be completely compatible with all existing rxkad clients. Thus, in order to take advantage of the new token format, all that is necessary is to obtain an rxkad 2b token from the authentication service. There are two primary methods by which this can be accomplished: they can generated from a standard Kerberos version 5 ticket by a client utility, or they can be obtained via the Kerberos 5-to-4 translation service (krb524d).
A client utility will generally be able to construct an rxkad 2b token directly from an appropriate Kerberos version 5 ticket. This is only possible if the ticket meets the requirements listed above for rxkad 2b tokens, with regard to length and encryption types used. Provided these requirements are met, the client can simply extract the encoded form of the enc-part field from the ticket, and use it as an rxkad 2b token.
Many existing clients obtain rxkad tokens via the Kerberos 5-to-4 translation service, which accepts a Kerberos version 5 ticket and returns a corresponding Kerberos version 4 ticket. In cases where the krb524 service knows that the servers which will process the token are capable of handling rxkad 2b tokens, it may choose to return an rxkad 2b token instead of a traditional Kerberos version 4 ticket.
When the krb524 service chooses to return an rxkad 2b token, it can simply perform the same transformation described above for clients; this approach has the advantage that it does not require the translation service to know the service key.
However, the translation service MAY instead choose to decrypt the ticket and modify it in order to make it conform to the restrictions for rxkad 2b tokens. For example, it may check and strip out unnecessary authorization data, remove client addresses, and check the transited realm list. It may also reencrypt the token in a different service key known to the service; for example, this would allow handling of Kerberos version 5 tickets which use a non-DES service key. The translation service MUST NOT change the session key or encryption type, since there would be no way to communicate such a change to the client.
When the translation service returns an rxkad 2b token, it MUST set the returned kvno to the magic value 213 (0xd5), as described above.
This document extends the rxkad security module by adding a new token format. The new token format is based on a Kerberos version 5 ticket; therefore, some of the same issues which apply to Kerberos apply here. In addition, the rxkad 2b token format places additional restrictions on the ticket beyond those present in Kerberos; particularly, it limits the encryption types that may be used for service and session keys. These restrictions may impact the level of security available.
This document is an extension to rxkad, and thus is subject to several security issues affecting rxkad which are not addressed by this document. These include:
rxkad rxkad-v5 rfc1510 mit kerberos heimdal
Copyright (c) 2003, Jeffrey Hutzelman. All rights reserved.
This document may be copied and redistributed, provided that the above copyright notice and this permission notice are preserved. However, it may not be modified in any way.