From eed9f58be4565853ded3b6345e49563f69f670bf Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Love=20H=C3=B6rnquist=20=C3=85strand?= Date: Sun, 12 Nov 2006 17:00:26 +0000 Subject: [PATCH] x git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@18995 ec53bebd-3082-4978-b11e-865c3cabbd6b --- ...draft-ietf-krb-wg-preauth-framework-04.txt | 1830 +++++ .../draft-ietf-krb-wg-rfc1510ter-03.txt | 6217 +++++++++++++++++ .../draft-josefsson-kerberos5-starttls-00.txt | 447 ++ .../draft-josefsson-kerberos5-starttls-01.txt | 672 ++ .../draft-josefsson-kerberos5-starttls-02.txt | 672 ++ .../draft-richards-otp-kerberos-01.txt | 1232 ++++ ...-sakane-krb-cross-problem-statement-01.txt | 731 ++ 7 files changed, 11801 insertions(+) create mode 100644 doc/standardisation/draft-ietf-krb-wg-preauth-framework-04.txt create mode 100644 doc/standardisation/draft-ietf-krb-wg-rfc1510ter-03.txt create mode 100644 doc/standardisation/draft-josefsson-kerberos5-starttls-00.txt create mode 100644 doc/standardisation/draft-josefsson-kerberos5-starttls-01.txt create mode 100644 doc/standardisation/draft-josefsson-kerberos5-starttls-02.txt create mode 100644 doc/standardisation/draft-richards-otp-kerberos-01.txt create mode 100644 doc/standardisation/draft-sakane-krb-cross-problem-statement-01.txt diff --git a/doc/standardisation/draft-ietf-krb-wg-preauth-framework-04.txt b/doc/standardisation/draft-ietf-krb-wg-preauth-framework-04.txt new file mode 100644 index 000000000..2354a5926 --- /dev/null +++ b/doc/standardisation/draft-ietf-krb-wg-preauth-framework-04.txt @@ -0,0 +1,1830 @@ + + +Kerberos Working Group L. Zhu +Internet-Draft Microsoft Corporation +Updates: 4120 (if approved) S. Hartman +Intended status: Standards Track MIT +Expires: April 28, 2007 October 25, 2006 + + + A Generalized Framework for Kerberos Pre-Authentication + draft-ietf-krb-wg-preauth-framework-04 + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on April 28, 2007. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + Kerberos is a protocol for verifying the identity of principals + (e.g., a workstation user or a network server) on an open network. + The Kerberos protocol provides a mechanism called pre-authentication + for proving the identity of a principal and for better protecting the + long-term secret of the principal. + + This document describes a model for Kerberos pre-authentication + + + +Zhu & Hartman Expires April 28, 2007 [Page 1] + +Internet-Draft Kerberos Preauth Framework October 2006 + + + mechanisms. The model describes what state in the Kerberos request a + pre-authentication mechanism is likely to change. It also describes + how multiple pre-authentication mechanisms used in the same request + will interact. + + This document also provides common tools needed by multiple pre- + authentication mechanisms. One of such tools is a secure channel + between the client and the KDC with a reply key delivery mechanism, + this secure channel can be used to protect the authentication + exchange thus eliminate offline dictionary attacks. With these + tools, it is straightforward to chain multiple authentication factors + or add a plugin to, for example, utilize a different key management + system, or support a new key agreement algorithm. + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Conventions Used in This Document . . . . . . . . . . . . . . 5 + 3. Model for Pre-Authentication . . . . . . . . . . . . . . . . . 5 + 3.1. Information Managed by the Pre-authentication Model . . . 6 + 3.2. Initial Pre-authentication Required Error . . . . . . . . 8 + 3.3. Client to KDC . . . . . . . . . . . . . . . . . . . . . . 9 + 3.4. KDC to Client . . . . . . . . . . . . . . . . . . . . . . 10 + 4. Pre-Authentication Facilities . . . . . . . . . . . . . . . . 11 + 4.1. Client-authentication Facility . . . . . . . . . . . . . . 12 + 4.2. Strengthening-reply-key Facility . . . . . . . . . . . . . 12 + 4.3. Replacing-reply-key Facility . . . . . . . . . . . . . . . 13 + 4.4. KDC-authentication Facility . . . . . . . . . . . . . . . 14 + 5. Requirements for Pre-Authentication Mechanisms . . . . . . . . 14 + 6. Tools for Use in Pre-Authentication Mechanisms . . . . . . . . 15 + 6.1. Combining Keys . . . . . . . . . . . . . . . . . . . . . . 15 + 6.2. Protecting Requests/Responses . . . . . . . . . . . . . . 17 + 6.3. Managing States for the KDC . . . . . . . . . . . . . . . 17 + 6.4. Pre-authentication Set . . . . . . . . . . . . . . . . . . 18 + 6.5. Definition of Kerberos FAST Padata . . . . . . . . . . . . 19 + 6.5.1. FAST Armors . . . . . . . . . . . . . . . . . . . . . 20 + 6.5.2. FAST Request . . . . . . . . . . . . . . . . . . . . . 21 + 6.5.3. FAST Response . . . . . . . . . . . . . . . . . . . . 24 + 6.6. Authentication Strength Indication . . . . . . . . . . . . 27 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 28 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 28 + Appendix A. ASN.1 module . . . . . . . . . . . . . . . . . . . . 28 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 + + + +Zhu & Hartman Expires April 28, 2007 [Page 2] + +Internet-Draft Kerberos Preauth Framework October 2006 + + + Intellectual Property and Copyright Statements . . . . . . . . . . 32 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zhu & Hartman Expires April 28, 2007 [Page 3] + +Internet-Draft Kerberos Preauth Framework October 2006 + + +1. Introduction + + The core Kerberos specification [RFC4120] treats pre-authentication + data as an opaque typed hole in the messages to the KDC that may + influence the reply key used to encrypt the KDC reply. This + generality has been useful: pre-authentication data is used for a + variety of extensions to the protocol, many outside the expectations + of the initial designers. However, this generality makes designing + more common types of pre-authentication mechanisms difficult. Each + mechanism needs to specify how it interacts with other mechanisms. + Also, problems like combining a key with the long-term secret or + proving the identity of the user are common to multiple mechanisms. + Where there are generally well-accepted solutions to these problems, + it is desirable to standardize one of these solutions so mechanisms + can avoid duplication of work. In other cases, a modular approach to + these problems is appropriated. The modular approach will allow new + and better solutions to common pre-authentication problems to be used + by existing mechanisms as they are developed. + + This document specifies a framework for Kerberos pre-authentication + mechanisms. It defines the common set of functions pre- + authentication mechanisms perform as well as how these functions + affect the state of the request and reply. In addition several + common tools needed by pre-authentication mechanisms are provided. + Unlike [RFC3961], this framework is not complete--it does not + describe all the inputs and outputs for the pre-authentication + mechanisms. Pre-Authentication mechanism designers should try to be + consistent with this framework because doing so will make their + mechanisms easier to implement. Kerberos implementations are likely + to have plugin architectures for pre-authentication; such + architectures are likely to support mechanisms that follow this + framework plus commonly used extensions. + + One of these common tools is the flexible authentication secure + tunneling (FAST) padata. FAST provides a protected channel between + the client and the KDC, and it also delivers a reply key within the + protected channel. Based on FAST, pre-authentication mechanisms can + extend Kerberos with ease, to support, for example, password + authenticated key exchange (PAKE) protocols with zero knowledge + password proof (ZKPP) [EKE] [IEEE1363.2]. Any pre-authentication + mechanism can be encapsulated in the padata field Section 6.5 of + FAST. A pre-authentication type thus carried within FAST is called a + FAST factor. A FAST factor MUST NOT be used outside of FAST unless + its specification explicitly allows so. Note that FAST without a + FAST factor for authentication does NOT by itself authenticate the + client or the KDC. + + New pre-authentication mechanisms SHOULD design FAST factors, instead + + + +Zhu & Hartman Expires April 28, 2007 [Page 4] + +Internet-Draft Kerberos Preauth Framework October 2006 + + + of full-blown pre-authentication mechanisms. + + A conversation consists of all messages that are necessary to + complete the mutual authentication between the client and the KDC. A + conversation is the smallest logic unit for messages exchanged + between the client and the KDC. The KDC need to manage mulitple + authentication sets frequently need to keep track of KDC states + during a convesation, standard solutions are provided for these + common problems. + + This document should be read only after reading the documents + describing the Kerberos cryptography framework [RFC3961] and the core + Kerberos protocol [RFC4120]. This document freely uses terminology + and notation from these documents without reference or further + explanation. + + +2. Conventions Used in This Document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + The word padata is used as the shorthand of pre-authentication data. + A conversation is used to refer to all authentication messages + exchanged between the client and the KDC. + + +3. Model for Pre-Authentication + + When a Kerberos client wishes to obtain a ticket using the + authentication server, it sends an initial Authentication Service + (AS) request. If pre-authentication is required but not being used, + then the KDC will respond with a KDC_ERR_PREAUTH_REQUIRED error. + Alternatively, if the client knows what pre-authentication to use, it + MAY optimize away a round-trip and send an initial request with + padata included in the initial request. If the client includes the + wrong padata, the KDC MAY return KDC_ERR_PREAUTH_FAILED with no + indication of what padata should have been included. In that case, + the client MUST retry with no padata and examine the error data of + the KDC_ERR_PREAUTH_REQUIRED error. If the KDC includes pre- + authentication information in the accompanying error data of + KDC_ERR_PREAUTH_FAILED, the client SHOULD process the error data as + that of the KDC_ERR_PREAUTH_REQUIRED error, and then retry. + + The conventional KDC maintains no state between two requests; + subsequent requests may even be processed by a different KDC. On the + other hand, the client treats a series of exchanges with KDCs as a + + + +Zhu & Hartman Expires April 28, 2007 [Page 5] + +Internet-Draft Kerberos Preauth Framework October 2006 + + + single authentication session. Each exchange accumulates state and + hopefully brings the client closer to a successful authentication. + + These models for state management are in apparent conflict. For many + of the simpler pre-authentication scenarios, the client uses one + round trip to find out what mechanisms the KDC supports. Then the + next request contains sufficient pre-authentication for the KDC to be + able to return a successful reply. For these simple scenarios, the + client only sends one request with pre-authentication data and so the + authentication session is trivial. For more complex authentication + sessions, the KDC needs to provide the client with a cookie to + include in future requests to capture the current state of the + authentication session. Handling of multiple round-trip mechanisms + is discussed in Section 6.3. + + This framework specifies the behavior of Kerberos pre-authentication + mechanisms used to identify users or to modify the reply key used to + encrypt the KDC reply. The PA-DATA typed hole may be used to carry + extensions to Kerberos that have nothing to do with proving the + identity of the user or establishing a reply key. Such extensions + are outside the scope of this framework. However mechanisms that do + accomplish these goals should follow this framework. + + This framework specifies the minimum state that a Kerberos + implementation needs to maintain while handling a request in order to + process pre-authentication. It also specifies how Kerberos + implementations process the padata at each step of the AS request + process. + +3.1. Information Managed by the Pre-authentication Model + + The following information is maintained by the client and KDC as each + request is being processed: + + o The reply key used to encrypt the KDC reply + + o How strongly the identity of the client has been authenticated + + o Whether the reply key has been used in this authentication session + + o Whether the reply key has been replaced in this authentication + session + + o Whether the contents of the KDC reply can be verified by the + client principal + + + + + + +Zhu & Hartman Expires April 28, 2007 [Page 6] + +Internet-Draft Kerberos Preauth Framework October 2006 + + + o Whether the contents of the KDC reply can be verified by the + client machine + + Conceptually, the reply key is initially the long-term key of the + principal. However, principals can have multiple long-term keys + because of support for multiple encryption types, salts and + string2key parameters. As described in section 5.2.7.5 of the + Kerberos protocol [RFC4120], the KDC sends PA-ETYPE-INFO2 to notify + the client what types of keys are available. Thus in full + generality, the reply key in the pre-authentication model is actually + a set of keys. At the beginning of a request, it is initialized to + the set of long-term keys advertised in the PA-ETYPE-INFO2 element on + the KDC. If multiple reply keys are available, the client chooses + which one to use. Thus the client does not need to treat the reply + key as a set. At the beginning of a handling a request, the client + picks a reply key to use. + + KDC implementations MAY choose to offer only one key in the PA-ETYPE- + INFO2 element. Since the KDC already knows the client's list of + supported enctypes from the request, no interoperability problems are + created by choosing a single possible reply key. This way, the KDC + implementation avoids the complexity of treating the reply key as a + set. + + When the padata in the request is verified by the KDC, then the + client is known to have that key, therefore the KDC SHOULD pick the + same key as the reply key. + + At the beginning of handling a message on both the client and the + KDC, the client's identity is not authenticated. A mechanism may + indicate that it has successfully authenticated the client's + identity. This information is useful to keep track of on the client + in order to know what pre-authentication mechanisms should be used. + The KDC needs to keep track of whether the client is authenticated + because the primary purpose of pre-authentication is to authenticate + the client identity before issuing a ticket. The handling of + authentication strength using various authentication mechanisms is + discussed in Section 6.6. + + Initially the reply key has not been used. A pre-authentication + mechanism that uses the reply key either directly to encrypt or + checksum some data or indirectly in the generation of new keys MUST + indicate that the reply key is used. This state is maintained by the + client and the KDC to enforce the security requirement stated in + Section 4.3 that the reply key cannot be used after it is replaced. + + Initially the reply key has not been replaced. If a mechanism + implements the Replace Reply Key facility discussed in Section 4.3, + + + +Zhu & Hartman Expires April 28, 2007 [Page 7] + +Internet-Draft Kerberos Preauth Framework October 2006 + + + then the state MUST be updated to indicate that the reply key has + been replaced. Once the reply key has been replaced, knowledge of + the reply key is insufficient to authenticate the client. The reply + key is marked replaced in exactly the same situations as the KDC + reply is marked as not being verified to the client principal. + However, while mechanisms can verify the KDC reply to the client, + once the reply key is replaced, then the reply key remains replaced + for the remainder of the authentication session. + + Without pre-authentication, the client knows that the KDC reply is + authentic and has not been modified because it is encrypted in a + long-term key of the client. Only the KDC and the client know that + key. So at the start of handling any message the KDC reply is + presumed to be verified using the client principal's long-term key. + Any pre-authentication mechanism that sets a new reply key not based + on the principal's long-term secret MUST either verify the KDC reply + some other way or indicate that the reply is not verified. If a + mechanism indicates that the reply is not verified then the client + implementation MUST return an error unless a subsequent mechanism + verifies the reply. The KDC needs to track this state so it can + avoid generating a reply that is not verified. + + The typical Kerberos request does not provide a way for the client + machine to know that it is talking to the correct KDC. Someone who + can inject packets into the network between the client machine and + the KDC and who knows the password that the user will give to the + client machine can generate a KDC reply that will decrypt properly. + So, if the client machine needs to authenticate that the user is in + fact the named principal, then the client machine needs to do a TGS + request for itself as a service. Some pre-authentication mechanisms + may provide a way for the client to authenticate the KDC. Examples + of this include signing the reply with a well-known public key or + providing a ticket for the client machine as a service in addition to + the requested ticket. + +3.2. Initial Pre-authentication Required Error + + Typically a client starts an authentication session by sending an + initial request with no pre-authentication. If the KDC requires pre- + authentication, then it returns a KDC_ERR_PREAUTH_REQUIRED message. + After the first reply with the KDC_ERR_PREAUTH_REQUIRED error code, + the KDC returns the error code KDC_ERR_MORE_PREAUTH_DATA_NEEDED for + pre-authentication configurations that use multi-round-trip + mechanisms; see Section 3.4 for details of that case. + + The KDC needs to choose which mechanisms to offer the client. The + client needs to be able to choose what mechanisms to use from the + first message. For example consider the KDC that will accept + + + +Zhu & Hartman Expires April 28, 2007 [Page 8] + +Internet-Draft Kerberos Preauth Framework October 2006 + + + mechanism A followed by mechanism B or alternatively the single + mechanism C. A client that supports A and C needs to know that it + should not bother trying A. + + Mechanisms can either be sufficient on their own or can be part of an + authentication set--a group of mechanisms that all need to + successfully complete in order to authenticate a client. Some + mechanisms may only be useful in authentication sets; others may be + useful alone or in authentication sets. For the second group of + mechanisms, KDC policy dictates whether the mechanism will be part of + an authentication set or offered alone. For each mechanism that is + offered alone, the KDC includes the pre-authentication type ID of the + mechanism in the padata sequence returned in the + KDC_ERR_PREAUTH_REQUIRED error. + + The KDC SHOULD NOT send data that is encrypted in the long-term + password-based key of the principal. Doing so has the same security + exposures as the Kerberos protocol without pre-authentication. There + are few situations where pre-authentication is desirable and where + the KDC needs to expose cipher text encrypted in a weak key before + the client has proven knowledge of that key. + +3.3. Client to KDC + + This description assumes a client has already received a + KDC_ERR_PREAUTH_REQUIRED from the KDC. If the client performs + optimistic pre-authentication then the client needs to optimistically + choose the information it would normally receive from that error + response. + + The client starts by initializing the pre-authentication state as + specified. It then processes the padata in the + KDC_ERR_PREAUTH_REQUIRED. + + When processing the response to the KDC_ERR_PREAUTH_REQUIRED, the + client MAY ignore any padata it chooses unless doing so violates a + specification to which the client conforms. Clients MUST NOT ignore + the padata defined in Section 6.3. Clients SHOULD process padata + unrelated to this framework or other means of authenticating the + user. Clients SHOULD choose one authentication set or mechanism that + could lead to authenticating the user and ignore the rest. Since the + list of mechanisms offered by the KDC is in the decreasing preference + order, clients typically choose the first mechanism that the client + can usefully perform. If a client chooses to ignore a padata it MUST + NOT process the padata, allow the padata to affect the pre- + authentication state, nor respond to the padata. + + For each padata the client chooses to process, the client processes + + + +Zhu & Hartman Expires April 28, 2007 [Page 9] + +Internet-Draft Kerberos Preauth Framework October 2006 + + + the padata and modifies the pre-authentication state as required by + that mechanism. Padata are processed in the order received from the + KDC. + + After processing the padata in the KDC error, the client generates a + new request. It processes the pre-authentication mechanisms in the + order in which they will appear in the next request, updating the + state as appropriate. The request is sent when it is complete. + +3.4. KDC to Client + + When a KDC receives an AS request from a client, it needs to + determine whether it will respond with an error or a AS reply. There + are many causes for an error to be generated that have nothing to do + with pre-authentication; they are discussed in the core Kerberos + specification. + + From the standpoint of evaluating the pre-authentication, the KDC + first starts by initializing the pre-authentication state. It then + processes the padata in the request. As mentioned in Section 3.3, + the KDC MAY ignore padata that is inappropriate for the configuration + and MUST ignore padata of an unknown type. + + At this point the KDC decides whether it will issue a pre- + authentication required error or a reply. Typically a KDC will issue + a reply if the client's identity has been authenticated to a + sufficient degree. + + In the case of a KDC_ERR_PREAUTH_REQUIRED error, the KDC first starts + by initializing the pre-authentication state. Then it processes any + padata in the client's request in the order provided by the client. + Mechanisms that are not understood by the KDC are ignored. + Mechanisms that are inappropriate for the client principal or the + request SHOULD also be ignored. Next, it generates padata for the + error response, modifying the pre-authentication state appropriately + as each mechanism is processed. The KDC chooses the order in which + it will generate padata (and thus the order of padata in the + response), but it needs to modify the pre-authentication state + consistently with the choice of order. For example, if some + mechanism establishes an authenticated client identity, then the + subsequent mechanisms in the generated response receive this state as + input. After the padata is generated, the error response is sent. + Typically the errors with the code KDC_ERR_MORE_PREAUTH_DATA_NEEDED + in a converstation will include KDC state as discussed in + Section 6.3. + + To generate a final reply, the KDC generates the padata modifying the + pre-authentication state as necessary. Then it generates the final + + + +Zhu & Hartman Expires April 28, 2007 [Page 10] + +Internet-Draft Kerberos Preauth Framework October 2006 + + + response, encrypting it in the current pre-authentication reply key. + + +4. Pre-Authentication Facilities + + Pre-Authentication mechanisms can be thought of as providing various + conceptual facilities. This serves two useful purposes. First, + mechanism authors can choose only to solve one specific small + problem. It is often useful for a mechanism designed to offer key + management not to directly provide client authentication but instead + to allow one or more other mechanisms to handle this need. Secondly, + thinking about the abstract services that a mechanism provides yields + a minimum set of security requirements that all mechanisms providing + that facility must meet. These security requirements are not + complete; mechanisms will have additional security requirements based + on the specific protocol they employ. + + A mechanism is not constrained to only offering one of these + facilities. While such mechanisms can be designed and are sometimes + useful, many pre-authentication mechanisms implement several + facilities. By combining multiple facilities in a single mechanism, + it is often easier to construct a secure, simple solution than by + solving the problem in full generality. Even when mechanisms provide + multiple facilities, they need to meet the security requirements for + all the facilities they provide. + + According to Kerberos extensibility rules (Section 1.5 of the + Kerberos specification [RFC4120]), an extension MUST NOT change the + semantics of a message unless a recipient is known to understand that + extension. Because a client does not know that the KDC supports a + particular pre-authentication mechanism when it sends an initial + request, a pre-authentication mechanism MUST NOT change the semantics + of the request in a way that will break a KDC that does not + understand that mechanism. Similarly, KDCs MUST not send messages to + clients that affect the core semantics unless the client has + indicated support for the message. + + The only state in this model that would break the interpretation of a + message is changing the expected reply key. If one mechanism changed + the reply key and a later mechanism used that reply key, then a KDC + that interpreted the second mechanism but not the first would fail to + interpret the request correctly. In order to avoid this problem, + extensions that change core semantics are typically divided into two + parts. The first part proposes a change to the core semantic--for + example proposes a new reply key. The second part acknowledges that + the extension is understood and that the change takes effect. + Section 4.2 discusses how to design mechanisms that modify the reply + key to be split into a proposal and acceptance without requiring + + + +Zhu & Hartman Expires April 28, 2007 [Page 11] + +Internet-Draft Kerberos Preauth Framework October 2006 + + + additional round trips to use the new reply key in subsequent pre- + authentication. Other changes in the state described in Section 3.1 + can safely be ignored by a KDC that does not understand a mechanism. + Mechanisms that modify the behavior of the request outside the scope + of this framework need to carefully consider the Kerberos + extensibility rules to avoid similar problems. + +4.1. Client-authentication Facility + + The client authentication facility proves the identity of a user to + the KDC before a ticket is issued. Examples of mechanisms + implementing this facility include the encrypted timestamp facility + defined in Section 5.2.7.2 of the Kerberos specification [RFC4120]. + Mechanisms that provide this facility are expected to mark the client + as authenticated. + + Mechanisms implementing this facility SHOULD require the client to + prove knowledge of the reply key before transmitting a successful KDC + reply. Otherwise, an attacker can intercept the pre-authentication + exchange and get a reply to attack. One way of proving the client + knows the reply key is to implement the Replace Reply Key facility + along with this facility. The PKINIT mechanism [RFC4556] implements + Client Authentication alongside Replace Reply Key. + + If the reply key has been replaced, then mechanisms such as + encrypted-timestamp that rely on knowledge of the reply key to + authenticate the client MUST NOT be used. + +4.2. Strengthening-reply-key Facility + + Particularly, when dealing with keys based on passwords, it is + desirable to increase the strength of the key by adding additional + secrets to it. Examples of sources of additional secrets include the + results of a Diffie-Hellman key exchange or key bits from the output + of a smart card [RFC4556]. Typically these additional secrets can be + first combined with the existing reply key and then converted to a + protocol key using tools defined in Section 6.1. + + If a mechanism implementing this facility wishes to modify the reply + key before knowing that the other party in the exchange supports the + mechanism, it proposes modifying the reply key. The other party then + includes a message indicating that the proposal is accepted if it is + understood and meets policy. In many cases it is desirable to use + the new reply key for client authentication and for other facilities. + Waiting for the other party to accept the proposal and actually + modify the reply key state would add an additional round trip to the + exchange. Instead, mechanism designers are encouraged to include a + typed hole for additional padata in the message that proposes the + + + +Zhu & Hartman Expires April 28, 2007 [Page 12] + +Internet-Draft Kerberos Preauth Framework October 2006 + + + reply key change. The padata included in the typed hole are + generated assuming the new reply key. If the other party accepts the + proposal, then these padata are interpreted as if they were included + immediately following the proposal. The party generating the + proposal can determine whether the padata were processed based on + whether the proposal for the reply key is accepted. + + The specific formats of the proposal message, including where padata + are are included is a matter for the mechanism specification. + Similarly, the format of the message accepting the proposal is + mechanism-specific. + + Mechanisms implementing this facility and including a typed hole for + additional padata MUST checksum that padata using a keyed checksum or + encrypt the padata. Typically the reply key is used to protect the + padata. If you are only minimally increasing the strength of the + reply key, this may give the attacker access to something too close + to the original reply key. However, binding the padata to the new + reply key seems potentially important from a security standpoint. + There may also be objections to this from a double encryption + standpoint because we also recommend client authentication facilities + be tied to the reply key. + +4.3. Replacing-reply-key Facility + + The Replace Reply Key facility replaces the key in which a successful + AS reply will be encrypted. This facility can only be used in cases + where knowledge of the reply key is not used to authenticate the + client. The new reply key MUST be communicated to the client and the + KDC in a secure manner. Mechanisms implementing this facility MUST + mark the reply key as replaced in the pre-authentication state. + Mechanisms implementing this facility MUST either provide a mechanism + to verify the KDC reply to the client or mark the reply as unverified + in the pre-authentication state. Mechanisms implementing this + facility SHOULD NOT be used if a previous mechanism has used the + reply key. + + As with the strengthening-reply-key facility, Kerberos extensibility + rules require that the reply key not be changed unless both sides of + the exchange understand the extension. In the case of this facility + it will likely be more common for both sides to know that the + facility is available by the time that the new key is available to be + used. However, mechanism designers can use a container for padata in + a proposal message as discussed in Section 4.2 if appropriate. + + + + + + + +Zhu & Hartman Expires April 28, 2007 [Page 13] + +Internet-Draft Kerberos Preauth Framework October 2006 + + +4.4. KDC-authentication Facility + + This facility verifies that the reply comes from the expected KDC. + In traditional Kerberos, the KDC and the client share a key, so if + the KDC reply can be decrypted then the client knows that a trusted + KDC responded. Note that the client machine cannot trust the client + unless the machine is presented with a service ticket for it + (typically the machine can retrieve this ticket by itself). However, + if the reply key is replaced, some mechanism is required to verify + the KDC. Pre-authentication mechanisms providing this facility allow + a client to determine that the expected KDC has responded even after + the reply key is replaced. They mark the pre-authentication state as + having been verified. + + +5. Requirements for Pre-Authentication Mechanisms + + This section lists requirements for specifications of pre- + authentication mechanisms. + + For each message in the pre-authentication mechanism, the + specification describes the pa-type value to be used and the contents + of the message. The processing of the message by the sender and + recipient is also specified. This specification needs to include all + modifications to the pre-authentication state. + + Generally mechanisms have a message that can be sent in the error + data of the KDC_ERR_PREAUTH_REQUIRED error message or in an + authentication set. If the client need information such as, for + example, trusted certificate authorities in order to determine if it + can use the mechanism, then this information should be in that + message. In addition, such mechanisms should also define a pa-hint + to be included in authentication sets. Often, the same information + included in the padata-value is appropriate to include in the pa- + hint. + + In order to ease security analysis the mechanism specification should + describe what facilities from this document are offered by the + mechanism. For each facility, the security consideration section of + the mechanism specification should show that the security + requirements of that facility are met. This requirement is + applicable to any FAST factor that is used in FAST to provide + authentication information. + + Significant problems have resulted in the specification of Kerberos + protocols because much of the KDC exchange is not protected against + authentication. The security considerations section should discuss + unauthenticated plaintext attacks. It should either show that + + + +Zhu & Hartman Expires April 28, 2007 [Page 14] + +Internet-Draft Kerberos Preauth Framework October 2006 + + + plaintext is protected or discuss what harm an attacker could do by + modifying the plaintext. It is generally acceptable for an attacker + to be able to cause the protocol negotiation to fail by modifying + plaintext. More significant attacks should be evaluated carefully. + + +6. Tools for Use in Pre-Authentication Mechanisms + + This section describes common tools needed by multiple pre- + authentication mechanisms. By using these tools mechanism designers + can use a modular approach to specify mechanism details and ease + security analysis. + +6.1. Combining Keys + + Frequently a weak key need to be combined with a stronger key before + use. For example, passwords are typically limited in size and + insufficiently random, therefore it is desirable to increase the + strength of the keys based on passwords by adding additional secrets + to it. Additional source of secrecy may come from hardware tokens. + + This section provides standard ways to combine two keys into one. + + KRB-FX-CF1() is defined to combine two pass-phrases. + + KRB-FX-CF1(UTF-8 string, UTF-8 string) -> (UTF-8 string) + KRB-FX-CF1(x, y) -> x || y + + Where || denotes concatenation. The strength of the final key is + roughly the total strength of the individual keys being combined. + + An example usage of KRB-FX-CF1() is when a device provides random but + short passwords, the password is often combined with a personal + identification number (PIN). The password and the PIN can be + combined using KRB-FX-CF1(). + + The function KRB-FX-CF2() produces a new key based on two existing + keys of the same enctype and it is base on a secure hash function and + the primitives encrypt(), random-to-key() and K-truncate() described + in [RFC3961]. + + KRB-FX-CF2(protocol key, protocol key, octet string) -> + (resulting key) + + The KRB-FX-CF2() function takes two protocol keys and an octet string + as input, and output a new key of the same enctype. + + + + + +Zhu & Hartman Expires April 28, 2007 [Page 15] + +Internet-Draft Kerberos Preauth Framework October 2006 + + + encrypt(B, initial-cipher-state, pepper) -> (state-1, cipher-text-1) + + encrypt(A, initial-cipher-state, pepper) -> (state-2, cipher-text-2) + + PRF+(H, cipher-text-1 | cipher-text-2) -> bitstring-1 + + K-truncate(cipher-text-1) -> bitstring-2 + + random-to-key(bitstring-2) -> final-key + + KRB-FX-CF2(A, B, pepper) -> final-key + + Where initial-cipher-state is defined in [RFC3961] and the key- + generation seed length K is specified by the enctype profile + [RFC3961]. The value of the parameter pepper is RECOMMENDED to be in + the form of contextID || SharedInfo per guidelines in [HKDF]. If the + value of pepper is too short for the encrypt() primitive, it MUST + first be padded with all zeroes to the next shortest length that + encryt() can operate on. PRF+() produces a bit-string of at least K + bits in length. + + H is the secure hash function associated with the enctype. An + example of a secure hash function is SHA-256 [SHA2]. + + This document updates [RFC3961] to associate a secure hash function + with every enctype. Unless otherwise specified by the enctype + specification, the associated hash function is SHA-256. The + associated hash function for hmac-sha1-96-aes256 is SHA-512 [SHA2]. + + encryption type etype associated hash function + -------------------------------------------------------------- + hmac-sha1-96-aes256 16 SHA-512 [SHA2] + + PRF+ is defined as follows: + + PRF+(secure hash function, octet string) -> (octet string) + + PRF+(H, shared-info) -> H( 1 || shared-info ) || + H( 2 || shared-info ) H ( 3 || shared-info ) || ... + + Where the counter value 1, 2, 3 and so on are encoded as a one-octet + integer. + + Mechanism designers MUST specify the pepper value when combining two + keys using KRB-FX-CF2(). + + + + + + +Zhu & Hartman Expires April 28, 2007 [Page 16] + +Internet-Draft Kerberos Preauth Framework October 2006 + + +6.2. Protecting Requests/Responses + + Mechanism designers SHOULD provide integrity protection of the + messages in a conversation whenever feasible + + Sensitive data MUST be encrypted when sent over the wire. Non- + sensitive data that have privacy implications are encouraged to be + encrypted as well. + + If there are more than one roundtrip for an authentication exchange, + mechanism designers SHOULD allow either the client or the KDC provide + a checksum of all the messages exchanged on the wire, that is then + verified by the receiver. + + Primitives defined in [RFC3961] are RECOMMENDED for integrity + protection and confidentiality. Mechanisms based on these primitives + have the benefit of crypto-agility provided by [RFC3961]. The + advantage afforded by crypto-agility is the ability to avoid a multi- + year standardization and deployment cycle to fix a problem specific + to a particular algorithm, when real attacks do arise against that + algorithm. + + New mechanisms MUST NOT be hard-wired to use a specific algorithm. + +6.3. Managing States for the KDC + + For any conversation that consists of more than two messages, the KDC + likely need to keep track of KDC states for incomplete authentication + exchanges and destroy the states of a conversation when the + authentication completes successful or fails, or the KDC times out. + When the KDC times out, the KDC returns an error message with the + code KDC_ERR_PREAUTH_TIMED_OUT. + + KDC_ERR_PREAUTH_TIMED_OUT TBA + + Upnon receipt of this error, the client MUST abort the existing + conversation, and restart a new one. + + An example, where more than one message from the client is needed, is + when the client is authenticated based on a challenge-response + scheme. In that case, the KDC need to keep track of the challenge + issued for a client authentication request. + + The PA-FX-COOKIE pdata type is defined in this section to facilitate + state management. + + PA_FX_COOKIE TBA + + + + +Zhu & Hartman Expires April 28, 2007 [Page 17] + +Internet-Draft Kerberos Preauth Framework October 2006 + + + The corresponding padata-value field [RFC4120] contains the + Distinguished Encoding Rules (DER) [X60] [X690] encoding of the + following Abstract Syntax Notation One (ASN.1) type PA-FX-COOKIE: + + PA-FX-COOKIE ::= SEQUENCE { + Cookie [1] OCTET STRING, + -- Opaque data, for use to associate all the messages in a + -- single conversation between the client and the KDC. + -- This can be generated by either the client or the KDC. + -- The receiver MUST copy the exact Cookie encapsulated in + -- a PA_FX_COOKIE data element into the next message of the + -- same conversation. + ... + } + + The PA-FX-COOKIE structure contains an opaque cookie that is a logic + identifier of all the messages in a conversation. + + The PA_FX_COOKIE can be initially sent by the client or the KDC, the + receiver MUST copy the Cookie into a PA_FX_COOKIE padata and include + it in the next message, if any, in the same conversation. + + The content of the PA_FX_COOKIE padata is a local matter of the + sender. Implementations MUST NOT include any sensitive or private + data in the PA-FX-COOKIE structure. + + If at least one more message for a mechanism or a mechanism set is + expected by the KDC, the KDC returns a + KDC_ERR_MORE_PREAUTH_DATA_NEEDED error with a PA_FX_COOKIE to + identify the conversation with the client. + + KDC_ERR_MORE_PREAUTH_DATA_NEEDED TBA + + If a PA_FX_COOKIE is included in the client request, the KDC then + MUST copy the exact cookie into the response. + +6.4. Pre-authentication Set + + If all mechanisms in a group need to successfully complete in order + to authenticate a client, the client and the KDC SHOULD use the + PA_AUTHENTICATION_SET padata element. A PA_AUTHENTICATION_SET padata + element contains the ASN.1 DER encoding of the PA-AUTHENTICATION-SET + structure: + + + + + + + + +Zhu & Hartman Expires April 28, 2007 [Page 18] + +Internet-Draft Kerberos Preauth Framework October 2006 + + + PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM + + PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE { + pa-type [1] Int32, + -- same as padata-type. + pa-hint [2] OCTET STRING, + -- hint data. + ... + } + + The pa-type field of the PA-AUTHENTICATION-SET-ELEM structure + contains the corresponding value of padata-type in PA-DATA [RFC4120]. + Associated with the pa-type is a pa-hint, which is an octet-string + specified by the pre-authentication mechanism. This hint may provide + information for the client which helps it determine whether the + mechanism can be used. For example a public-key mechanism might + include the certificate authorities it trusts in the hint info. Most + mechanisms today do not specify hint info; if a mechanism does not + specify hint info the KDC MUST NOT send a hint for that mechanism. + To allow future revisions of mechanism specifications to add hint + info, clients MUST ignore hint info received for mechanisms that the + client believes do not support hint info. + + When indicating which sets of padata are supported, the KDC includes + a PA-AUTHENTICATION-SET padata element for each authentication set. + + The client sends the padata-value for the first mechanism it picks in + the authentication set, when the first mechanism completes, the + client and the KDC will proceed with the second mechanism, and so on + until all mechanisms complete successfully. The PA_FX_COOKIE as + defined in Section 6.3 MUST be sent by the KDC along with the first + message that contains a PA-AUTHENTICATION-SET, in order to keep track + of KDC states. + +6.5. Definition of Kerberos FAST Padata + + The cipher text exposure of encrypted timestamp pre-authentication + data is a security concern for Kerberos. Attackers can lauch offline + dictionary attack using the cipher text. The FAST pre-authentication + padata is a tool to mitigate this threat. FAST also provides + solutions to common problems for pre-authentication mechanisms such + as binding of the request and the reply, freshness guarantee of the + authentication. FAST itself, however, does not authenticate the + client or the KDC, instead, it provides a typed hole to allow pre- + authentication data be tunneled using FAST messages. A pre- + authentication data element used within FAST is called a FAST factor. + A FAST factor capatures the minimal work required for extending + Kerberos to support a new authentication scheme. A FAST factor MUST + + + +Zhu & Hartman Expires April 28, 2007 [Page 19] + +Internet-Draft Kerberos Preauth Framework October 2006 + + + NOT be used outside of FAST unless its specification explicitly + allows so. The typed holes in FAST messages can also be used as + generic ones that are not intended to prove the client's identity, or + establish the reply key. + + New pre-authentication mechanisms SHOULD be designed as FAST factors, + instead of full-blown pre-authentication mechanisms. + + A FAST mechanism factor when used within FAST to authenticate the + client or the KDC is a pre-authentication mechanism, as such the + specification of such a FAST factor SHOULD specify which facilities + it provides per Section 5. + + Implementations of the pre-authentication framework SHOULD use + encrypted timestamp pre-authentication, if that is the mechanism to + authenticate the client, as a FAST factor to avoid security exposure. + + The encrypted timestamp FAST factor MUST fill out the encrypted rep- + key-package field as described in Section 6.5.3. It provides the + following facilities: client-authentication, replacing-reply-key, + KDC-authentication. It does not provide the strengthening-reply-key + facility. The security considerations section of this document + provides an explaination why the security requirements are met. + + FAST employs an armoring scheme. The armor can be a host Ticket + Granting Ticket (TGT), or an anonymous TGT obtained based on + anonymous PKINIT [KRB-ANON], or a pre-shared long term key such as a + host key. The rest of this section describes the types of armors and + the messages used by FAST. + +6.5.1. FAST Armors + + An armor key is used to encrypt pre-authentication data in the FAST + request and the response. The ArmorData structure is used to + identify the armor key. It contains the following two fields: the + armor-type identifies the type of armor data, and the armor-value as + an OCTET STRING contains the data. + + KrbFastArmor ::= SEQUENCE { + armor-type [1] Int32, + -- Type of the armor. + armor-value [2] OCTET STRING, + -- Value of the armor. + ... + } + + The value of the armor key is a matter of the armor type + specification. The following types of armors are currently defined: + + + +Zhu & Hartman Expires April 28, 2007 [Page 20] + +Internet-Draft Kerberos Preauth Framework October 2006 + + + FX_FAST_ARMOR_AP_REQUEST 1 + FX_FAST_ARMOR_KEY_ID 2 + + Conforming implementations MUST implement the + FX_FAST_ARMOR_AP_REQUEST armor type. + +6.5.1.1. Ticket-based Armors + + The FX_FAST_ARMOR_AP_REQUEST armor type is based on a Kerberos TGT. + The armor-value field of an FX_FAST_ARMOR_AP_REQUEST armor contains + an AP-REQ encoded in DER. The subkey field in the AP-REQ MUST be + present. And the armor key is the subkey in the AP-REQ + authenticator. + + If the client has a TGT for the expected KDC, it can use that ticket + to construct the AP-REQ. If not, the client can use anonymous PKINIT + as described in [KRB-ANON] to obtain a TGT anonymously and use that + to construct an FX_FAST_ARMOR_AP_REQUEST armor. + +6.5.1.2. Key-based Armors + + The FX_FAST_ARMOR_KEY_ID armor type is used to carry an identifier of + a key that is shared between the client host and the KDC. The + content and the encoding of the armor-data field of this armor type + is a local matter of the communicating client and the expected KDC. + The FX_FAST_ARMOR_KEY_ID armor is useful when the client host and the + KDC does have a shared key and it is beneficial to minimize the + number of messages exchanged between the client and the KDC, namely + by eliminating the messages for obtaining a host ticket based on the + host key. + +6.5.2. FAST Request + + A padata type PA_FX_FAST is defined for the Kerberos FAST pre- + authentication padata. The corresponding padata-value field + [RFC4120] contains the DER encoding of the ASN.1 type PA-FX-FAST- + REQUEST. + + + + + + + + + + + + + + +Zhu & Hartman Expires April 28, 2007 [Page 21] + +Internet-Draft Kerberos Preauth Framework October 2006 + + + PA-FX-FAST-REQUEST ::= CHOICE { + armored-data [1] KrbFastAmoredReq, + ... + } + + KrbFastAmoredReq ::= SEQUENCE { + armor [1] KrbFastArmor OPTIONAL, + -- Contains the armor that determines the armor key. + -- MUST be present in the initial AS-REQ in a converstation, + -- MUST be absent in any subsequent AS-REQ. + -- MUST be absent in TGS-REQ. + req-checksum [2] Checksum, + -- Checksum performed over the type KDC-REQ-BODY. + -- The checksum key is the armor key, and the checksum + -- type is the required checksum type for the enctype of + -- the armor key. + enc-fast-req [3] EncryptedData, -- KrbFastReq -- + -- The encryption key is the armor key, and the key usage + -- number is TBA. + ... + } + + The PA-FX-FAST-REQUEST contains a KrbFastAmoredReq structure. The + KrbFastAmoredReq encapsulates the encrypted padata. + + The armor key is used to encrypt the KrbFastReq structure, and the + key usage number for that encryption is TBA. The armor field in the + KrbFastAmoredReq structure is filled to identify the armor key. + + When a KrbFastAmoredReq is included in an AS request, the armor field + MUST be present in the initial AS-REQ in a converstation, specifying + the armor key being used. The armor field MUST be absent in any + subsequent AS-REQ of the same converstation. Thus the armor key is + specified explicitly in the initial AS-REQ in a converstation, and + implicitly thereafter. + + When a KrbFastAmoredReq is included in a TGS request, the armor field + MUST be absent. In which case, the subkey in the AP-REQ + authenticator in the PA-TGS-REQ PA-DATA MUST be present, and the + armor key is implicitly that subkey. + + The req-checksum field contains a checksum that is performed over the + type KDC-REQ-BODY of the containing message. The checksum key is the + armor key, and the checksum type is the required checksum type for + the enctype of the armor key. + + The enc-fast-req field contains an encrypted KrbFastReq structure. + The KrbFastReq structure contains the following information: + + + +Zhu & Hartman Expires April 28, 2007 [Page 22] + +Internet-Draft Kerberos Preauth Framework October 2006 + + + KrbFastReq ::= SEQUENCE { + fast-options [0] FastOptions, + -- Additional options. + padata [1] SEQUENCE OF PA-DATA, + -- padata typed holes. + timestamp [2] KerberosTime, + usec [3] Microseconds, + -- timestamp and usec represent the time of the client + -- host. + req-nonce [4] OCTET STRING, + -- At least 128 octets in length, randomly filled using + -- a PRNG by the client for each message request. + ... + } + + The fast-options field indicates various options that are to modify + the behavior of the KDC. The meanings of the options are as follows: + + FastOptions ::= KerberosFlags + -- reserved(0), + -- anonymous(1), + -- kdc-referrals(16) + + + Bits Name Description + ----------------------------------------------------------------- + 0 RESERVED Reserved for future expansion of this field. + 1 anonymous Requesting the KDC to hide client names in + the KDC response, as described next in this + section. + 16 kdc-referrals Requesting the KDC to follow referrals, as + described next in this section. + + Bits 1 through 15 (with bit 2 and bit 15 included) are critical + options. If the KDC does not understand a critical option, it MUST + fail the request. Bit 16 and onward (with bit 16 included) are non- + critical options. The KDC conforming to this specification ignores + unknown non-critical options. + + The anonymous Option + + The Kerberos response defined in [RFC4120] contains the client + identity in clear text, This makes traffic analysis + straightforward. The anonymous option is designed to complicate + traffic analysis performed over the client-KDC messages. If the + anonymous option is set, the KDC implementing PA_FX_FAST MUST + identify the client as the anonymous principal in the KDC reply + and the error response. Thus this option is set by the client if + + + +Zhu & Hartman Expires April 28, 2007 [Page 23] + +Internet-Draft Kerberos Preauth Framework October 2006 + + + it wishes to hide the client identity in the KDC response. + + The kdc-referrals Option + + The Kerberos client described in [RFC4120] has to request referral + TGTs along the authentication path in order to get a service + ticket for the target service. The Kerberos client described in + the [REFERRALS] need to contain the AS specified in the error + response in order to complete client referrals. In many cases, it + is desirable to keep the client's involvement minimal. For + example, the client may contact the KDC via a satellite link that + has high latency, or the client has limited computational + capabilities. The kdc-referrals option is designed to minimize + the number of KDC response messages that the client need to + process. If the kdc-referrals option is set, the KDC that honors + this option acts as the client to follow AS referrals and TGS + referrals [REFERRALS], and return the ticket thus-obtained using + the reply key expected by the client. The kdc-referrals option + can be implemented when the KDC knows the reply key. KDC can + igore kdc-referrals option when it does not understand it or it + does not allow it based on local policy. The client MUST be able + to process the KDC responses when this option is not honored by + the KDC, unless otherwise specified. + + The padata field contains a list of PA-DATA structures as described + in Section 5.2.7 in [RFC4120]. These PA-DATA structures can contain + FAST factors. They can also be used as generic typed-holes to + contain data not intended for proving the client's identity or + establishing a reply key, but for protocol extensibility. + + The timestamp and usec fields represent the time of the client host, + these fields have the same semantics as the corresponding- + identically-named fields in Section 5.6.1 of [RFC4120]. + + The req-nonce field is randomly filled using a PRNG by the client for + each message request. It MUST have at least 128 octets in length. + +6.5.3. FAST Response + + The KDC that supports the PA_FX_FAST padata MUST include a PA_FX_FAST + padata element in the KDC reply and/or the error response, when the + client and the KDC agreed upon the armor key. The corresponding + padata-value field [RFC4120] in the KDC response is the DER encoding + of the ASN.1 type PA-FX-FAST-REPLY. + + + + + + + +Zhu & Hartman Expires April 28, 2007 [Page 24] + +Internet-Draft Kerberos Preauth Framework October 2006 + + + PA-FX-FAST-REPLY ::= CHOICE { + armored-data [1] KrbFastArmoredRep, + ... + } + + KrbFastArmoredRep ::= SEQUENCE { + enc-fast-rep [1] EncryptedData, -- KrbFastResponse -- + -- The encryption key is the armor key in the request, and + -- the key usage number is TBA. + ... + } + + The PA-FX-FAST-REPLY structure contains a KrbFastArmoredRep + structure. The KrbFastArmoredRep structure encapsulates the padata + in the KDC reply in the encrypted form. The KrbFastResponse is + encrypted with the armor key used in the corresponding request, and + the key usage number is TBA. + + The Kerberos client who does not receive a PA-FX-FAST-REPLY in the + KDC response MUST reject the reply based on local policy. The + Kerberos client MAY process an error message without a PA-FX-FAST- + REPLY, if that is only intended to return better error information to + the application, typically for trouble-shooing purposes. + + The KrbFastResponse structure contains the following information: + + KrbFastResponse ::= SEQUENCE { + padata [1] SEQUENCE OF PA-DATA, + -- padata typed holes. + finish [2] KrbFastFinish OPTIONAL, + -- MUST be present if the client is authenticated, + -- absent otherwise. + -- Typically this is present if and only if the containing + -- message is the last one in a conversation. + rep-nonce [3] OCTET STRING, + -- At least 128 octets in length, randomly filled using + -- a PRNG by the KDC for each KDC response. + ... + } + + The padata field in the KrbFastResponse structure contains a list of + PA-DATA structures as described in Section 5.2.7 of [RFC4120]. These + PA-DATA structures are used to carry data completing the exchange for + the FAST factors. They can also be used as generic typed-holes for + protocol extensibility. + + The finish field contains a KrbFastFinish structure. It is filled by + the KDC when the client has been authenticated (the client + + + +Zhu & Hartman Expires April 28, 2007 [Page 25] + +Internet-Draft Kerberos Preauth Framework October 2006 + + + authenticated state is marked), it MUST be absent otherwise. + Consequently this field can only be present in an AS-REP or a TGS-REP + when a ticket is returned. And typically the containing message with + the finish field present is the last one in a conversation. + + The KrbFastFinish structure contains the following information: + + KrbFastFinish ::= SEQUENCE { + authtime [1] KerberosTime, + usec [2] Microseconds, + -- timestamp and usec represent the time on the KDC when + -- the reply was generated. + rep-key-package [3] EncryptedData OPTIONAL, -- EncryptionKey -- + -- This, if present, replaces the reply key for AS and TGS. + -- The encryption key is the client key, unless otherwise + -- specified. The key usage number is TBA. + crealm [4] Realm, + cname [5] PrincipalName, + -- Contains the client realm and the client name. + checksum [6] Checksum, + -- Checksum performed over all the messages in the + -- conversation, except the containing message. + -- The checksum key is the ticket session key of the reply + -- ticket, and the checksum type is the required checksum + -- type of that key. + ... + } + + The timestamp and usec fields represent the time on the KDC when the + reply was generated, these fields have the same semantics as the + corresponding-identically-named fields in Section 5.6.1 of [RFC4120]. + The client MUST use the KDC's time in these fields thereafter when + using the returned ticket. Note that the KDC's time in AS-REP may + not match the authtime in the reply ticket if the kdc-referrals + option is requested and honored by the KDC. + + The rep-key-package field, if present, contains the reply key + encrypted using the client key unless otherwise specified. The key + usage number is TBA. + + When the encrypted timestamp FAST factor is used in the request, the + rep-key-package field MUST be present and the client key is used to + encrypt the reply key enclosed in the KrbFastArmoredRep. + + The cname and crealm fields identifies the authenticated client. + + The checksum field contains a checksum of all the messages in the + conversation excluding and prior to the containing message. The + + + +Zhu & Hartman Expires April 28, 2007 [Page 26] + +Internet-Draft Kerberos Preauth Framework October 2006 + + + checksum key is the ticket session key of the reply ticket, and the + checksum type is the required checksum type of the enctype of that + key. + + The rep-nonce field is randomly filled using a PRNG by the KDC for + each KDC response, and it MUST have at least 128 octets in length. + + The client MUST include a PA_FX_COOKIE as defined in Section 6.3, if + it includes a PA_FX_FAST in the request. + +6.6. Authentication Strength Indication + + Implementations that have pre-authentication mechanisms offering + significantly different strengths of client authentication MAY choose + to keep track of the strength of the authentication used as an input + into policy decisions. For example, some principals might require + strong pre-authentication, while less sensitive principals can use + relatively weak forms of pre-authentication like encrypted timestamp. + + An AuthorizationData data type AD-Authentication-Strength is defined + for this purpose. + + AD-authentication-strength TBA + + The corresponding ad-data field contains the DER encoding of the pre- + authentication data set as defined in Section 6.4. This set contains + all the pre-authentication mechanisms that were used to authenticate + the client. If only one pre-authentication mechanism was used to + authenticate the client, the pre-authentication set contains one + element. + + The AD-authentication-strength element MUST be included in the AD-IF- + RELEVANT, thus it can be ignored if it is unknown to the receiver. + + +7. IANA Considerations + + This document defines FAST factors, these are mini- and light- + weighted- pre-authentication mechanisms. A new IANA registry should + be setup for registering FAST factor IDs. + + +8. Security Considerations + + The kdc-referrals option in the Kerberos FAST padata requests the KDC + to act as the client to follow referrals. This can overload the KDC. + To limit the damages of denied of service using this option, KDCs MAY + restrict the number of simultaneous active requests with this option + + + +Zhu & Hartman Expires April 28, 2007 [Page 27] + +Internet-Draft Kerberos Preauth Framework October 2006 + + + for any given client principal. + + Because the client secrets are known only to the client and the KDC, + the verification of the encrypted timestamp proves the client's + identity, the verification of the encrypted rep-key-package in the + KDC reply proves that the expected KDC responded. The encrypted + reply key is contained in the rep-key-package in the PA-FX-FAST- + REPLY. Therefore, the encrypted timestamp FAST factor as a pre- + authentication mechanism offers the following facilities: client- + authentication, replacing-reply-key, KDC-authentication. There is no + un-authenticated cleartext introduced by the encrypted timestamp FAST + factor. + + +9. Acknowledgements + + Serveral suggestions from Jeffery Hutzman based on early revisions of + this documents led to significant improvements of this document. + + +10. References + +10.1. Normative References + + [KRB-ANON] Zhu, L., Leach, P. and Jaganathan, K., "Kerberos Anonymity + Support", draft-ietf-krb-wg-anon, work in progress. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for + Kerberos 5", RFC 3961, February 2005. + + [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The + Kerberos Network Authentication Service (V5)", RFC 4120, + July 2005. + + [REFERALS] Raeburn, K. et al, "Generating KDC Referrals to Locate + Kerberos Realms", draft-ietf-krb-wg-kerberos-referrals, + work in progress. + +Zhu & Hartman Expires April 27, 2007 [Page 27] + +Internet-Draft Kerberos Preauth Framework October 2006 + + + [SHA2] National Institute of Standards and Technology, "Secure + Hash Standard (SHS)", Federal Information Processing + Standards Publication 180-2, August 2002. + + [X680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, + Information technology - Abstract Syntax Notation One + (ASN.1): Specification of basic notation. + + + +Zhu & Hartman Expires April 28, 2007 [Page 28] + +Internet-Draft Kerberos Preauth Framework October 2006 + + + + [X690] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, + Information technology - ASN.1 encoding Rules: + Specification of Basic Encoding Rules (BER), Canonical + Encoding Rules (CER) and Distinguished Encoding Rules + (DER). + +10.2. Informative References + + [EKE] Bellovin, S. M. and M. Merritt. "Augmented + Encrypted Key Exchange: A Password-Based Protocol Secure + Against Dictionary Attacks and Password File Compromise". + Proceedings of the 1st ACM Conference on Computer and + Communications Security, ACM Press, November 1993. + + [HKDF] Dang, Q. and P. Polk, draft-dang-nistkdf, work in + progress. + + [IEEE1363.2] + IEEE P1363.2: Password-Based Public-Key Cryptography, + 2004. + + [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial + Authentication in Kerberos (PKINIT)", RFC 4556, June 2006. + + +Appendix A. ASN.1 module + + KerberosPreauthFramework { + iso(1) identified-organization(3) dod(6) internet(1) + security(5) kerberosV5(2) modules(4) preauth-framework(3) + } DEFINITIONS EXPLICIT TAGS ::= BEGIN + + IMPORTS + + KerberosTime, PrincipalName, Realm, EncryptionKey, Checksum, + Int32, EncryptedData, PA-DATA + FROM KerberosV5Spec2 { iso(1) identified-organization(3) + dod(6) internet(1) security(5) kerberosV5(2) + modules(4) krb5spec2(2) }; + -- as defined in RFC 4120. + + PA-FX-COOKIE ::= SEQUENCE { + Cookie [1] OCTET STRING, + -- Opaque data, for use to associate all the messages in a + -- single conversation between the client and the KDC. + -- This can be generated by either the client or the KDC. + -- The receiver MUST copy the exact Cookie encapsulated in + -- a PA_FX_COOKIE data element into the next message of the + -- same conversation. + ... + } + + PA-AUTHENTICATION-SET ::= SEQUENCE OF PA-AUTHENTICATION-SET-ELEM + + PA-AUTHENTICATION-SET-ELEM ::= SEQUENCE { + pa-type [1] Int32, + -- same as padata-type. + pa-hint [2] OCTET STRING, + -- hint data. + ... + } + + +Zhu & Hartman Expires April 28, 2007 [Page 29] + +Internet-Draft Kerberos Preauth Framework October 2006 + + + + PA-FX-FAST-REQUEST ::= CHOICE { + armored-data [1] KrbFastAmoredReq, + ... + } + + KrbFastAmoredReq ::= SEQUENCE { + armor [1] KrbFastArmor OPTIONAL, + -- Contains the armor that determines the armor key. + -- MUST be present in AS-REQ. + -- MUST be absent in TGS-REQ. + req-checksum [2] Checksum, + -- Checksum performed over the type KDC-REQ-BODY. + -- The checksum key is the armor key, and the checksum + -- type is the required checksum type for the enctype of + -- the armor key. + enc-fast-req [3] EncryptedData, -- KrbFastReq -- + -- The encryption key is the armor key, and the key usage + -- number is TBA. + ... + } + + KrbFastArmor ::= SEQUENCE { + armor-type [1] Int32, + -- Type of the armor. + armor-value [2] OCTET STRING, + -- Value of the armor. + ... + } + + KrbFastReq ::= SEQUENCE { + fast-options [0] FastOptions, + -- Additional options. + padata [1] SEQUENCE OF PA-DATA, + -- padata typed holes. + timestamp [2] KerberosTime, + usec [3] Microseconds, + -- timestamp and usec represent the time of the client + -- host. + req-nonce [4] OCTET STRING, + -- At least 128 octets in length, randomly filled using + -- a PRNG by the client for each message request. + ... + } + + FastOptions ::= KerberosFlags + -- reserved(0), + -- anonymous(1), + -- kdc-referrals(16) + + + +Zhu & Hartman Expires April 28, 2007 [Page 30] + +Internet-Draft Kerberos Preauth Framework October 2006 + + + + PA-FX-FAST-REPLY ::= CHOICE { + armored-data [1] KrbFastArmoredRep, + ... + } + + KrbFastArmoredRep ::= SEQUENCE { + enc-fast-rep [1] EncryptedData, -- KrbFastResponse -- + -- The encryption key is the armor key in the request, and + -- the key usage number is TBA. + ... + } + + KrbFastResponse ::= SEQUENCE { + padata [1] SEQUENCE OF PA-DATA, + -- padata typed holes. + finish [2] KrbFastFinish OPTIONAL, + -- MUST be present if the client is authenticated, + -- absent otherwise. + -- Typically this is present if and only if the containing + -- message is the last one in a conversation. + rep-nonce [3] OCTET STRING, + -- At least 128 octets in length, randomly filled using + -- a PRNG by the KDC for each KDC response. + ... + } + + KrbFastFinish ::= SEQUENCE { + timestamp [1] KerberosTime, + usec [2] Microseconds, + -- timestamp and usec represent the time on the KDC when + -- the reply was generated. + rep-key-package [3] EncryptedData OPTIONAL, -- EncryptionKey -- + -- This, if present, replaces the reply key for AS and TGS. + -- The encryption key is the client key, unless otherwise + -- specified. The key usage number is TBA. + crealm [4] Realm, + cname [5] PrincipalName, + -- Contains the client realm and the client name. + checksum [6] Checksum, + -- Checksum performed over all the messages in the + -- conversation, except the containing message. + -- The checksum key is the ticket session key of the reply + -- ticket, and the checksum type is the required checksum + -- type of that key. + ... + } + + END + + +Authors' Addresses + + Larry Zhu + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + US + + Email: lzhu@microsoft.com + + + Sam hartman + MIT + + Email: hartmans@mit.edu + + + + +Zhu & Hartman Expires April 28, 2007 [Page 31] + +Internet-Draft Kerberos Preauth Framework October 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Acknowledgment + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + +Zhu & Hartman Expires April 28, 2007 [Page 32] + + diff --git a/doc/standardisation/draft-ietf-krb-wg-rfc1510ter-03.txt b/doc/standardisation/draft-ietf-krb-wg-rfc1510ter-03.txt new file mode 100644 index 000000000..009e8bd2b --- /dev/null +++ b/doc/standardisation/draft-ietf-krb-wg-rfc1510ter-03.txt @@ -0,0 +1,6217 @@ + + +INTERNET-DRAFT Tom Yu +draft-ietf-krb-wg-rfc1510ter-03.txt MIT +Expires: 26 Apr 2006 23 October 2006 + + The Kerberos Network Authentication Service (Version 5) + +Status of This Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + + http://www.ietf.org/shadow.html + + +Copyright Notice + + Copyright (C) The Internet Society (2006). All Rights Reserved. + +Abstract + + This document describes version 5 of the Kerberos network + authentication protocol. It describes a framework to allow for + extensions to be made to the protocol without creating + interoperability problems. + +Key Words for Requirements + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are + to be interpreted as described in RFC 2119. + + + + +Yu Expires: Apr 2007 [Page 1] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + +Table of Contents + + Status of This Memo .............................................. 1 + Copyright Notice ................................................. 1 + Abstract ......................................................... 1 + Key Words for Requirements ....................................... 1 + Table of Contents ................................................ 2 + 1. Introduction ................................................. 5 + 1.1. Kerberos Protocol Overview ................................. 5 + 1.2. Document Organization ...................................... 6 + 2. Compatibility Considerations ................................. 6 + 2.1. Extensibility .............................................. 7 + 2.2. Compatibility with RFC 1510 ................................ 7 + 2.3. Backwards Compatibility .................................... 7 + 2.4. Sending Extensible Messages ................................ 8 + 2.5. Criticality ................................................ 8 + 2.6. Authenticating Cleartext Portions of Messages .............. 9 + 2.7. Capability Negotiation ..................................... 10 + 2.7.1. KDC protocol ............................................. 10 + 2.7.2. Application protocol ..................................... 11 + 2.8. Strings .................................................... 11 + 3. Use of ASN.1 in Kerberos ..................................... 11 + 3.1. Module Header .............................................. 12 + 3.2. Top-Level Type ............................................. 12 + 3.3. Previously Unused ASN.1 Notation (informative) ............. 13 + 3.3.1. Parameterized Types ...................................... 13 + 3.3.2. Constraints .............................................. 13 + 3.4. New Types .................................................. 13 + 4. Basic Types .................................................. 14 + 4.1. Constrained Integer Types .................................. 14 + 4.2. KerberosTime ............................................... 15 + 4.3. KerberosString ............................................. 15 + 4.4. Language Tags .............................................. 16 + 4.5. KerberosFlags .............................................. 16 + 4.6. Typed Holes ................................................ 17 + 4.7. HostAddress and HostAddresses .............................. 17 + 4.7.1. Internet (IPv4) Addresses ................................ 18 + 4.7.2. Internet (IPv6) Addresses ................................ 18 + 4.7.3. DECnet Phase IV addresses ................................ 18 + 4.7.4. Netbios addresses ........................................ 18 + 4.7.5. Directional Addresses .................................... 18 + 5. Principals ................................................... 19 + 5.1. Name Types ................................................. 19 + 5.2. Principal Type Definition .................................. 20 + 5.3. Principal Name Reuse ....................................... 21 + 5.4. Best Common Practice Recommendations for the Processing + of Principal Names Consisting of Internationalized + Domain Names: .......................................... 21 + 5.5. Realm Names ................................................ 22 + 5.6. Best Common Practice Recommendations for the Processing + of Internationalized Domain-Style Realm Names: ......... 22 + +Yu Expires: Apr 2007 [Page 2] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + 5.7. Printable Representations of Principal Names ............... 23 + 5.8. Ticket-Granting Service Principal .......................... 23 + 5.8.1. Cross-Realm TGS Principals ............................... 24 + 6. Types Relating to Encryption ................................. 24 + 6.1. Assigned Numbers for Encryption ............................ 24 + 6.1.1. EType .................................................... 24 + 6.1.2. Key Usages ............................................... 25 + 6.2. Which Key to Use ........................................... 26 + 6.3. EncryptionKey .............................................. 27 + 6.4. EncryptedData .............................................. 27 + 6.5. Checksums .................................................. 28 + 6.5.1. ChecksumOf ............................................... 29 + 6.5.2. Signed ................................................... 30 + 7. Tickets ...................................................... 30 + 7.1. Timestamps ................................................. 31 + 7.2. Ticket Flags ............................................... 32 + 7.2.1. Flags Relating to Initial Ticket Acquisition ............. 32 + 7.2.2. Invalid Tickets .......................................... 33 + 7.2.3. OK as Delegate ........................................... 33 + 7.2.4. Renewable Tickets ........................................ 34 + 7.2.5. Postdated Tickets ........................................ 34 + 7.2.6. Proxiable and Proxy Tickets .............................. 35 + 7.2.7. Forwarded and Forwardable Tickets ........................ 36 + 7.3. Transited Realms ........................................... 37 + 7.4. Authorization Data ......................................... 37 + 7.4.1. AD-IF-RELEVANT ........................................... 38 + 7.4.2. AD-KDCIssued ............................................. 39 + 7.4.3. AD-AND-OR ................................................ 40 + 7.4.4. AD-MANDATORY-FOR-KDC ..................................... 40 + 7.5. Encrypted Part of Ticket ................................... 41 + 7.6. Cleartext Part of Ticket ................................... 41 + 8. Credential Acquisition ....................................... 43 + 8.1. KDC-REQ .................................................... 43 + 8.2. PA-DATA .................................................... 50 + 8.3. KDC-REQ Processing ......................................... 50 + 8.3.1. Handling Replays ......................................... 50 + 8.3.2. Request Validation ....................................... 51 + 8.3.2.1. AS-REQ Authentication .................................. 51 + 8.3.2.2. TGS-REQ Authentication ................................. 51 + 8.3.2.3. Principal Validation ................................... 51 + 8.3.2.4. Checking For Revoked or Invalid Tickets ................ 51 + 8.3.3. Timestamp Handling ....................................... 52 + 8.3.3.1. AS-REQ Timestamp Processing ............................ 52 + 8.3.3.2. TGS-REQ Timestamp Processing ........................... 53 + 8.3.4. Handling Transited Realms ................................ 54 + 8.3.5. Address Processing ....................................... 54 + 8.3.6. Ticket Flag Processing ................................... 54 + 8.3.7. Key Selection ............................................ 56 + 8.3.7.1. Reply Key and Session Key Selection .................... 56 + 8.3.7.2. Ticket Key Selection ................................... 56 + 8.4. KDC-REP .................................................... 56 + +Yu Expires: Apr 2007 [Page 3] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + 8.5. Reply Validation ........................................... 60 + 8.6. IP Transports .............................................. 60 + 8.6.1. UDP/IP transport ......................................... 60 + 8.6.2. TCP/IP transport ......................................... 60 + 8.6.3. KDC Discovery on IP Networks ............................. 62 + 8.6.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names ..... 62 + 8.6.3.2. DNS SRV records for KDC location ....................... 62 + 8.6.3.3. KDC Discovery for Domain Style Realm Names on IP + Networks ............................................ 63 + 9. Errors ....................................................... 63 + 10. Session Key Exchange ........................................ 65 + 10.1. AP-REQ .................................................... 66 + 10.2. AP-REP .................................................... 67 + 11. Session Key Use ............................................. 69 + 11.1. KRB-SAFE .................................................. 69 + 11.2. KRB-PRIV .................................................. 69 + 11.3. KRB-CRED .................................................. 70 + 12. Security Considerations ..................................... 71 + 12.1. Time Synchronization ...................................... 71 + 12.2. Replays ................................................... 71 + 12.3. Principal Name Reuse ...................................... 72 + 12.4. Password Guessing ......................................... 72 + 12.5. Forward Secrecy ........................................... 72 + 12.6. Authorization ............................................. 72 + 12.7. Login Authentication ...................................... 72 + 13. IANA Considerations ......................................... 72 + 14. Acknowledgments ............................................. 73 + Appendices ....................................................... 73 + A. ASN.1 Module (Normative) ..................................... 73 + B. Kerberos and Character Encodings (Informative) ...............105 + C. Kerberos History (Informative) ...............................107 + D. Notational Differences from [KCLAR] ..........................107 + Normative References .............................................108 + Informative References ...........................................109 + Author's Address .................................................110 + Copyright Statement ..............................................110 + Intellectual Property Statement ..................................110 + + + + + + + + + + + + + + + +Yu Expires: Apr 2007 [Page 4] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + +1. Introduction + + The Kerberos network authentication protocol is a trusted-third-party + protocol utilizing symmetric-key cryptography. It assumes that all + communications between parties in the protocol may be arbitrarily + tampered with or monitored, and that the security of the overall + system depends only on the effectiveness of the cryptographic + techniques and the secrecy of the cryptographic keys used. The + Kerberos protocol authenticates an application client's identity to + an application server, and likewise authenticates the application + server's identity to the application client. These assurances are + made possible by the client and the server sharing secrets with the + trusted third party: the Kerberos server, also known as the Key + Distribution Center (KDC). In addition, the protocol establishes an + ephemeral shared secret (the session key) between the client and the + server, allowing the protection of further communications between + them. + + The Kerberos protocol, as originally specified, provides insufficient + means for extending the protocol in a backwards-compatible way. This + deficiency has caused problems for interoperability. This document + describes a framework which enables backwards-compatible extensions + to the Kerberos protocol. + +1.1. Kerberos Protocol Overview + + Kerberos comprises three main sub-protocols: credentials acquisition, + session key exchange, and session key usage. A client acquires + credentials by asking the KDC for a credential for a service; the KDC + issues the credential, which contains a ticket and a session key. + The ticket, containing the client's identity, timestamps, expiration + time, and a session key, is a encrypted in a key known to the + application server. The KDC encrypts the credential using a key + known to the client, and transmits the credential to the client. + + There are two means of requesting credentials: the Authentication + Service (AS) exchange, and the Ticket-Granting Service (TGS) + exchange. In the typical AS exchange, a client uses a password- + derived key to decrypt the response. In the TGS exchange, the KDC + behaves as an application server; the client authenticates to the TGS + by using a Ticket-Granting Ticket (TGT). The client usually obtains + the TGT by using the AS exchange. + + Session key exchange consists of the client transmitting the ticket + to the application server, accompanied by an authenticator. The + authenticator contains a timestamp and additional data encrypted + using the ticket's session key. The application server decrypts the + ticket, extracting the session key. The application server then uses + the session key to decrypt the authenticator. Upon successful + decryption of the authenticator, the application server knows that + the data in the authenticator were sent by the client named in the + +Yu Expires: Apr 2007 [Page 5] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + associated ticket. Additionally, since authenticators expire more + quickly than tickets, the application server has some assurance that + the transaction is not a replay. The application server may send an + encrypted acknowledgment to the client, verifying its identity to the + client. + + Once session key exchange has occurred, the client and server may use + the established session key to protect further traffic. This + protection may consist of protection of integrity only, or of + protection of confidentiality and integrity. Additional measures + exist for a client to securely forward credentials to a server. + + The entire scheme depends on loosely synchronized clocks. + Synchronization of the clock on the KDC with the application server + clock allows the application server to accurately determine whether a + credential is expired. Likewise, synchronization of the clock on the + client with the application server clock prevents replay attacks + utilizing the same credential. Careful design of the application + protocol may allow replay prevention without requiring client-server + clock synchronization. + + After establishing a session key, application client and the + application server can exchange Kerberos protocol messages that use + the session key to protect the integrity or confidentiality of + communications between the client and the server. Additionally, the + client may forward credentials to the application server. + + The credentials acquisition protocol takes place over specific, + defined transports (UDP and TCP). Application protocols define which + transport to use for the session key establishment protocol and for + messages using the session key; the application may choose to perform + its own encapsulation of the Kerberos messages, for example. + +1.2. Document Organization + + The remainder of this document begins by describing the general + frameworks for protocol extensibility, including whether to interpret + unknown extensions as critical. It then defines the protocol + messages and exchanges. + + The definition of the Kerberos protocol uses Abstract Syntax Notation + One (ASN.1) [X680], which specifies notation for describing the + abstract content of protocol messages. This document defines a + number of base types using ASN.1; these base types subsequently + appear in multiple types which define actual protocol messages. + Definitions of principal names and of tickets, which are central to + the protocol, also appear preceding the protocol message definitions. + + + + + +Yu Expires: Apr 2007 [Page 6] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + +2. Compatibility Considerations + +2.1. Extensibility + + In the past, significant interoperability problems have resulted from + conflicting assumptions about how the Kerberos protocol can be + extended. As the deployed base of Kerberos grows, the ability to + extend the Kerberos protocol becomes more important. In order to + ensure that vendors and the IETF can extend the protocol while + maintaining backwards compatibility, this document outlines a + framework for extending Kerberos. + + Kerberos provides two general mechanisms for protocol extensibility. + Many protocol messages, including some defined in RFC 1510, contain + typed holes--sub-messages containing an octet string along with an + integer that identifies how to interpret the octet string. The + integer identifiers are registered centrally, but can be used both + for vendor extensions and for extensions standardized in the IETF. + This document adds typed holes to a number of messages which + previously lacked typed holes. + + Many new messages defined in this document also contain ASN.1 + extension markers. These markers allow future revisions of this + document to add additional elements to messages, for cases where + typed holes are inadequate for some reason. Because tag numbers and + position in a sequence need to be coordinated in order to maintain + interoperability, implementations MUST NOT include ASN.1 extensions + except when those extensions are specified by IETF standards-track + documents. + +2.2. Compatibility with RFC 1510 + + Implementations of RFC 1510 did not use extensible ASN.1 types. + Sending additional fields not in RFC 1510 to these implementations + results in undefined behavior. Examples of this behavior are known + to include discarding messages with no error indications. + + Where messages have been changed since RFC 1510, ASN.1 CHOICE types + are used; one alternative of the CHOICE provides a message which is + wire-encoding compatible with RFC 1510, and the other alternative + provides the new, extensible message. + + Implementations sending new messages MUST ensure that the recipient + supports these new messages. Along with each extensible message is a + guideline for when that message MAY be used. If that guideline is + followed, then the recipient is guaranteed to understand the message. + +2.3. Backwards Compatibility + + This document describes two sets (for the most part) of ASN.1 types. + The first set of types is wire-encoding compatible with RFC 1510 and + +Yu Expires: Apr 2007 [Page 7] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + [KCLAR]. The second set of types is the set of types enabling + extensibility. This second set may be referred to as + "extensibility-enabled types". [ need to make this consistent + throughout? ] + + A major difference between the new extensibility-enabled types and + the types for RFC 1510 compatibility is that the extensibility- + enabled types allow for the use of UTF-8 encodings in various + character strings in the protocol. Each party in the protocol must + have some knowledge of the capabilities of the other parties in the + protocol. There are methods for establishing this knowledge without + necessarily requiring explicit configuration. + + An extensibility-enabled client can detect whether a KDC supports the + extensibility-enabled types by requesting an extensibility-enabled + reply. If the KDC replies with an extensibility-enabled reply, the + client knows that the KDC supports extensibility. If the KDC issues + an extensibility-enabled ticket, the client knows that the service + named in the ticket is extensibility-enabled. + +2.4. Sending Extensible Messages + + Care must be taken to make sure that old implementations can + understand messages sent to them even if they do not understand an + extension that is used. Unless the sender knows the extension is + supported, the extension cannot change the semantics of the core + message or previously defined extensions. + + For example, an extension including key information necessary to + decrypt the encrypted part of a KDC-REP could only be used in + situations where the recipient was known to support the extension. + Thus when designing such extensions it is important to provide a way + for the recipient to notify the sender of support for the extension. + For example in the case of an extension that changes the KDC-REP + reply key, the client could indicate support for the extension by + including a padata element in the AS-REQ sequence. The KDC should + only use the extension if this padata element is present in the AS- + REQ. Even if policy requires the use of the extension, it is better + to return an error indicating that the extension is required than to + use the extension when the recipient may not support it; debugging + why implementations do not interoperate is easier when errors are + returned. + +2.5. Criticality + + Recipients of unknown message extensions (including typed holes, new + flags, and ASN.1 extension elements) should preserve the encoding of + the extension but otherwise ignore the presence of the extension; + i.e., unknown extensions SHOULD be treated as non-critical. If a + copy of the message is used later--for example, when a Ticket + received in a KDC-REP is later used in an AP-REQ--then the unknown + +Yu Expires: Apr 2007 [Page 8] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + extensions MUST be included. + + An implementation SHOULD NOT reject a request merely because it does + not understand some element of the request. As a related + consequence, implementations SHOULD handle communicating with other + implementations which do not implement some requested options. This + may require designers of options to provide means to determine + whether an option has been rejected, not understood, or (perhaps + maliciously) deleted or modified in transit. + + There is one exception to non-criticality described above: if an + unknown authorization data element is received by a server either in + an AP-REQ or in a Ticket contained in an AP-REQ, then the + authentication SHOULD fail. Authorization data is intended to + restrict the use of a ticket. If the service cannot determine + whether the restriction applies to that service then a security + weakness may result if authentication succeeds. Authorization + elements meant to be truly optional can be enclosed in the AD-IF- + RELEVANT element. + + Many RFC 1510 implementations ignore unknown authorization data + elements. Depending on these implementations to honor authorization + data restrictions may create a security weakness. + +2.6. Authenticating Cleartext Portions of Messages + + Various denial of service attacks and downgrade attacks against + Kerberos are possible unless plaintexts are somehow protected against + modification. An early design goal of Kerberos Version 5 was to + avoid encrypting more of the authentication exchange that was + required. (Version 4 doubly-encrypted the encrypted part of a ticket + in a KDC reply, for example.) This minimization of encryption + reduces the load on the KDC and busy servers. Also, during the + initial design of Version 5, the existence of legal restrictions on + the export of cryptography made it desirable to minimize of the + number of uses of encryption in the protocol. Unfortunately, + performing this minimization created numerous instances of + unauthenticated security-relevant plaintext fields. + + The extensible variants of the messages described in this document + wrap the actual message in an ASN.1 sequence containing a keyed + checksum of the contents of the message. Guidelines in [XXX] section + 3 specify when the checksum MUST be included and what key MUST be + used. Guidelines on when to include a checksum are never ambiguous: + a particular PDU is never correct both with and without a checksum. + With the exception of the KRB-ERROR message, receiving + implementations MUST reject messages where a checksum is included and + not expected or where a checksum is expected but not included. The + receiving implementation does not always have sufficient information + to know whether a KRB-ERROR should contain a checksum. Even so, + KRB-ERROR messages with invalid checksums MUST be rejected and + +Yu Expires: Apr 2007 [Page 9] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + implementations MAY consider the presence or absence of a checksum + when evaluating whether to trust the error. + + This authenticated cleartext protection is provided only in the + extensible variants of the messages; it is never used when + communicating with an RFC 1510 implementation. + +2.7. Capability Negotiation + + Kerberos is a three-party protocol. Each of the three parties + involved needs a means of detecting the capabilities supported by the + others. Two of the parties, the KDC and the application server, do + not communicate directly in the Kerberos protocol. Communicating + capabilities from the KDC to the application server requires using a + ticket as an intermediary. + + The main capability requiring negotiation is the support of the + extensibility framework described in this document. Negotiation of + this capability while remaining compatible with RFC 1510 + implementations is possible. The main complication is that the + client needs to know whether the application server supports the + extensibility framework prior to sending any message to the + application server. This can be accomplished if the KDC has + knowledge of whether an application server supports the extensibility + framework. + + Client software advertizes its capabilities when requesting + credentials from the KDC. If the KDC recognizes the capabilities, it + acknowledges this fact to the client in its reply. In addition, if + the KDC has knowledge that the application server supports certain + capabilities, it also communicates this knowledge to the client in + its reply. The KDC can encode its own capabilities in the ticket so + that the application server may discover these capabilities. The + client advertizes its capabilities to the application server when it + initiates authentication to the application server. + +2.7.1. KDC protocol + + A client may send an AS-REQ-EXT if it has prior knowledge that the + KDC in question will accept it. (possibly via a TCP extension?) + Otherwise, the client will send an AS-REQ-1510 with the AS-REQ-EXT + inside preauthentication data. The client will always know whether + to send TGS-REQ-EXT because (as in the application protocol) it knows + the type of the associated Ticket. (Note: could be a problem with + non-TGT tickets) + + The KDC will send AS-REP-EXT or TGS-REP-EXT if the client's message + is extensible; otherwise, it will send AS-REP-1510 or TGS-REP-1510. + The Ticket contained within the AS-REP-EXT or TGS-REP-EXT will be a + TicketExt if the application server supports it; otherwise, it will + be a Ticket1510. AS-REP-1510 and TGS-REP-1510 always contain a + +Yu Expires: Apr 2007 [Page 10] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + Ticket1510. The EncTicketPart will depend on the server's + capability; the client cannot distinguish EncTicketPart1510 from + EncTicketPartExt. + + KDCs within a realm should be uniform in advertized capability for + extensible messages. A KDC SHOULD only issue a TicketExt TGT if all + KDCs support it. Similarly, a client receiving a TicketExt knows + that all instances of the application service will accept extensible + messages. + +2.7.2. Application protocol + + The client knows whether the application server supports AP-REQ-EXT + because it can distinguish Ticket1510 from TicketExt. The server + knows the client's capability due to the format of the AP-REQ. + +2.8. Strings + + Some implementations of RFC 1510 do not limit princpal names and + realm names to ASCII characters. As a result, migration difficulties + resulting from legacy non-ASCII principal and realm names can arise. + Is it reasonable to assume that any legacy non-ASCII character can be + uniquely represented in Unicode? + + This may result in a situation where various parties of the protocol + need to know alternate, possibly multiple, legacy non-ASCII names for + principals and also to know how they map into Unicode. An + application server needs to know all possible legacy encodings of its + name if it receives a "mixed" ticket. (Ticket1510 containing + EncTicketPartExt) It also needs to be able to compare a legacy + encoding of a client principal against the normalized UTF-8 encoding + when checking the client's principal name in the Authenticator + against the one contained in the EncTicketPart. This check can be + avoided if the application protocol does not require a replay cache. + +3. Use of ASN.1 in Kerberos + + Kerberos uses the ASN.1 Distinguished Encoding Rules (DER) [X690]. + Even though ASN.1 theoretically allows the description of protocol + messages to be independent of the encoding rules used to encode the + messages, Kerberos messages MUST be encoded with DER. Subtleties in + the semantics of the notation, such as whether tags carry any + semantic content to the application, may cause the use of other ASN.1 + encoding rules to be problematic. + + Implementors not using existing ASN.1 tools (e.g., compilers or + support libraries) are cautioned to thoroughly read and understand + the actual ASN.1 specification to ensure correct implementation + behavior. There is more complexity in the notation than is + immediately obvious, and some tutorials and guides to ASN.1 are + misleading or erroneous. Recommended tutorials and guides include + +Yu Expires: Apr 2007 [Page 11] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + [Dub00], [Lar99], though there is still no substitute for reading the + actual ASN.1 specification. + +3.1. Module Header + + The type definitions in this document assume an ASN.1 module + definition of the following form: + + KerberosV5Spec3 { + iso(1) identified-organization(3) dod(6) internet(1) + security(5) kerberosV5(2) modules(4) krb5spec3(4) + } DEFINITIONS EXPLICIT TAGS ::= BEGIN + + -- Rest of definitions here + + END + + This specifies that the tagging context for the module will be + explicit and that automatic tagging is not done. + + Some other publications [RFC1510] [RFC1964] erroneously specify an + object identifier (OID) having an incorrect value of "5" for the + "dod" component of the OID. In the case of RFC 1964, use of the + "correct" OID value would result in a change in the wire protocol; + therefore, the RFC 1964 OID remains unchanged for now. + +3.2. Top-Level Type + + The ASN.1 type "KRB-PDU" is a CHOICE over all the types (Protocol + Data Units or PDUs) which an application may directly reference. + Applications SHOULD NOT transmit any types other than those which are + alternatives of the KRB-PDU CHOICE. + + + + + + + + + + + + + + + + + + + + +Yu Expires: Apr 2007 [Page 12] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + -- top-level type + -- + -- Applications should not directly reference any types + -- other than KRB-PDU and its component types. + -- + KRB-PDU ::= CHOICE { + ticket Ticket, + as-req AS-REQ, + as-rep AS-REP, + tgs-req TGS-REQ, + tgs-rep TGS-REP, + ap-req AP-REQ, + ap-rep AP-REP, + krb-safe KRB-SAFE, + krb-priv KRB-PRIV, + krb-cred KRB-CRED, + tgt-req TGT-REQ, + krb-error KRB-ERROR, + ... + } + + +3.3. Previously Unused ASN.1 Notation (informative) + + Some aspects of ASN.1 notation used in this document were not used in + [KCLAR], and may be unfamiliar to some readers. This subsection is + informative; for normative definitions of the notation, see the + actual ASN.1 specifications [X680], [X682], [X683]. + +3.3.1. Parameterized Types + + This document uses ASN.1 parameterized types [X683] to make + definitions of types more readable. For some types, some or all of + the parameters are advisory, i.e., they are not encoded in any form + for transmission in a protocol message. These advisory parameters + can describe implementation behavior associated with the type. + +3.3.2. Constraints + + This document uses ASN.1 constraints, including the + "UserDefinedConstraint" notation [X682]. Some constraints can be + handled automatically by tools that can parse them. Uses of the + "UserDefinedConstraint" notation (the "CONSTRAINED BY" notation) will + typically need to have behavior manually coded; the notation provides + a formalized way of conveying intended implementation behavior. + + The "WITH COMPONENTS" constraint notation allows constraints to apply + to component types of a SEQUENCE type. This constraint notation + effectively allows constraints to "reach into" a type to constrain + its component types. + + +Yu Expires: Apr 2007 [Page 13] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + +3.4. New Types + + This document defines a number of ASN.1 types which are new since + [KCLAR]. The names of these types will typically have a suffix like + "Ext", indicating that the types are intended to support + extensibility. Types original to RFC 1510 and [KCLAR] have been + renamed to have a suffix like "1510". The "Ext" and "1510" types + often contain a number of common elements, but differ primarily in + the way strings are encoded. + +4. Basic Types + + These "basic" Kerberos ASN.1 types appear in multiple other Kerberos + types. + +4.1. Constrained Integer Types + + In RFC 1510, many types contained references to the unconstrained + INTEGER type. Since an unconstrained INTEGER can contain almost any + possible abstract integer value, most of the unconstrained references + to INTEGER in RFC 1510 were constrained to 32 bits or smaller in + [KCLAR]. + + -- signed values representable in 32 bits + -- + -- These are often used as assigned numbers for various things. + Int32 ::= INTEGER (-2147483648..2147483647) + + The "Int32" type often contains an assigned number identifying the + contents of a typed hole. Unless otherwise stated, non-negative + values are registered, and negative values are available for local + use. + + -- unsigned 32 bit values + UInt32 ::= INTEGER (0..4294967295) + + The "UInt32" type is used in some places where an unsigned 32-bit + integer is needed. + + -- unsigned 64 bit values + UInt64 ::= INTEGER (0..18446744073709551615) + + The "UInt64" type is used in places where 32 bits of precision may + provide inadequate security. + + -- sequence numbers + SeqNum ::= UInt64 + + Sequence numbers were constrained to 32 bits in [KCLAR], but this + document allows for 64-bit sequence numbers. + + +Yu Expires: Apr 2007 [Page 14] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + -- nonces + Nonce ::= UInt64 + + Likewise, nonces were constrained to 32 bits in [KCLAR], but expanded + to 64 bits here. + + -- microseconds + Microseconds ::= INTEGER (0..999999) + + The "microseconds" type is intended to carry the microseconds part of + a time value. + +4.2. KerberosTime + + KerberosTime ::= GeneralizedTime (CONSTRAINED BY { + -- MUST NOT include fractional seconds + }) + + The timestamps used in Kerberos are encoded as GeneralizedTimes. A + KerberosTime value MUST NOT include any fractional portions of the + seconds. As required by the DER, it further MUST NOT include any + separators, and it specifies the UTC time zone (Z). Example: The + only valid format for UTC time 6 minutes, 27 seconds after 9 pm on 6 + November 1985 is "19851106210627Z". + +4.3. KerberosString + + -- used for names and for error messages + KerberosString ::= CHOICE { + ia5 GeneralString (IA5String), + utf8 UTF8String, + ... -- no extension may be sent + -- to an rfc1510 implementation -- + } + + The KerberosString type is used for character strings in various + places in the Kerberos protocol. For compatibility with RFC 1510, + GeneralString values constrained to IA5String (US-ASCII) are + permitted in messages exchanged with RFC 1510 implementations. The + new protocol messages contain strings encoded as UTF-8, and these + strings MUST be normalized using [SASLPREP]. KerberosString values + are present in principal names and in error messages. Control + characters SHOULD NOT be used in principal names, and used with + caution in error messages. + + + + + + + + +Yu Expires: Apr 2007 [Page 15] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + -- IA5 choice only; useful for constraints + KerberosStringIA5 ::= KerberosString + (WITH COMPONENTS { ia5 PRESENT }) + + -- IA5 excluded; useful for constraints + KerberosStringExt ::= KerberosString + (WITH COMPONENTS { ia5 ABSENT }) + + KerberosStringIA5 requires the use of the "ia5" alternative, while + KerberosStringExt forbids it. These types appear in ASN.1 + constraints on messages. + + For detailed background regarding the history of character string use + in Kerberos, as well as discussion of some compatibility issues, see + Appendix B. + +4.4. Language Tags + + -- used for language tags + LangTag ::= PrintableString + (FROM ("A".."Z" | "a".."z" | "0".."9" | "-")) + + The "LangTag" type is used to specify language tags for localization + purposes, using the [RFC3066] format. + +4.5. KerberosFlags + + For several message types, a specific constrained bit string type, + KerberosFlags, is used. + + KerberosFlags { NamedBits } ::= BIT STRING (SIZE (32..MAX)) + (CONSTRAINED BY { + -- MUST be a valid value of -- NamedBits + -- but if the value to be sent would be truncated to shorter + -- than 32 bits according to DER, the value MUST be padded + -- with trailing zero bits to 32 bits. Otherwise, no + -- trailing zero bits may be present. + + }) + + + The actual bit string type encoded in Kerberos messages does not use + named bits. The advisory parameter of the KerberosFlags type names a + bit string type defined using named bits, whose value is encoded as + if it were a bit string with unnamed bits. This practice is + necessary because the DER require trailing zero bits to be removed + when encoding bit strings defined using named bits. Existing + implementations of Kerberos send exactly 32 bits rather than + truncating, so the size constraint requires the transmission of at + least 32 bits. Trailing zero bits beyond the first 32 bits are + truncated. + +Yu Expires: Apr 2007 [Page 16] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + +4.6. Typed Holes + + -- Typed hole identifiers + TH-id ::= CHOICE { + int32 Int32, + rel-oid RELATIVE-OID + } + + The "TH-id" type is a generalized means to identify the contents of a + typed hole. The "int32" alternative may be used for simple integer + assignments, in the same manner as "Int32", while the "rel-oid" + alternative may be used for hierarchical delegation. + +4.7. HostAddress and HostAddresses + + AddrType ::= Int32 + + HostAddress ::= SEQUENCE { + addr-type [0] AddrType, + address [1] OCTET STRING + } + + -- NOTE: HostAddresses is always used as an OPTIONAL field and + -- should not be a zero-length SEQUENCE OF. + -- + -- The extensible messages explicitly constrain this to be + -- non-empty. + HostAddresses ::= SEQUENCE OF HostAddress + + + addr-type + This field specifies the type of address that follows. + + address + This field encodes a single address of the type identified by + "addr-type". + + All negative values for the host address type are reserved for local + use. All non-negative values are reserved for officially assigned + type fields and interpretations. + + + addr-type | meaning + __________|______________ + 2 | IPv4 + 3 | directional + 12 | DECnet + 20 | NetBIOS + 24 | IPv6 + + + +Yu Expires: Apr 2007 [Page 17] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + +4.7.1. Internet (IPv4) Addresses + + Internet (IPv4) addresses are 32-bit (4-octet) quantities, encoded in + MSB order (most significant byte first). The IPv4 loopback address + SHOULD NOT appear in a Kerberos PDU. The type of IPv4 addresses is + two (2). + +4.7.2. Internet (IPv6) Addresses + + IPv6 addresses [RFC2373] are 128-bit (16-octet) quantities, encoded + in MSB order (most significant byte first). The type of IPv6 + addresses is twenty-four (24). The following addresses MUST NOT + appear in any Kerberos PDU: + + * the Unspecified Address + + * the Loopback Address + + * Link-Local addresses + + This restriction applies to the inclusion in the address fields of + Kerberos PDUs, but not to the address fields of packets that might + carry such PDUs. The restriction is necessary because the use of an + address with non-global scope could allow the acceptance of a message + sent from a node that may have the same address, but which is not the + host intended by the entity that added the restriction. If the + link-local address type needs to be used for communication, then the + address restriction in tickets must not be used (i.e. addressless + tickets must be used). + + IPv4-mapped IPv6 addresses MUST be represented as addresses of type + 2. + +4.7.3. DECnet Phase IV addresses + + DECnet Phase IV addresses are 16-bit addresses, encoded in LSB order. + The type of DECnet Phase IV addresses is twelve (12). + +4.7.4. Netbios addresses + + Netbios addresses are 16-octet addresses typically composed of 1 to + 15 alphanumeric characters and padded with the US-ASCII SPC character + (code 32). The 16th octet MUST be the US-ASCII NUL character (code + 0). The type of Netbios addresses is twenty (20). + +4.7.5. Directional Addresses + + In many environments, including the sender address in KRB-SAFE and + KRB-PRIV messages is undesirable because the addresses may be changed + in transport by network address translators. However, if these + addresses are removed, the messages may be subject to a reflection + +Yu Expires: Apr 2007 [Page 18] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + attack in which a message is reflected back to its originator. The + directional address type provides a way to avoid transport addresses + and reflection attacks. Directional addresses are encoded as four + byte unsigned integers in network byte order. If the message is + originated by the party sending the original AP-REQ message, then an + address of 0 SHOULD be used. If the message is originated by the + party to whom that AP-REQ was sent, then the address 1 SHOULD be + used. Applications involving multiple parties can specify the use of + other addresses. + + Directional addresses MUST only be used for the sender address field + in the KRB-SAFE or KRB-PRIV messages. They MUST NOT be used as a + ticket address or in a AP-REQ message. This address type SHOULD only + be used in situations where the sending party knows that the + receiving party supports the address type. This generally means that + directional addresses may only be used when the application protocol + requires their support. Directional addresses are type (3). + +5. Principals + + Principals are participants in the Kerberos protocol. A "realm" + consists of principals in one administrative domain, served by one + KDC (or one replicated set of KDCs). Each principal name has an + arbitrary number of components, though typical principal names will + only have one or two components. A principal name is meant to be + readable by and meaningful to humans, especially in a realm lacking a + centrally adminstered authorization infrastructure. + +5.1. Name Types + + Each PrincipalName has NameType indicating what sort of name it is. + The name-type SHOULD be treated as a hint. Ignoring the name type, + no two names can be the same (i.e., at least one of the components, + or the realm, must be different). + + + + + + + + + + + + + + + + + + +Yu Expires: Apr 2007 [Page 19] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + -- assigned numbers for name types (used in principal names) + NameType ::= Int32 + + -- Name type not known + nt-unknown NameType ::= 0 + -- Just the name of the principal as in DCE, or for users + nt-principal NameType ::= 1 + -- Service and other unique instance (krbtgt) + nt-srv-inst NameType ::= 2 + -- Service with host name as instance (telnet, rcommands) + nt-srv-hst NameType ::= 3 + -- Service with host as remaining components + nt-srv-xhst NameType ::= 4 + -- Unique ID + nt-uid NameType ::= 5 + -- Encoded X.509 Distingished name [RFC 2253] + nt-x500-principal NameType ::= 6 + -- Name in form of SMTP email name (e.g. user@foo.com) + nt-smtp-name NameType ::= 7 + -- Enterprise name - may be mapped to principal name + nt-enterprise NameType ::= 10 + + +5.2. Principal Type Definition + + The "PrincipalName" type takes a parameter to constrain which string + type it contains. + + PrincipalName { StrType } ::= SEQUENCE { + name-type [0] NameType, + -- May have zero elements, or individual elements may be + -- zero-length, but this is NOT RECOMMENDED. + name-string [1] SEQUENCE OF KerberosString (StrType) + } + + + The constrained types have their own names. + + -- IA5 only + PrincipalNameIA5 ::= PrincipalName { KerberosStringIA5 } + -- IA5 excluded + PrincipalNameExt ::= PrincipalName { KerberosStringExt } + -- Either one? + PrincipalNameEither ::= PrincipalName { KerberosString } + + + name-type + hint of the type of name that follows + + name-string + The "name-string" encodes a sequence of components that form a + +Yu Expires: Apr 2007 [Page 20] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + name, each component encoded as a KerberosString. Taken + together, a PrincipalName and a Realm form a principal + identifier. Most PrincipalNames will have only a few components + (typically one or two). + +5.3. Principal Name Reuse + + Realm administrators SHOULD use extreme caution when considering + reusing a principal name. A service administrator might explicitly + enter principal names into a local access control list (ACL) for the + service. If such local ACLs exist independently of a centrally + administered authorization infrastructure, realm administrators + SHOULD NOT reuse principal names until confirming that all extant ACL + entries referencing that principal name have been updated. Failure + to perform this check can result in a security vulnerability, as a + new principal can inadvertently inherit unauthorized privileges upon + receiving a reused principal name. An organization whose Kerberos- + authenticated services all use a centrally-adminstered authorization + infrastructure may not need to take these precautions regarding + principal name reuse. + +5.4. Best Common Practice Recommendations for the Processing of + Principal Names Consisting of Internationalized Domain Names: + + Kerberos principals are often created for the purpose of + authenticating a service located on a machine identified by an domain + name. Unfortunately, once a principal name is created it is + impossible to know the source from which the resulting KerberosString + was derived. It is therefore required that principal names + containing internationalized domain names be processed via the + following procedure: + + * ensure that the IDN component must be a valid domain name as per + the rules of IDNA [RFC3490] + + * separate the IDN component into labels separated by any of the + Full Stop characters + + * fold all Full Stop characters to Full Stop (0x002E) + + * for each label (perform all steps): + + o if the label begins with an ACE prefix as registered with IANA, + the prefix will be removed and the rest of the label will be + converted from the ACE representation to Unicode [need + reference] + + o if the label consists of one or more internationalized + characters separately apply the NamePrep and then the SASLprep + string preparation methods. + + +Yu Expires: Apr 2007 [Page 21] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + o if the label consists of zero internalizationalized characters, + the label is to be lower-cased + + o if the output of the two methods match, continue on to the next + label; otherwise reject the principal name as invalid + + * the result of a valid principal name component derived from an IDN + is the joining of the individual string prepared labels separated + by the Full Stop (0x002E) + +5.5. Realm Names + + Realm { StrType } ::= KerberosString (StrType) + + -- IA5 only + RealmIA5 ::= Realm { KerberosStringIA5 } + + -- IA5 excluded + RealmExt ::= Realm { KerberosStringExt } + + -- Either + RealmEither ::= Realm { KerberosString } + + + + Kerberos realm names are KerberosStrings. Realms MUST NOT contain a + character with the code 0 (the US-ASCII NUL). Most realms will + usually consist of several components separated by periods (.), in + the style of Internet Domain Names, or separated by slashes (/) in + the style of X.500 names. + +5.6. Best Common Practice Recommendations for the Processing of + Internationalized Domain-Style Realm Names: + + Domain Style Realm names are defined as all realm names whose + components are separated by Full Stop (0x002E) (aka periods, '.') and + contain neither colons, name containing one or more internationalized + characters (not included in US-ASCII), this procedure must be used: + + * the realm name must be a valid domain name as per the rules of + IDNA [RFC3490] + + * the following string preparation routine must be followed: + + - separate the string into components separated by any of the + Full Stop characters + + - fold all Full Stop characters to Full Stop (0x002E) + + - for each component (perform all steps): + + +Yu Expires: Apr 2007 [Page 22] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + o if the component begins with an ACE prefix as registered + with IANA, the prefix will be removed and the rest of the + component will be converted from the ACE representation to + Unicode [need reference] + + o if the component consists of one or more internationalized + characters separately apply the NamePrep and SASLprep string + preparation methods. + + if the output of the two methods match, continue on to the + next component; otherwise reject the realm name as invalid + + - the result of a valid realm name is the joining of the + individual string prepared components separated by the Full + Stop (0x002E) + + In [KCLAR], the recommendation is that all domain style realm names + be represented in uppercase. This recommendation is modified in the + following manner. All components of domain style realm names not + including internationalized characters should be upper-cased. All + components of domain style realm names including internationalized + characters must be lower-cased. (The lower case representation of + internationalized components is enforced by the requirement that the + output of NamePrep and StringPrep string preparation must be + equivalent.) + +5.7. Printable Representations of Principal Names + + [ perhaps non-normative? ] + + The printable form of a principal name consists of the concatenation + of components of the PrincipalName value using the slash character + (/), followed by an at-sign (@), followed by the realm name. Any + occurrence of a backslash (\), slash (/) or at-sign (@) in the + PrincipalName value is quoted by a backslash. + +5.8. Ticket-Granting Service Principal + + The PrincipalName value corresponding to a ticket-granting service + has two components: the first component is the string "krbtgt", and + the second component is the realm name of the TGS which will accept a + ticket-granting ticket having this service principal name. The realm + name of service always indicates which realm issued the ticket. A + ticket-granting ticket issued by "A.EXAMPLE.COM" which is valid for + obtaining tickets in the same realm would have the following ASN.1 + values for its "realm" and "sname" components, respectively: + + + + + + +Yu Expires: Apr 2007 [Page 23] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + -- Example Realm and PrincipalName for a TGS + + tgtRealm1 Realm ::= ia5 : "A.EXAMPLE.COM" + + tgtPrinc1 PrincipalName ::= { + name-type nt-srv-inst, + name-string { ia5 : "krbtgt", ia5 : "A.EXAMPLE.COM" } + } + + Its printable representation would be written as + "krbtgt/A.EXAMPLE.COM@A.EXAMPLE.COM". + +5.8.1. Cross-Realm TGS Principals + + It is possible for a principal in one realm to authenticate to a + service in another realm. A KDC can issue a cross-realm ticket- + granting ticket to allow one of its principals to authenticate to a + service in a foreign realm. For example, the TGS principal + "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM" is a principal that permits a + client principal in the realm A.EXAMPLE.COM to authenticate to a + service in the realm B.EXAMPLE.COM. When the KDC for B.EXAMPLE.COM + issues a ticket to a client originating in A.EXAMPLE.COM, the + client's realm name remains "A.EXAMPLE.COM", even though the service + principal will have the realm "B.EXAMPLE.COM". + +6. Types Relating to Encryption + + Many Kerberos protocol messages contain encrypted encodings of + various data types. Some Kerberos protocol messages also contain + checksums (signatures) of encodings of various types. + +6.1. Assigned Numbers for Encryption + + Encryption algorithm identifiers and key usages both have assigned + numbers, described in [KCRYPTO]. + +6.1.1. EType + + EType is the integer type for assigned numbers for encryption + algorithms. Defined in [KCRYPTO]. + + + + + + + + + + + + +Yu Expires: Apr 2007 [Page 24] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + -- Assigned numbers denoting encryption mechanisms. + EType ::= Int32 + + -- assigned numbers for encryption schemes + et-des-cbc-crc EType ::= 1 + et-des-cbc-md4 EType ::= 2 + et-des-cbc-md5 EType ::= 3 + -- [reserved] 4 + et-des3-cbc-md5 EType ::= 5 + -- [reserved] 6 + et-des3-cbc-sha1 EType ::= 7 + et-dsaWithSHA1-CmsOID EType ::= 9 + et-md5WithRSAEncryption-CmsOID EType ::= 10 + et-sha1WithRSAEncryption-CmsOID EType ::= 11 + et-rc2CBC-EnvOID EType ::= 12 + et-rsaEncryption-EnvOID EType ::= 13 + et-rsaES-OAEP-ENV-OID EType ::= 14 + et-des-ede3-cbc-Env-OID EType ::= 15 + et-des3-cbc-sha1-kd EType ::= 16 + -- AES + et-aes128-cts-hmac-sha1-96 EType ::= 17 + -- AES + et-aes256-cts-hmac-sha1-96 EType ::= 18 + -- Microsoft + et-rc4-hmac EType ::= 23 + -- Microsoft + et-rc4-hmac-exp EType ::= 24 + -- opaque; PacketCable + et-subkey-keymaterial EType ::= 65 + + +6.1.2. Key Usages + + KeyUsage is the integer type for assigned numbers for key usages. + Key usage values are inputs to the encryption and decryption + functions described in [KCRYPTO]. + + + + + + + + + + + + + + + + +Yu Expires: Apr 2007 [Page 25] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + -- Assigned numbers denoting key usages. + KeyUsage ::= UInt32 + + -- + -- Actual identifier names are provisional and subject to + -- change. + -- + ku-pa-enc-ts KeyUsage ::= 1 + ku-Ticket KeyUsage ::= 2 + ku-EncASRepPart KeyUsage ::= 3 + ku-TGSReqAuthData-sesskey KeyUsage ::= 4 + ku-TGSReqAuthData-subkey KeyUsage ::= 5 + ku-pa-TGSReq-cksum KeyUsage ::= 6 + ku-pa-TGSReq-authenticator KeyUsage ::= 7 + ku-EncTGSRepPart-sesskey KeyUsage ::= 8 + ku-EncTGSRepPart-subkey KeyUsage ::= 9 + ku-Authenticator-cksum KeyUsage ::= 10 + ku-APReq-authenticator KeyUsage ::= 11 + ku-EncAPRepPart KeyUsage ::= 12 + ku-EncKrbPrivPart KeyUsage ::= 13 + ku-EncKrbCredPart KeyUsage ::= 14 + ku-KrbSafe-cksum KeyUsage ::= 15 + ku-ad-KDCIssued-cksum KeyUsage ::= 19 + + + -- The following numbers are provisional... + -- conflicts may exist elsewhere. + ku-Ticket-cksum KeyUsage ::= 29 + ku-ASReq-cksum KeyUsage ::= 30 + ku-TGSReq-cksum KeyUsage ::= 31 + ku-ASRep-cksum KeyUsage ::= 32 + ku-TGSRep-cksum KeyUsage ::= 33 + ku-APReq-cksum KeyUsage ::= 34 + ku-APRep-cksum KeyUsage ::= 35 + ku-KrbCred-cksum KeyUsage ::= 36 + ku-KrbError-cksum KeyUsage ::= 37 + ku-KDCRep-cksum KeyUsage ::= 38 + + ku-kg-acceptor-seal KeyUsage ::= 22 + ku-kg-acceptor-sign KeyUsage ::= 23 + ku-kg-intiator-seal KeyUsage ::= 24 + ku-kg-intiator-sign KeyUsage ::= 25 + + -- KeyUsage values 25..27 used by hardware preauth? + + -- for KINK + ku-kink-encrypt KeyUsage ::= 39 + ku-kink-cksum KeyUsage ::= 40 + + + + +Yu Expires: Apr 2007 [Page 26] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + +6.2. Which Key to Use + + -- KeyToUse identifies which key is to be used to encrypt or + -- sign a given value. + -- + -- Values of KeyToUse are never actually transmitted over the + -- wire, or even used directly by the implementation in any + -- way, as key usages are; it exists primarily to identify + -- which key gets used for what purpose. Thus, the specific + -- numeric values associated with this type are irrelevant. + KeyToUse ::= ENUMERATED { + -- unspecified + key-unspecified, + -- server long term key + key-server, + -- client long term key + key-client, + -- key selected by KDC for encryption of a KDC-REP + key-kdc-rep, + -- session key from ticket + key-session, + -- subsession key negotiated via AP-REQ/AP-REP + key-subsession, + ... + } + + +6.3. EncryptionKey + + The "EncryptionKey" type holds an encryption key. + + EncryptionKey ::= SEQUENCE { + keytype [0] EType, + keyvalue [1] OCTET STRING + } + + + keytype + This "EType" identifies the encryption algorithm, described in + [KCRYPTO]. + + keyvalue + Contains the actual key. + +6.4. EncryptedData + + The "EncryptedData" type contains the encryption of another data + type. The recipient uses fields within EncryptedData to determine + which key to use for decryption. + + + +Yu Expires: Apr 2007 [Page 27] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + + -- "Type" specifies which ASN.1 type is encrypted to the + -- ciphertext in the EncryptedData. "Keys" specifies a set of + -- keys of which one key may be used to encrypt the data. + -- "KeyUsages" specifies a set of key usages, one of which may + -- be used to encrypt. + -- + -- None of the parameters is transmitted over the wire. + EncryptedData { + Type, KeyToUse:Keys, KeyUsage:KeyUsages + } ::= SEQUENCE { + etype [0] EType, + kvno [1] UInt32 OPTIONAL, + cipher [2] OCTET STRING (CONSTRAINED BY { + -- must be encryption of -- + OCTET STRING (CONTAINING Type), + -- with one of the keys -- KeyToUse:Keys, + -- with key usage being one of -- + KeyUsage:KeyUsages + }), + ... + } + + + + KeyUsages + Advisory parameter indicating which key usage to use when + encrypting the ciphertext. If "KeyUsages" indicate multiple + "KeyUsage" values, the detailed description of the containing + message will indicate which key to use under which conditions. + + Type + Advisory parameter indicating the ASN.1 type whose DER encoding + is the plaintext encrypted into the EncryptedData. + + Keys + Advisory parameter indicating which key to use to perform the + encryption. If "Keys" indicate multiple "KeyToUse" values, the + detailed description of the containing message will indicate + which key to use under which conditions. + + KeyUsages + Advisory parameter indicating which "KeyUsage" value is used to + encrypt. If "KeyUsages" indicates multiple "KeyUsage" values, + the detailed description of the containing message will indicate + which key usage to use under which conditions. + +6.5. Checksums + + Several types contain checksums (actually signatures) of data. + + +Yu Expires: Apr 2007 [Page 28] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + CksumType ::= Int32 + + -- The parameters specify which key to use to produce the + -- signature, as well as which key usage to use. The + -- parameters are not actually sent over the wire. + Checksum { + KeyToUse:Keys, KeyUsage:KeyUsages + } ::= SEQUENCE { + cksumtype [0] CksumType, + checksum [1] OCTET STRING (CONSTRAINED BY { + -- signed using one of the keys -- + KeyToUse:Keys, + -- with key usage being one of -- + KeyUsage:KeyUsages + }) + } + + + CksumType + Integer type for assigned numbers for signature algorithms. + Defined in [KCRYPTO] + + Keys + As in EncryptedData + + KeyUsages + As in EncryptedData + + cksumtype + Signature algorithm used to produce the signature. + + checksum + The actual checksum. + +6.5.1. ChecksumOf + + ChecksumOf is similar to "Checksum", but specifies which type is + signed. + + -- a Checksum that must contain the checksum + -- of a particular type + ChecksumOf { + Type, KeyToUse:Keys, KeyUsage:KeyUsages + } ::= Checksum { Keys, KeyUsages } (WITH COMPONENTS { + ..., + checksum (CONSTRAINED BY { + -- must be checksum of -- + OCTET STRING (CONTAINING Type) + }) + }) + + +Yu Expires: Apr 2007 [Page 29] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + Type + Indicates the ASN.1 type whose DER encoding is signed. + +6.5.2. Signed + + Signed is similar to "ChecksumOf", but contains an actual instance of + the type being signed in addition to the signature. + + -- parameterized type for wrapping authenticated plaintext + Signed { + InnerType, KeyToUse:Keys, KeyUsage:KeyUsages + } ::= SEQUENCE { + cksum [0] ChecksumOf { + InnerType, Keys, KeyUsages + } OPTIONAL, + inner [1] InnerType, + ... + } + + +7. Tickets + + [ A large number of items described here are duplicated in the + sections describing KDC-REQ processing. Should find a way to avoid + this duplication. ] + + A ticket binds a principal name to a session key. The important + fields of a ticket are in the encrypted part. + + -- Encrypted part of ticket + EncTicketPart ::= CHOICE { + rfc1510 EncTicketPart1510, + ext EncTicketPartExt + } + + + EncTicketPart1510 ::= [APPLICATION 3] SEQUENCE { + flags [0] TicketFlags, + key [1] EncryptionKey, + crealm [2] RealmIA5, + cname [3] PrincipalNameIA5, + transited [4] TransitedEncoding, + authtime [5] KerberosTime, + starttime [6] KerberosTime OPTIONAL, + endtime [7] KerberosTime, + renew-till [8] KerberosTime OPTIONAL, + caddr [9] HostAddresses OPTIONAL, + authorization-data [10] AuthorizationData OPTIONAL + } + + + +Yu Expires: Apr 2007 [Page 30] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + EncTicketPartExt ::= [APPLICATION 5] SEQUENCE { + flags [0] TicketFlags, + key [1] EncryptionKey, + crealm [2] RealmExt, + cname [3] PrincipalNameExt, + transited [4] TransitedEncoding, + authtime [5] KerberosTime, + starttime [6] KerberosTime OPTIONAL, + endtime [7] KerberosTime, + renew-till [8] KerberosTime OPTIONAL, + caddr [9] HostAddresses OPTIONAL, + authorization-data [10] AuthorizationData OPTIONAL, + ..., + } + + + crealm + This field contains the client's realm. + + cname + This field contains the client's name. + + caddr + This field lists the network addresses (if absent, all addresses + are permitted) from which the ticket is valid. + + Descriptions of the other fields appear in the following sections. + +7.1. Timestamps + + Three of the ticket timestamps may be requested from the KDC. The + timestamps may differ from those requested, depending on site policy. + + authtime + The time at which the client authenticated, as recorded by the + KDC. + + starttime + The earliest time when the ticket is valid. If not present, the + ticket is valid starting at the authtime. This is requested as + the "from" field of KDC-REQ-BODY. + + endtime + This time is requested in the "till" field of KDC-REQ-BODY. + Contains the time after which the ticket will not be honored + (its expiration time). Note that individual services MAY place + their own limits on the life of a ticket and MAY reject tickets + which have not yet expired. As such, this is really an upper + bound on the expiration time for the ticket. + + + +Yu Expires: Apr 2007 [Page 31] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + renew-till + This time is requested in the "rtime" field of KDC-REQ-BODY. It + is only present in tickets that have the "renewable" flag set in + the flags field. It indicates the maximum endtime that may be + included in a renewal. It can be thought of as the absolute + expiration time for the ticket, including all renewals. + +7.2. Ticket Flags + + A number of flags may be set in the ticket, further defining some of + its capabilities. Some of these flags map to flags in a KDC request. + + TicketFlags ::= KerberosFlags { TicketFlagsBits } + + TicketFlagsBits ::= BIT STRING { + reserved (0), + forwardable (1), + forwarded (2), + proxiable (3), + proxy (4), + may-postdate (5), + postdated (6), + invalid (7), + renewable (8), + initial (9), + pre-authent (10), + hw-authent (11), + transited-policy-checked (12), + ok-as-delegate (13), + anonymous (14), + cksummed-ticket (15) + } + + +7.2.1. Flags Relating to Initial Ticket Acquisition + + [ adapted KCLAR 2.1. ] + + Several flags indicate the details of how the initial ticket was + acquired. + + initial + The "initial" flag indicates that a ticket was issued using the + AS protocol, rather than issued based on a ticket-granting + ticket. Application servers (e.g., a password-changing program) + requiring a client's definite knowledge of its secret key can + insist that this flag be set in any tickets they accept, thus + being assured that the client's key was recently presented to + the application client. + + + +Yu Expires: Apr 2007 [Page 32] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + pre-authent + The "pre-authent" flag indicates that some sort of pre- + authentication was used during the AS exchange. + + hw-authent + The "hw-authent" flag indicates that some sort of hardware-based + pre-authentication occurred during the AS exchange. + + Both the "pre-authent" and the "hw-authent" flags may be present with + or without the "initial" flag; such tickets with the "initial" flag + clear are ones which are derived from initial tickets with the "pre- + authent" or "hw-authent" flags set. + +7.2.2. Invalid Tickets + + [ KCLAR 2.2. ] + + The "invalid" flag indicates that a ticket is invalid. Application + servers MUST reject tickets which have this flag set. A postdated + ticket will be issued in this form. Invalid tickets MUST be + validated by the KDC before use, by presenting them to the KDC in a + TGS request with the "validate" option specified. The KDC will only + validate tickets after their starttime has passed. The validation is + required so that postdated tickets which have been stolen before + their starttime can be rendered permanently invalid (through a hot- + list mechanism -- see Section 8.3.2.4). + +7.2.3. OK as Delegate + + [ KCLAR 2.8. ] + + The "ok-as-delegate" flag provides a way for a KDC to communicate + local realm policy to a client regarding whether the service for + which the ticket is issued is trusted to accept delegated + credentials. For some applications, a client may need to delegate + credentials to a service to act on its behalf in contacting other + services. The ability of a client to obtain a service ticket for a + service conveys no information to the client about whether the + service should be trusted to accept delegated credentials. + + The copy of the ticket flags visible to the client may have the "ok- + as-delegate" flag set to indicate to the client that the service + specified in the ticket has been determined by policy of the realm to + be a suitable recipient of delegation. A client can use the presence + of this flag to help it make a decision whether to delegate + credentials (either grant a proxy or a forwarded ticket-granting + ticket) to this service. It is acceptable to ignore the value of + this flag. When setting this flag, an administrator should consider + the security and placement of the server on which the service will + run, as well as whether the service requires the use of delegated + credentials. + +Yu Expires: Apr 2007 [Page 33] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + +7.2.4. Renewable Tickets + + [ adapted KCLAR 2.3. ] + + The "renewable" flag indicates whether the ticket may be renewed. + + Renewable tickets can be used to mitigate the consequences of ticket + theft. Applications may desire to hold credentials which can be + valid for long periods of time. However, this can expose the + credentials to potential theft for equally long periods, and those + stolen credentials would be valid until the expiration time of the + ticket(s). Simply using short-lived tickets and obtaining new ones + periodically would require the application to have long-term access + to the client's secret key, which is an even greater risk. + + Renewable tickets have two "expiration times": the first is when the + current instance of the ticket expires, and the second is the latest + permissible value for an individual expiration time. An application + client must periodically present an unexpired renewable ticket to the + KDC, setting the "renew" option in the KDC request. The KDC will + issue a new ticket with a new session key and a later expiration + time. All other fields of the ticket are left unmodified by the + renewal process. When the latest permissible expiration time + arrives, the ticket expires permanently. At each renewal, the KDC + MAY consult a hot-list to determine if the ticket had been reported + stolen since its last renewal; it will refuse to renew such stolen + tickets, and thus the usable lifetime of stolen tickets is reduced. + + The "renewable" flag in a ticket is normally only interpreted by the + ticket-granting service. It can usually be ignored by application + servers. However, some particularly careful application servers MAY + disallow renewable tickets. + + If a renewable ticket is not renewed by its expiration time, the KDC + will not renew the ticket. The "renewable" flag is clear by default, + but a client can request it be set by setting the "renewable" option + in the AS-REQ message. If it is set, then the "renew-till" field in + the ticket contains the time after which the ticket may not be + renewed. + +7.2.5. Postdated Tickets + + postdated + indicates a ticket which has been postdated + + may-postdate + indicates that postdated tickets may be issued based on this + ticket + + [ KCLAR 2.4. ] + + +Yu Expires: Apr 2007 [Page 34] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + Applications may occasionally need to obtain tickets for use much + later, e.g., a batch submission system would need tickets to be valid + at the time the batch job is serviced. However, it is dangerous to + hold valid tickets in a batch queue, since they will be on-line + longer and more prone to theft. Postdated tickets provide a way to + obtain these tickets from the KDC at job submission time, but to + leave them "dormant" until they are activated and validated by a + further request of the KDC. If a ticket theft were reported in the + interim, the KDC would refuse to validate the ticket, and the thief + would be foiled. + + The "may-postdate" flag in a ticket is normally only interpreted by + the TGS. It can be ignored by application servers. This flag MUST + be set in a ticket-granting ticket in order for the KDC to issue a + postdated ticket based on the presented ticket. It is reset by + default; it MAY be requested by a client by setting the "allow- + postdate" option in the AS-REQ [?also TGS-REQ?] message. This flag + does not allow a client to obtain a postdated ticket-granting ticket; + postdated ticket-granting tickets can only by obtained by requesting + the postdating in the AS-REQ message. The life (endtime minus + starttime) of a postdated ticket will be the remaining life of the + ticket-granting ticket at the time of the request, unless the + "renewable" option is also set, in which case it can be the full life + (endtime minus starttime) of the ticket-granting ticket. The KDC MAY + limit how far in the future a ticket may be postdated. + + The "postdated" flag indicates that a ticket has been postdated. The + application server can check the authtime field in the ticket to see + when the original authentication occurred. Some services MAY choose + to reject postdated tickets, or they may only accept them within a + certain period after the original authentication. When the KDC + issues a "postdated" ticket, it will also be marked as "invalid", so + that the application client MUST present the ticket to the KDC for + validation before use. + +7.2.6. Proxiable and Proxy Tickets + + proxy + indicates a proxy ticket + + proxiable + indicates that proxy tickets may be issued based on this ticket + + [ KCLAR 2.5. ] + + It may be necessary for a principal to allow a service to perform an + operation on its behalf. The service must be able to take on the + identity of the client, but only for a particular purpose. A + principal can allow a service to take on the principal's identity for + a particular purpose by granting it a proxy. + + +Yu Expires: Apr 2007 [Page 35] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + The process of granting a proxy using the "proxy" and "proxiable" + flags is used to provide credentials for use with specific services. + Though conceptually also a proxy, users wishing to delegate their + identity in a form usable for all purposes MUST use the ticket + forwarding mechanism described in the next section to forward a + ticket-granting ticket. + + The "proxiable" flag in a ticket is normally only interpreted by the + ticket-granting service. It can be ignored by application servers. + When set, this flag tells the ticket-granting server that it is OK to + issue a new ticket (but not a ticket-granting ticket) with a + different network address based on this ticket. This flag is set if + requested by the client on initial authentication. By default, the + client will request that it be set when requesting a ticket-granting + ticket, and reset when requesting any other ticket. + + This flag allows a client to pass a proxy to a server to perform a + remote request on its behalf (e.g. a print service client can give + the print server a proxy to access the client's files on a particular + file server in order to satisfy a print request). + + In order to complicate the use of stolen credentials, Kerberos + tickets may contain a set of network addresses from which they are + valid. When granting a proxy, the client MUST specify the new + network address from which the proxy is to be used, or indicate that + the proxy is to be issued for use from any address. + + The "proxy" flag is set in a ticket by the TGS when it issues a proxy + ticket. Application servers MAY check this flag and at their option + they MAY require additional authentication from the agent presenting + the proxy in order to provide an audit trail. + +7.2.7. Forwarded and Forwardable Tickets + + forwarded + indicates a forwarded ticket + + forwardable + indicates that forwarded tickets may be issued based on this + ticket + + [ KCLAR 2.6. ] + + Authentication forwarding is an instance of a proxy where the service + that is granted is complete use of the client's identity. An example + where it might be used is when a user logs in to a remote system and + wants authentication to work from that system as if the login were + local. + + The "forwardable" flag in a ticket is normally only interpreted by + the ticket-granting service. It can be ignored by application + +Yu Expires: Apr 2007 [Page 36] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + servers. The "forwardable" flag has an interpretation similar to + that of the "proxiable" flag, except ticket-granting tickets may also + be issued with different network addresses. This flag is reset by + default, but users MAY request that it be set by setting the + "forwardable" option in the AS request when they request their + initial ticket-granting ticket. + + This flag allows for authentication forwarding without requiring the + user to enter a password again. If the flag is not set, then + authentication forwarding is not permitted, but the same result can + still be achieved if the user engages in the AS exchange specifying + the requested network addresses and supplies a password. + + The "forwarded" flag is set by the TGS when a client presents a + ticket with the "forwardable" flag set and requests a forwarded + ticket by specifying the "forwarded" KDC option and supplying a set + of addresses for the new ticket. It is also set in all tickets + issued based on tickets with the "forwarded" flag set. Application + servers may choose to process "forwarded" tickets differently than + non-forwarded tickets. + + If addressless tickets are forwarded from one system to another, + clients SHOULD still use this option to obtain a new TGT in order to + have different session keys on the different systems. + +7.3. Transited Realms + + [ KCLAR 2.7., plus new stuff ] + +7.4. Authorization Data + + [ KCLAR 5.2.6. ] + + ADType ::= TH-id + + AuthorizationData ::= SEQUENCE OF SEQUENCE { + ad-type [0] ADType, + ad-data [1] OCTET STRING + } + + + ad-type + This field identifies the contents of the ad-data. All negative + values are reserved for local use. Non-negative values are + reserved for registered use. + + ad-data + This field contains authorization data to be interpreted + according to the value of the corresponding ad-type field. + + + +Yu Expires: Apr 2007 [Page 37] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + Each sequence of ADType and OCTET STRING is referred to as an + authorization element. Elements MAY be application specific, + however, there is a common set of recursive elements that should be + understood by all implementations. These elements contain other + AuthorizationData, and the interpretation of the encapsulating + element determines which enclosed elements must be interpreted, and + which may be ignored. + + Depending on the meaning of the encapsulating element, the + encapsulated AuthorizationData may be ignored, interpreted as issued + directly by the KDC, or be stored in a separate plaintext part of the + ticket. The types of the encapsulating elements are specified as + part of the Kerberos protocol because behavior based on these + container elements should be understood across implementations, while + other elements need only be understood by the applications which they + affect. + + Authorization data elements are considered critical if present in a + ticket or authenticator. Unless encapsulated in a known + authorization data element modifying the criticality of the elements + it contains, an application server MUST reject the authentication of + a client whose AP-REQ or ticket contains an unrecognized + authorization data element. Authorization data is intended to + restrict the use of a ticket. If the service cannot determine + whether it is the target of a restriction, a security weakness may + exist if the ticket can be used for that service. Authorization + elements that are truly optional can be enclosed in AD-IF-RELEVANT + element. + + + ad-type | contents of ad-data + ________|_______________________________________ + 1 | DER encoding of AD-IF-RELEVANT + 4 | DER encoding of AD-KDCIssued + 5 | DER encoding of AD-AND-OR + 8 | DER encoding of AD-MANDATORY-FOR-KDC + + + +7.4.1. AD-IF-RELEVANT + + ad-if-relevant ADType ::= int32 : 1 + + -- Encapsulates another AuthorizationData. + -- Intended for application servers; receiving application servers + -- MAY ignore. + AD-IF-RELEVANT ::= AuthorizationData + + AD elements encapsulated within the if-relevant element are intended + for interpretation only by application servers that understand the + particular ad-type of the embedded element. Application servers that + +Yu Expires: Apr 2007 [Page 38] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + do not understand the type of an element embedded within the if- + relevant element MAY ignore the uninterpretable element. This element + promotes interoperability across implementations which may have local + extensions for authorization. The ad-type for AD-IF-RELEVANT is (1). + +7.4.2. AD-KDCIssued + + -- KDC-issued privilege attributes + ad-kdcissued ADType ::= int32 : 4 + + AD-KDCIssued ::= SEQUENCE { + ad-checksum [0] ChecksumOf { + AuthorizationData, { key-session }, + { ku-ad-KDCIssued-cksum }}, + i-realm [1] Realm OPTIONAL, + i-sname [2] PrincipalName OPTIONAL, + elements [3] AuthorizationData + } + + + ad-checksum + A cryptographic checksum computed over the DER encoding of the + AuthorizationData in the "elements" field, keyed with the + session key. Its checksumtype is the mandatory checksum type + for the encryption type of the session key, and its key usage + value is 19. + + i-realm, i-sname + The name of the issuing principal if different from the KDC + itself. This field would be used when the KDC can verify the + authenticity of elements signed by the issuing principal and it + allows this KDC to notify the application server of the validity + of those elements. + + elements + AuthorizationData issued by the KDC. + + The KDC-issued ad-data field is intended to provide a means for + Kerberos credentials to embed within themselves privilege attributes + and other mechanisms for positive authorization, amplifying the + privileges of the principal beyond what it would have if using + credentials without such an authorization-data element. + + This amplification of privileges cannot be provided without this + element because the definition of the authorization-data field allows + elements to be added at will by the bearer of a TGT at the time that + they request service tickets and elements may also be added to a + delegated ticket by inclusion in the authenticator. + + For KDC-issued elements this is prevented because the elements are + signed by the KDC by including a checksum encrypted using the + +Yu Expires: Apr 2007 [Page 39] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + server's key (the same key used to encrypt the ticket -- or a key + derived from that key). AuthorizationData encapsulated with in the + AD-KDCIssued element MUST be ignored by the application server if + this "signature" is not present. Further, AuthorizationData + encapsulated within this element from a ticket-granting ticket MAY be + interpreted by the KDC, and used as a basis according to policy for + including new signed elements within derivative tickets, but they + will not be copied to a derivative ticket directly. If they are + copied directly to a derivative ticket by a KDC that is not aware of + this element, the signature will not be correct for the application + ticket elements, and the field will be ignored by the application + server. + + This element and the elements it encapsulates MAY be safely ignored + by applications, application servers, and KDCs that do not implement + this element. + + The ad-type for AD-KDC-ISSUED is (4). + +7.4.3. AD-AND-OR + + ad-and-or ADType ::= int32 : 5 + + AD-AND-OR ::= SEQUENCE { + condition-count [0] Int32, + elements [1] AuthorizationData + } + + + When restrictive AD elements are encapsulated within the and-or + element, the and-or element is considered satisfied if and only if at + least the number of encapsulated elements specified in condition- + count are satisfied. Therefore, this element MAY be used to + implement an "or" operation by setting the condition-count field to + 1, and it MAY specify an "and" operation by setting the condition + count to the number of embedded elements. Application servers that do + not implement this element MUST reject tickets that contain + authorization data elements of this type. + + The ad-type for AD-AND-OR is (5). + +7.4.4. AD-MANDATORY-FOR-KDC + + -- KDCs MUST interpret any AuthorizationData wrapped in this. + ad-mandatory-for-kdc ADType ::= int32 : 8 + AD-MANDATORY-FOR-KDC ::= AuthorizationData + + AD elements encapsulated within the mandatory-for-kdc element are to + be interpreted by the KDC. KDCs that do not understand the type of + an element embedded within the mandatory-for-kdc element MUST reject + the request. + +Yu Expires: Apr 2007 [Page 40] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + The ad-type for AD-MANDATORY-FOR-KDC is (8). + +7.5. Encrypted Part of Ticket + + The complete definition of the encrypted part is + + -- Encrypted part of ticket + EncTicketPart ::= CHOICE { + rfc1510 EncTicketPart1510, + ext EncTicketPartExt + } + + + The encrypted part of the backwards-compatibility form of a ticket + is: + + EncTicketPart1510 ::= [APPLICATION 3] SEQUENCE { + flags [0] TicketFlags, + key [1] EncryptionKey, + crealm [2] RealmIA5, + cname [3] PrincipalNameIA5, + transited [4] TransitedEncoding, + authtime [5] KerberosTime, + starttime [6] KerberosTime OPTIONAL, + endtime [7] KerberosTime, + renew-till [8] KerberosTime OPTIONAL, + caddr [9] HostAddresses OPTIONAL, + authorization-data [10] AuthorizationData OPTIONAL + } + + The encrypted part of the extensible form of a ticket is: + + EncTicketPartExt ::= [APPLICATION 5] SEQUENCE { + flags [0] TicketFlags, + key [1] EncryptionKey, + crealm [2] RealmExt, + cname [3] PrincipalNameExt, + transited [4] TransitedEncoding, + authtime [5] KerberosTime, + starttime [6] KerberosTime OPTIONAL, + endtime [7] KerberosTime, + renew-till [8] KerberosTime OPTIONAL, + caddr [9] HostAddresses OPTIONAL, + authorization-data [10] AuthorizationData OPTIONAL, + ..., + } + + + + + + +Yu Expires: Apr 2007 [Page 41] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + +7.6. Cleartext Part of Ticket + + The complete definition of Ticket is: + + Ticket ::= CHOICE { + rfc1510 Ticket1510, + ext TicketExt + } + + + The "sname" field provides the name of the target service principal + in cleartext, as a hint to aid the server in choosing the correct + decryption key. + + The backwards-compatibility form of Ticket is: + + Ticket1510 ::= [APPLICATION 1] SEQUENCE { + tkt-vno [0] INTEGER (5), + realm [1] RealmIA5, + sname [2] PrincipalNameIA5, + enc-part [3] EncryptedData { + EncTicketPart1510, { key-server }, { ku-Ticket } + } + } + + The extensible form of Ticket is: + + TicketExt ::= [APPLICATION 4] Signed { + [APPLICATION 4] SEQUENCE { + tkt-vno [0] INTEGER (5), + realm [1] RealmExt, + sname [2] PrincipalNameExt, + enc-part [3] EncryptedData { + EncTicketPartExt, { key-server }, { ku-Ticket } + }, + ..., + extensions [4] TicketExtensions OPTIONAL, + ... + }, + { key-ticket }, { ku-Ticket-cksum } + } + + + TicketExtensions, which may only be present in the extensible form of + Ticket, are a cleartext typed hole for extension use. + AuthorizationData already provides an encrypted typed hole. + + + + + + +Yu Expires: Apr 2007 [Page 42] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + TEType ::= TH-id + + -- ticket extensions: for TicketExt only + TicketExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE { + te-type [0] TEType, + te-data [1] OCTET STRING + } + + + A client will only receive an extensible Ticket if the application + server supports extensibility. + +8. Credential Acquisition + + There are two exchanges that can be used for acquiring credentials: + the AS exchange and the TGS exchange. These exchanges have many + similarities, and this document describes them in parallel, noting + which behaviors are specific to one type of exchange. The AS request + (AS-REQ) and TGS request (TGS-REQ) are both forms of KDC requests + (KDC-REQ). Likewise, the AS reply (AS-REP) and TGS reply (TGS-REP) + are forms of KDC replies (KDC-REP). + + The credentials acquisition protocol operates over specific + transports. Additionally, specific methods exist to permit a client + to discover the KDC host with which to communicate. + +8.1. KDC-REQ + + The KDC-REQ has a large number of fields in common between the RFC + 1510 and the extensible versions. The KDC-REQ type itself is never + directly encoded; it is always a part of a AS-REQ or a TGS-REQ. + + KDC-REQ-1510 ::= SEQUENCE { + -- NOTE: first tag is [1], not [0] + pvno [1] INTEGER (5), + msg-type [2] INTEGER ( 10 -- AS-REQ -- + | 12 -- TGS-REQ -- ), + padata [3] SEQUENCE OF PA-DATA OPTIONAL, + req-body [4] KDC-REQ-BODY-1510 + } + + + KDC-REQ-EXT ::= SEQUENCE { + pvno [1] INTEGER (5), + msg-type [2] INTEGER ( 6 -- AS-REQ -- + | 8 -- TGS-REQ -- ), + padata [3] SEQUENCE (SIZE (1..MAX)) OF PA-DATA OPTIONAL, + req-body [4] KDC-REQ-BODY-EXT, + ... + } + + +Yu Expires: Apr 2007 [Page 43] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + KDC-REQ-BODY-1510 ::= SEQUENCE { + kdc-options [0] KDCOptions, + cname [1] PrincipalNameIA5 OPTIONAL + -- Used only in AS-REQ --, + + realm [2] RealmIA5 + -- Server's realm; also client's in AS-REQ --, + + sname [3] PrincipalNameIA5 OPTIONAL, + from [4] KerberosTime OPTIONAL, + till [5] KerberosTime, + rtime [6] KerberosTime OPTIONAL, + nonce [7] Nonce32, + etype [8] SEQUENCE OF EType + -- in preference order --, + + addresses [9] HostAddresses OPTIONAL, + enc-authorization-data [10] EncryptedData { + AuthorizationData, { key-session | key-subsession }, + { ku-TGSReqAuthData-subkey | + ku-TGSReqAuthData-sesskey } + } OPTIONAL, + + additional-tickets [11] SEQUENCE OF Ticket OPTIONAL + -- NOTE: not empty -- + } + + + + + + + + + + + + + + + + + + + + + + + + + + +Yu Expires: Apr 2007 [Page 44] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + KDC-REQ-BODY-EXT ::= SEQUENCE { + kdc-options [0] KDCOptions, + cname [1] PrincipalName OPTIONAL + -- Used only in AS-REQ --, + + realm [2] Realm + -- Server's realm; also client's in AS-REQ --, + + sname [3] PrincipalName OPTIONAL, + from [4] KerberosTime OPTIONAL, + till [5] KerberosTime OPTIONAL + -- was required in rfc1510; + -- still required for compat versions + -- of messages --, + + rtime [6] KerberosTime OPTIONAL, + nonce [7] Nonce, + etype [8] SEQUENCE OF EType + -- in preference order --, + + addresses [9] HostAddresses OPTIONAL, + enc-authorization-data [10] EncryptedData { + AuthorizationData, { key-session | key-subsession }, + { ku-TGSReqAuthData-subkey | + ku-TGSReqAuthData-sesskey } + } OPTIONAL, + + additional-tickets [11] SEQUENCE OF Ticket OPTIONAL + -- NOTE: not empty --, + ... + lang-tags [5] SEQUENCE (SIZE (1..MAX)) OF + LangTag OPTIONAL, + ... + } + + + Many fields of KDC-REQ-BODY correspond directly to fields of an + EncTicketPart. The KDC copies most of them unchanged, provided that + the requested values meet site policy. + + kdc-options + These flags do not correspond directly to "flags" in + EncTicketPart. + + cname + This field is copied to the "cname" field in EncTicketPart. The + "cname" field is required in an AS-REQ; the client places its + own name here. In a TGS-REQ, the "cname" in the ticket in the + AP-REQ takes precedence. + + + +Yu Expires: Apr 2007 [Page 45] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + realm + This field is the server's realm, and also holds the client's + realm in an AS-REQ. + + sname + The "sname" field indicates the server's name. It may be absent + in a TGS-REQ which requests user-to-user authentication, in + which case the "sname" of the issued ticket will be taken from + the included additional ticket. + + The "from", "till", and "rtime" fields correspond to the "starttime", + "endtime", and "renew-till" fields of EncTicketPart. + + addresses + This field corresponds to the "caddr" field of EncTicketPart. + + enc-authorization-data + For TGS-REQ, this field contains authorization data encrypted + using either the TGT session key or the AP-REQ subsession key; + the KDC may copy these into the "authorization-data" field of + EncTicketPart if policy permits. + + lang-tags + Only present in the extensible messages. Specifies the set of + languages which the client is willing to accept in error + messages. + + KDC options used in a KDC-REQ are: + + + + + + + + + + + + + + + + + + + + + + + + +Yu Expires: Apr 2007 [Page 46] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + KDCOptions ::= KerberosFlags { KDCOptionsBits } + + KDCOptionsBits ::= BIT STRING { + reserved (0), + forwardable (1), + forwarded (2), + proxiable (3), + proxy (4), + allow-postdate (5), + postdated (6), + unused7 (7), + renewable (8), + unused9 (9), + unused10 (10), + unused11 (11), + unused12 (12), + unused13 (13), + requestanonymous (14), + canonicalize (15), + disable-transited-check (26), + renewable-ok (27), + enc-tkt-in-skey (28), + renew (30), + validate (31) + -- XXX need "need ticket1" flag? + } + + Different options apply to different phases of KDC-REQ processing. + + The backwards-compatibility form of a KDC-REQ is: + + KDC-REQ-1510 ::= SEQUENCE { + -- NOTE: first tag is [1], not [0] + pvno [1] INTEGER (5), + msg-type [2] INTEGER ( 10 -- AS-REQ -- + | 12 -- TGS-REQ -- ), + padata [3] SEQUENCE OF PA-DATA OPTIONAL, + req-body [4] KDC-REQ-BODY-1510 + } + + The extensible form of a KDC-REQ is: + + KDC-REQ-EXT ::= SEQUENCE { + pvno [1] INTEGER (5), + msg-type [2] INTEGER ( 6 -- AS-REQ -- + | 8 -- TGS-REQ -- ), + padata [3] SEQUENCE (SIZE (1..MAX)) OF PA-DATA OPTIONAL, + req-body [4] KDC-REQ-BODY-EXT, + ... + } + + +Yu Expires: Apr 2007 [Page 47] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + The backwards-compatibility form of a KDC-REQ-BODY is: + + KDC-REQ-BODY-1510 ::= SEQUENCE { + kdc-options [0] KDCOptions, + cname [1] PrincipalNameIA5 OPTIONAL + -- Used only in AS-REQ --, + + realm [2] RealmIA5 + -- Server's realm; also client's in AS-REQ --, + + sname [3] PrincipalNameIA5 OPTIONAL, + from [4] KerberosTime OPTIONAL, + till [5] KerberosTime, + rtime [6] KerberosTime OPTIONAL, + nonce [7] Nonce32, + etype [8] SEQUENCE OF EType + -- in preference order --, + + addresses [9] HostAddresses OPTIONAL, + enc-authorization-data [10] EncryptedData { + AuthorizationData, { key-session | key-subsession }, + { ku-TGSReqAuthData-subkey | + ku-TGSReqAuthData-sesskey } + } OPTIONAL, + + additional-tickets [11] SEQUENCE OF Ticket OPTIONAL + -- NOTE: not empty -- + } + + The extensible form of a KDC-REQ-BODY is: + + + + + + + + + + + + + + + + + + + + + + +Yu Expires: Apr 2007 [Page 48] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + KDC-REQ-BODY-EXT ::= SEQUENCE { + kdc-options [0] KDCOptions, + cname [1] PrincipalName OPTIONAL + -- Used only in AS-REQ --, + + realm [2] Realm + -- Server's realm; also client's in AS-REQ --, + + sname [3] PrincipalName OPTIONAL, + from [4] KerberosTime OPTIONAL, + till [5] KerberosTime OPTIONAL + -- was required in rfc1510; + -- still required for compat versions + -- of messages --, + + rtime [6] KerberosTime OPTIONAL, + nonce [7] Nonce, + etype [8] SEQUENCE OF EType + -- in preference order --, + + addresses [9] HostAddresses OPTIONAL, + enc-authorization-data [10] EncryptedData { + AuthorizationData, { key-session | key-subsession }, + { ku-TGSReqAuthData-subkey | + ku-TGSReqAuthData-sesskey } + } OPTIONAL, + + additional-tickets [11] SEQUENCE OF Ticket OPTIONAL + -- NOTE: not empty --, + ... + lang-tags [5] SEQUENCE (SIZE (1..MAX)) OF + LangTag OPTIONAL, + ... + } + + The AS-REQ is: + + AS-REQ ::= CHOICE { + rfc1510 AS-REQ-1510, + ext AS-REQ-EXT + } + AS-REQ-1510 ::= [APPLICATION 10] KDC-REQ-1510 + -- AS-REQ must include client name + + AS-REQ-EXT ::= [APPLICATION 6] Signed { + [APPLICATION 6] KDC-REQ-EXT, { key-client }, { ku-ASReq-cksum } + } + -- AS-REQ must include client name + + A client SHOULD NOT send the extensible AS-REQ alternative to a KDC + if the client does not know that the KDC supports the extensibility + +Yu Expires: Apr 2007 [Page 49] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + framework. A client SHOULD send the extensible AS-REQ alternative in + a PA-AS-REQ PA-DATA. A KDC supporting extensibility will treat the + AS-REQ contained within the PA-AS-REQ as the actual AS-REQ. [ XXX + what if their contents conflict? ] + + The TGS-REQ is: + + TGS-REQ ::= CHOICE { + rfc1510 TGS-REQ-1510, + ext TGS-REQ-EXT + } + + TGS-REQ-1510 ::= [APPLICATION 12] KDC-REQ-1510 + + TGS-REQ-EXT ::= [APPLICATION 8] Signed { + [APPLICATION 8] KDC-REQ-EXT, { key-session }, { ku-TGSReq-cksum } + } + + +8.2. PA-DATA + + PA-DATA have multiple uses in the Kerberos protocol. They may pre- + authenticate an AS-REQ; they may also modify several of the + encryption keys used in a KDC-REP. PA-DATA may also provide "hints" + to the client about which long-term key (usually password-derived) to + use. PA-DATA may also include "hints" about which pre-authentication + mechanisms to use, or include data for input into a pre- + authentication mechanism. + + [ XXX enumerate standard padata here ] + +8.3. KDC-REQ Processing + + Processing of a KDC-REQ proceeds through several steps. An + implementation need not perform these steps exactly as described, as + long as it behaves as if the steps were performed as described. The + KDC performs replay handling upon receiving the request; it then + validates the request, adjusts timestamps, and selects the keys used + in the reply. It copies data from the request into the issued + ticket, adjusting the values to conform with its policies. The KDC + then transmits the reply to the client. + +8.3.1. Handling Replays + + Because Kerberos can run over unreliable transports such as UDP, the + KDC MUST be prepared to retransmit responses in case they are lost. + If a KDC receives a request identical to one it has recently + successfully processed, the KDC MUST respond with a KDC-REP message + rather than a replay error. In order to reduce the amount of + ciphertext given to a potential attacker, KDCs MAY send the same + response generated when the request was first handled. KDCs MUST + +Yu Expires: Apr 2007 [Page 50] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + obey this replay behavior even if the actual transport in use is + reliable. If the AP-REQ which authenticates a TGS-REQ is a replay, + and the entire request is not identical to a recently successfully + processed request, the KDC SHOULD return "krb-ap-err-repeat", as is + appropriate for AP-REQ processing. + +8.3.2. Request Validation + +8.3.2.1. AS-REQ Authentication + + Site policy determines whether a given client principal is required + to provide some pre-authentication prior to receiving an AS-REP. + Since the default reply key is typically the client's long-term + password-based key, an attacker may easily request known plaintext + (in the form of an AS-REP) upon which to mount a dictionary attack. + Pre-authentication can limit the possibility of such an attack. + + If site policy requires pre-authentication for a client principal, + and no pre-authentication is provided, the KDC returns the error + "kdc-err-preauth-required". Accompanying this error are "e-data" + which include hints telling the client which pre-authentication + mechanisms to use, or data for input to pre-authentication mechanisms + (e.g., input to challenge-response systems). If pre-authentication + fails, the KDC returns the error "kdc-err-preauth-failed". + + [ may need additional changes based on Sam's preauth draft ] + +8.3.2.2. TGS-REQ Authentication + + A TGS-REQ has an accompanying AP-REQ, which is included in the "pa- + tgs-req". The KDC MUST validate the checksum in the Authenticator of + the AP-REQ, which is computed over the KDC-REQ-BODY-1510 or KDC-REQ- + BODY-EXT (for TGS-REQ-1510 or TGS-REQ-EXT, respectively) of the + request. [ padata not signed by authenticator! ] Any error from the + AP-REQ validation process SHOULD be returned in a KRB-ERROR message. + The service principal in the ticket of the AP-REQ may be a ticket- + granting service principal, or a normal application service + principal. A ticket which is not a ticket-granting ticket MUST NOT + be used to issue a ticket for any service other than the one named in + the ticket. In this case, the "renew", "validate", or "proxy" [?also + forwarded?] option must be set in the request. + +8.3.2.3. Principal Validation + + If the client principal in an AS-REQ is unknown, the KDC returns the + error "kdc-err-c-principal-unknown". If the server principal in a + KDC-REQ is unknown, the KDC returns the error "kdc-err-s-principal- + unknown". + + + + +Yu Expires: Apr 2007 [Page 51] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + +8.3.2.4. Checking For Revoked or Invalid Tickets + + [ KCLAR 3.3.3.1 ] + + Whenever a request is made to the ticket-granting server, the + presented ticket(s) is(are) checked against a hot-list of tickets + which have been canceled. This hot-list might be implemented by + storing a range of issue timestamps for "suspect tickets"; if a + presented ticket had an authtime in that range, it would be rejected. + In this way, a stolen ticket-granting ticket or renewable ticket + cannot be used to gain additional tickets (renewals or otherwise) + once the theft has been reported to the KDC for the realm in which + the server resides. Any normal ticket obtained before it was + reported stolen will still be valid (because they require no + interaction with the KDC), but only until their normal expiration + time. If TGTs have been issued for cross-realm authentication, use + of the cross-realm TGT will not be affected unless the hot-list is + propagated to the KDCs for the realms for which such cross-realm + tickets were issued. + + If a TGS-REQ ticket has its "invalid" flag set, the KDC MUST NOT + issue any ticket unless the TGS-REQ requests the "validate" option. + +8.3.3. Timestamp Handling + + [ some aspects of timestamp handling, especially regarding postdating + and renewal, are difficult to read in KCLAR... needs closer + examination here ] + + Processing of "starttime" (requested in the "from" field) differs + depending on whether the "postdated" option is set in the request. + If the "postdated" option is not set, and the requested "starttime" + is in the future beyond the window of acceptable clock skew, the KDC + returns the error "kdc-err-cannot-postdate". If the "postdated" + option is not set, and the requested "starttime" is absent or does + not indicate a time in the future beyond the acceptable clock skew, + the KDC sets the "starttime" to the KDC's current time. The + "postdated" option MUST NOT be honored if the ticket is being + requested by TGS-REQ and the "may-postdate" is not set in the TGT. + Otherwise, if the "postdated" option is set, and site policy permits, + the KDC sets the "starttime" as requested, and sets the "invalid" + flag in the new ticket. + + The "till" field is required in the RFC 1510 version of the KDC-REQ. + If the "till" field is equal to "19700101000000Z" (midnight, January + 1, 1970), the KDC SHOULD behave as if the "till" field were absent. + + The KDC MUST NOT issue a ticket whose "starttime", "endtime", or + "renew-till" time is later than the "renew-till" time of the ticket + from which it is derived. + + +Yu Expires: Apr 2007 [Page 52] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + +8.3.3.1. AS-REQ Timestamp Processing + + In the AS exchange, the "authtime" of a ticket is set to the local + time at the KDC. + + The "endtime" of the ticket will be set to the earlier of the + requested "till" time and a time determined by local policy, possibly + determined using factors specific to the realm or principal. For + example, the expiration time MAY be set to the earliest of the + following: + + * the expiration time ("till" value) requested + + * the ticket's start time plus the maximum allowable lifetime + associated with the client principal from the authentication + server's database + + * the ticket's start time plus the maximum allowable lifetime + associated with the server principal + + * the ticket's start time plus the maximum lifetime set by the + policy of the local realm + + If the requested expiration time minus the start time (as determined + above) is less than a site-determined minimum lifetime, an error + message with code "kdc-err-never-valid" is returned. If the + requested expiration time for the ticket exceeds what was determined + as above, and if the "renewable-ok" option was requested, then the + "renewable" flag is set in the new ticket, and the "renew-till" value + is set as if the "renewable" option were requested. + + If the "renewable" option has been requested or if the "renewable-ok" + option has been set and a renewable ticket is to be issued, then the + "renew-till" field MAY be set to the earliest of: + + * its requested value + + * the start time of the ticket plus the minimum of the two maximum + renewable lifetimes associated with the principals' database + entries + + * the start time of the ticket plus the maximum renewable lifetime + set by the policy of the local realm + +8.3.3.2. TGS-REQ Timestamp Processing + + In the TGS exchange, the KDC sets the "authtime" to that of the + ticket in the AP-REQ authenticating the TGS-REQ. [?application + server can print a ticket for itself with a spoofed authtime. + security issues for hot-list?] [ MIT implementation may change + authtime of renewed tickets; needs check... ] + +Yu Expires: Apr 2007 [Page 53] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + If the TGS-REQ has a TGT as the ticket in its AP-REQ, and the TGS-REQ + requests an "endtime" (in the "till" field), then the "endtime" of + the new ticket is set to the minimum of + + * the requested "endtime" value, + + * the "endtime" in the TGT, and + + * an "endtime" determined by site policy on ticket lifetimes. + + If the new ticket is a renewal, the "endtime" of the new ticket is + bounded by the minimum of + + * the requested "endtime" value, + + * the value of the "renew-till" value of the old, + + * the "starttime" of the new ticket plus the lifetime (endtime + minus starttime) of the old ticket, i.e., the lifetime of the + new ticket may not exceed that of the ticket being renewed [ + adapted from KCLAR 3.3.3. ], and + + * an "endtime" determined by site policy on ticket lifetimes. + + When handling a TGS-REQ, a KDC MUST NOT issue a postdated ticket with + a "starttime", "endtime", or "renew-till" time later than the + "renew-till" time of the TGT. + +8.3.4. Handling Transited Realms + + The KDC checks the ticket in a TGS-REQ against site policy, unless + the "disable-transited-check" option is set in the TGS-REQ. If site + policy permits the transit path in the TGS-REQ ticket, the KDC sets + the "transited-policy-checked" flag in the issued ticket. If the + "disable-transited-check" option is set, the issued ticket will have + the "transited-policy-checked" flag cleared. + +8.3.5. Address Processing The requested "addresses" in the KDC-REQ are + copied into the issued ticket. If the "addresses" field is absent or + empty in a TGS-REQ, the KDC copies addresses from the ticket in the + TGS-REQ into the issued ticket, unless the either "forwarded" or + "proxy" option is set. If the "forwarded" option is set, and the + ticket in the TGS-REQ has its "forwardable" flag set, the KDC copies + the addresses from the TGS-REQ, not the from TGS-REQ ticket, into the + issued ticket. The KDC behaves similarly if the "proxy" option is + set in the TGS-REQ and the "proxiable" flag is set in the ticket. + The "proxy" option will not be honored on requests for additional + ticket-granting tickets. + + + + +Yu Expires: Apr 2007 [Page 54] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + +8.3.6. Ticket Flag Processing + + Many kdc-options request that the KDC set a corresponding flag in the + issued ticket. kdc-options marked with an asterisk (*) in the + following table do not directly request the corresponding ticket flag + and therefore require special handling. + + + kdc-option | ticket flag affected + ________________________|__________________________ + forwardable | forwardable + forwarded | forwarded + proxiable | proxiable + proxy | proxy + allow-postdate | may-postdate + postdated | postdated + renewable | renewable + requestanonymous | anonymous + canonicalize | - + disable-transited-check*| transited-policy-checked + renewable-ok* | renewable + enc-tkt-in-skey | - + renew | - + validate* | invalid + + + + forwarded + The KDC sets the "forwarded" flag in the issued ticket if the + "forwarded" option is set in the TGS-REQ and the "forwardable" + flag is set in the TGS-REQ ticket. + + proxy + The KDC sets the "proxy" flag in the issued ticket if the + "proxy" option is set in the TGS-REQ and the "proxiable" flag is + set in the TGS-REQ ticket. + + disable-transited-check + The handling of the "disable-transited-check" kdc-option is + described in Section 8.3.4. + + renewable-ok + The handling of the "renewable-ok" kdc-option is described in + Section 8.3.3.1. + + enc-tkt-in-skey + This flag modifies ticket key selection to use the session key + of an additional ticket included in the TGS-REQ, for the purpose + of user-to-user authentication. + + + +Yu Expires: Apr 2007 [Page 55] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + validate + If the "validate" kdc-option is set in a TGS-REQ, and the + "starttime" has passed, the KDC will clear the "invalid" bit on + the ticket before re-issuing it. + +8.3.7. Key Selection + + Three keys are involved in creating a KDC-REP. The reply key + encrypts the encrypted part of the KDC-REP. The session key is + stored in the encrypted part of the ticket, and is also present in + the encrypted part of the KDC-REP so that the client can retrieve it. + The ticket key is used to encrypt the ticket. These keys all have + initial values for a given exchange; pre-authentication and other + extension mechanisms may change the value used for any of these keys. + + [ again, may need changes based on Sam's preauth draft ] + +8.3.7.1. Reply Key and Session Key Selection + + The set of encryption types which the client will understand appears + in the "etype" field of KDC-REQ-BODY. The KDC limits the set of + possible reply keys and the set of session key encryption types based + on the "etype" field. + + For the AS exchange, the reply key is initially a long-term key of + the client, limited to those encryption types listed in the "etype" + field. The KDC SHOULD use the first valid strong "etype" for which + an encryption key is available. For the TGS exchange, the reply key + is initially the subsession key of the Authenticator. If the + Authenticator subsesion key is absent, the reply key is initially the + session key of the ticket used to authenticate the TGS-REQ. + + The session key is initially randomly generated, and has an + encryption type which both the client and the server will understand. + Typically, the KDC has prior knowledge of which encryption types the + server will understand. It selects the first valid strong "etype" + listed the request which the server also will understand. + +8.3.7.2. Ticket Key Selection + + The ticket key is initially the long-term key of the service. The + "enc-tkt-in-skey" option requests user-to-user authentication, where + the ticket encryption key of the issued ticket is set equal to the + session key of the additional ticket in the request. + +8.4. KDC-REP + + The important parts of the KDC-REP are encrypted. + + + + +Yu Expires: Apr 2007 [Page 56] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + EncASRepPart1510 ::= [APPLICATION 25] EncKDCRepPart1510 + EncTGSRepPart1510 ::= [APPLICATION 26] EncKDCRepPart1510 + + EncASRepPartExt ::= [APPLICATION 32] EncKDCRepPartExt + EncTGSRepPartExt ::= [APPLICATION 33] EncKDCRepPartExt + + EncKDCRepPart1510 ::= SEQUENCE { + key [0] EncryptionKey, + last-req [1] LastReq, + nonce [2] Nonce32, + key-expiration [3] KerberosTime OPTIONAL, + flags [4] TicketFlags, + authtime [5] KerberosTime, + starttime [6] KerberosTime OPTIONAL, + endtime [7] KerberosTime, + renew-till [8] KerberosTime OPTIONAL, + srealm [9] RealmIA5, + sname [10] PrincipalNameIA5, + caddr [11] HostAddresses OPTIONAL + } + + EncKDCRepPartExt ::= SEQUENCE { + key [0] EncryptionKey, + last-req [1] LastReq, + nonce [2] Nonce, + key-expiration [3] KerberosTime OPTIONAL, + flags [4] TicketFlags, + authtime [5] KerberosTime, + starttime [6] KerberosTime OPTIONAL, + endtime [7] KerberosTime, + renew-till [8] KerberosTime OPTIONAL, + srealm [9] Realm, + sname [10] PrincipalName, + caddr [11] HostAddresses OPTIONAL, + ... + } + + + Most of the fields of EncKDCRepPartCom are duplicates of the + corresponding fields in the returned ticket. + + + + + + + + + + + + +Yu Expires: Apr 2007 [Page 57] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + KDC-REP-1510 { EncPart } ::= SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (11 -- AS-REP.rfc1510 -- | + 13 -- TGS.rfc1510 -- ), + padata [2] SEQUENCE OF PA-DATA OPTIONAL, + crealm [3] RealmIA5, + cname [4] PrincipalNameIA5, + ticket [5] Ticket, + + enc-part [6] EncryptedData { + EncPart, + { key-reply }, + -- maybe reach into EncryptedData in AS-REP/TGS-REP + -- definitions to apply constraints on key usages? + { ku-EncASRepPart -- if AS-REP -- | + ku-EncTGSRepPart-subkey -- if TGS-REP and + -- using Authenticator + -- session key -- | + ku-EncTGSRepPart-sesskey -- if TGS-REP and using + -- subsession key -- } + } + } + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Yu Expires: Apr 2007 [Page 58] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + KDC-REP-EXT { EncPart } ::= SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (7 -- AS-REP.ext -- | + 9 -- TGS-REP.ext -- ), + padata [2] SEQUENCE OF PA-DATA OPTIONAL, + crealm [3] RealmExt, + cname [4] PrincipalNameExt, + ticket [5] Ticket, + + enc-part [6] EncryptedData { + EncPart, + { key-reply }, + -- maybe reach into EncryptedData in AS-REP/TGS-REP + -- definitions to apply constraints on key usages? + { ku-EncASRepPart -- if AS-REP -- | + ku-EncTGSRepPart-subkey -- if TGS-REP and + -- using Authenticator + -- session key -- | + ku-EncTGSRepPart-sesskey -- if TGS-REP and using + -- subsession key -- } + }, + + ..., + -- In extensible version, KDC signs original request + -- to avoid replay attacks against client. + req-cksum [7] ChecksumOf { CHOICE { + as-req AS-REQ, + tgs-req TGS-REQ + }, { key-reply }, { ku-KDCRep-cksum }} OPTIONAL, + lang-tag [8] LangTag OPTIONAL, + ... + } + + + req-cksum + Signature of the original request using the reply key, to avoid + replay attacks against the client, among other things. Only + present in the extensible version of KDC-REP. + + AS-REP ::= CHOICE { + rfc1510 AS-REP-1510, + ext AS-REP-EXT + } + AS-REP-1510 ::= [APPLICATION 11] KDC-REP-1510 + AS-REP-EXT ::= [APPLICATION 7] Signed { + [APPLICATION 7] KDC-REP-EXT, + { key-reply }, { ku-ASRep-cksum } + } + + + + +Yu Expires: Apr 2007 [Page 59] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + TGS-REP ::= CHOICE { + rfc1510 TGS-REP-1510, + ext TGS-REP-EXT + } + TGS-REP-1510 ::= [APPLICATION 13] KDC-REP-1510 { EncTGSRepPart1510 } + TGS-REP-EXT ::= [APPLICATION 9] Signed { + [APPLICATION 9] KDC-REP-EXT { EncTGSRepPartExt }, + { key-reply }, { ku-TGSRep-cksum } + } + + + The extensible versions of AS-REQ and TGS-REQ are signed with the + reply key, to prevent an attacker from performing a delayed denial- + of-service attack by substituting the ticket. + +8.5. Reply Validation + + [ signature verification ] + +8.6. IP Transports + + [ KCLAR 7.2 ] + + Kerberos defines two IP transport mechanisms for the credentials + acquisition protocol: UDP/IP and TCP/IP. + +8.6.1. UDP/IP transport + + Kerberos servers (KDCs) supporting IP transports MUST accept UDP + requests and SHOULD listen for such requests on port 88 (decimal) + unless specifically configured to listen on an alternative UDP port. + Alternate ports MAY be used when running multiple KDCs for multiple + realms on the same host. + + Kerberos clients supporting IP transports SHOULD support the sending + of UDP requests. Clients SHOULD use KDC discovery (Section 8.6.3) to + identify the IP address and port to which they will send their + request. + + When contacting a KDC for a KRB_KDC_REQ request using UDP/IP + transport, the client shall send a UDP datagram containing only an + encoding of the request to the KDC. The KDC will respond with a reply + datagram containing only an encoding of the reply message (either a + KRB-ERROR or a KDC-REP) to the sending port at the sender's IP + address. The response to a request made through UDP/IP transport MUST + also use UDP/IP transport. If the response can not be handled using + UDP (for example because it is too large), the KDC MUST return "krb- + err-response-too-big", forcing the client to retry the request using + the TCP transport. + + + +Yu Expires: Apr 2007 [Page 60] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + +8.6.2. TCP/IP transport + + Kerberos servers (KDCs) supporting IP transports MUST accept TCP + requests and SHOULD listen for such requests on port 88 (decimal) + unless specifically configured to listen on an alternate TCP port. + Alternate ports MAY be used when running multiple KDCs for multiple + realms on the same host. + + Clients MUST support the sending of TCP requests, but MAY choose to + initially try a request using the UDP transport. Clients SHOULD use + KDC discovery (Section 8.6.3) to identify the IP address and port to + which they will send their request. + + Implementation note: Some extensions to the Kerberos protocol will + not succeed if any client or KDC not supporting the TCP transport is + involved. Implementations of RFC 1510 were not required to support + TCP/IP transports. + + When the KDC-REQ message is sent to the KDC over a TCP stream, the + response (KDC-REP or KRB-ERROR message) MUST be returned to the + client on the same TCP stream that was established for the request. + The KDC MAY close the TCP stream after sending a response, but MAY + leave the stream open for a reasonable period of time if it expects a + followup. Care must be taken in managing TCP/IP connections on the + KDC to prevent denial of service attacks based on the number of open + TCP/IP connections. + + The client MUST be prepared to have the stream closed by the KDC at + anytime after the receipt of a response. A stream closure SHOULD NOT + be treated as a fatal error. Instead, if multiple exchanges are + required (e.g., certain forms of pre-authentication) the client may + need to establish a new connection when it is ready to send + subsequent messages. A client MAY close the stream after receiving a + response, and SHOULD close the stream if it does not expect to send + followup messages. + + A client MAY send multiple requests before receiving responses, + though it must be prepared to handle the connection being closed + after the first response. + + Each request (KDC-REQ) and response (KDC-REP or KRB-ERROR) sent over + the TCP stream is preceded by the length of the request as 4 octets + in network byte order. The high bit of the length is reserved for + future expansion and MUST currently be set to zero. If a KDC that + does not understand how to interpret a set high bit of the length + encoding receives a request with the high order bit of the length + set, it MUST return a KRB-ERROR message with the error "krb-err- + field-toolong" and MUST close the TCP stream. + + If multiple requests are sent over a single TCP connection, and the + KDC sends multiple responses, the KDC is not required to send the + +Yu Expires: Apr 2007 [Page 61] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + responses in the order of the corresponding requests. This may + permit some implementations to send each response as soon as it is + ready even if earlier requests are still being processed (for + example, waiting for a response from an external device or database). + +8.6.3. KDC Discovery on IP Networks + + Kerberos client implementations MUST provide a means for the client + to determine the location of the Kerberos Key Distribution Centers + (KDCs). Traditionally, Kerberos implementations have stored such + configuration information in a file on each client machine. + Experience has shown this method of storing configuration information + presents problems with out-of-date information and scaling problems, + especially when using cross-realm authentication. This section + describes a method for using the Domain Name System [RFC 1035] for + storing KDC location information. + +8.6.3.1. DNS vs. Kerberos - Case Sensitivity of Realm Names + + In Kerberos, realm names are case sensitive. While it is strongly + encouraged that all realm names be all upper case this recommendation + has not been adopted by all sites. Some sites use all lower case + names and other use mixed case. DNS, on the other hand, is case + insensitive for queries. Since the realm names "MYREALM", "myrealm", + and "MyRealm" are all different, but resolve the same in the domain + name system, it is necessary that only one of the possible + combinations of upper and lower case characters be used in realm + names. + +8.6.3.2. DNS SRV records for KDC location + + KDC location information is to be stored using the DNS SRV RR [RFC + 2782]. The format of this RR is as follows: + + _Service._Proto.Realm TTL Class SRV Priority Weight Port Target + + The Service name for Kerberos is always "kerberos". + + The Proto can be one of "udp", "tcp". If these SRV records are to be + used, both "udp" and "tcp" records MUST be specified for all KDC + deployments. + + The Realm is the Kerberos realm that this record corresponds to. The + realm MUST be a domain style realm name. + + TTL, Class, SRV, Priority, Weight, and Target have the standard + meaning as defined in RFC 2782. + + As per RFC 2782 the Port number used for "_udp" and "_tcp" SRV + records SHOULD be the value assigned to "kerberos" by the Internet + Assigned Number Authority: 88 (decimal) unless the KDC is configured + +Yu Expires: Apr 2007 [Page 62] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + to listen on an alternate TCP port. + + Implementation note: Many existing client implementations do not + support KDC Discovery and are configured to send requests to the IANA + assigned port (88 decimal), so it is strongly recommended that KDCs + be configured to listen on that port. + +8.6.3.3. KDC Discovery for Domain Style Realm Names on IP Networks + + These are DNS records for a Kerberos realm EXAMPLE.COM. It has two + Kerberos servers, kdc1.example.com and kdc2.example.com. Queries + should be directed to kdc1.example.com first as per the specified + priority. Weights are not used in these sample records. + + _kerberos._udp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com. + _kerberos._udp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com. + _kerberos._tcp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com. + _kerberos._tcp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com. + + +9. Errors + + The KRB-ERROR message is returned by the KDC if an error occurs + during credentials acquisition. It may also be returned by an + application server if an error occurs during authentication. + + ErrCode ::= Int32 + + KRB-ERROR ::= CHOICE { + rfc1510 KRB-ERROR-1510, + ext KRB-ERROR-EXT + } + + + The extensible KRB-ERROR is only signed if there has been a key + negotiated with its recipient. KRB-ERROR messages sent in response + to AS-REQ messages will probably not be signed unless a + preauthentication mechanism has negotiated a key. (Signing using a + client's long-term key can expose ciphertext to dictionary attacks.) + + + + + + + + + + + + + +Yu Expires: Apr 2007 [Page 63] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + KRB-ERROR-1510 ::= [APPLICATION 30] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (30), + ctime [2] KerberosTime OPTIONAL, + cusec [3] Microseconds OPTIONAL, + stime [4] KerberosTime, + susec [5] Microseconds, + error-code [6] ErrCode, + crealm [7] RealmIA5 OPTIONAL, + cname [8] PrincipalNameIA5 OPTIONAL, + realm [9] RealmIA5 -- Correct realm --, + sname [10] PrincipalNameIA5 -- Correct name --, + e-text [11] KerberosString OPTIONAL, + e-data [12] OCTET STRING OPTIONAL + } + + + KRB-ERROR-EXT ::= [APPLICATION 23] Signed { + [APPLICATION 23] SEQUENCE{ + pvno [0] INTEGER (5), + msg-type [1] INTEGER (23), + ctime [2] KerberosTime OPTIONAL, + cusec [3] Microseconds OPTIONAL, + stime [4] KerberosTime, + susec [5] Microseconds, + error-code [6] ErrCode, + crealm [7] Realm OPTIONAL, + cname [8] PrincipalName OPTIONAL, + realm [9] Realm -- Correct realm --, + sname [10] PrincipalName -- Correct name --, + e-text [11] KerberosString OPTIONAL, + e-data [12] OCTET STRING OPTIONAL, + ..., + typed-data [13] TYPED-DATA OPTIONAL, + nonce [14] Nonce OPTIONAL, + lang-tag [15] LangTag OPTIONAL, + ... + }, { }, { ku-KrbError-cksum } + } + + + ctime, cusec + Client's time, if known from a KDC-REQ or AP-REQ. + + stime, susec + KDC or application server's current time. + + error-code + Numeric error code designating the error. + + + +Yu Expires: Apr 2007 [Page 64] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + crealm, cname + Client's realm and name, if known. + + realm, sname + server's realm and name. [ XXX what if these aren't known? ] + + e-text + Human-readable text providing additional details for the error. + + e-data + This field contains additional data about the error for use by + the client to help it recover from or handle the error. If the + "error-code" is "kdc-err-preauth-required", then the e-data + field will contain an encoding of a sequence of padata fields, + each corresponding to an acceptable pre-authentication method + and optionally containing data for the method: + + METHOD-DATA ::= SEQUENCE OF PA-DATA + + + For error codes defined in this document other than "kdc-err- + preauth-required", the format and contents of the e-data field + are implementation-defined. Similarly, for future error codes, + the format and contents of the e-data field are implementation- + defined unless specified. + + lang-tag + Indicates the language of the message in the "e-text" field. It + is only present in the extensible KRB-ERROR. + + nonce + is the nonce from a KDC-REQ. It is only present in the + extensible KRB-ERROR. + + typed-data + TYPED-DATA is a typed hole allowing for additional data to be + returned in error conditions, since "e-data" is insufficiently + flexible for some purposes. TYPED-DATA is only present in the + extensible KRB-ERROR. + + TDType ::= TH-id + + TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { + data-type [0] TDType, + data-value [1] OCTET STRING OPTIONAL + } + + + + + + +Yu Expires: Apr 2007 [Page 65] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + +10. Session Key Exchange + + Session key exchange consists of the AP-REQ and AP-REP messages. The + client sends the AP-REQ message, and the service responds with an + AP-REP message if mutual authentication is desired. Following + session key exchange, the client and service share a secret session + key, or possibly a subsesion key, which can be used to protect + further communications. Additionally, the session key exchange + process can establish initial sequence numbers which the client and + service can use to detect replayed messages. + +10.1. AP-REQ + + An AP-REQ message contains a ticket and a authenticator. The + authenticator is ciphertext encrypted with the session key contained + in the ticket. The plaintext contents of the authenticator are: + + -- plaintext of authenticator + Authenticator1510 ::= [APPLICATION 2] SEQUENCE { + authenticator-vno [0] INTEGER (5), + crealm [1] RealmIA5, + cname [2] PrincipalNameIA5, + cksum [3] Checksum {{ key-session }, + { ku-Authenticator-cksum | + ku-pa-TGSReq-cksum }} OPTIONAL, + cusec [4] Microseconds, + ctime [5] KerberosTime, + subkey [6] EncryptionKey OPTIONAL, + seq-number [7] SeqNum32 OPTIONAL, + authorization-data [8] AuthorizationData OPTIONAL + } + + AuthenticatorExt ::= [APPLICATION 35] SEQUENCE { + authenticator-vno [0] INTEGER (5), + crealm [1] RealmExt, + cname [2] PrincipalNameExt, + cksum [3] Checksum {{ key-session }, + { ku-Authenticator-cksum | + ku-pa-TGSReq-cksum }} OPTIONAL, + cusec [4] Microseconds, + ctime [5] KerberosTime, + subkey [6] EncryptionKey OPTIONAL, + seq-number [7] SeqNum OPTIONAL, + authorization-data [8] AuthorizationData OPTIONAL, + ... + } + + The complete definition of AP-REQ is: + + + + +Yu Expires: Apr 2007 [Page 66] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + AP-REQ ::= CHOICE { + rfc1510 AP-REQ-1510, + ext AP-REQ-EXT + } + + + AP-REQ-1510 ::= [APPLICATION 14] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (14), + ap-options [2] APOptions, + ticket [3] Ticket1510, + authenticator [4] EncryptedData { + Authenticator1510, + { key-session }, + { ku-APReq-authenticator | + ku-pa-TGSReq-authenticator } + } + } + + + AP-REQ-EXT ::= [APPLICATION 18] Signed { + [APPLICATION 18] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (18), + ap-options [2] APOptions, + ticket [3] Ticket, + authenticator [4] EncryptedData { + AuthenticatorExt, + { key-session }, + { ku-APReq-authenticator | + ku-pa-TGSReq-authenticator } + }, + ..., + extensions [5] ApReqExtensions OPTIONAL, + lang-tag [6] SEQUENCE (SIZE (1..MAX)) + OF LangTag OPTIONAL, + ... + }, { key-session }, { ku-APReq-cksum } + } + + + APOptions ::= KerberosFlags { APOptionsBits } + + APOptionsBits ::= BIT STRING { + reserved (0), + use-session-key (1), + mutual-required (2) + } + + + + +Yu Expires: Apr 2007 [Page 67] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + +10.2. AP-REP + + An AP-REP message provides mutual authentication of the service to + the client. + + EncAPRepPart ::= CHOICE { + rfc1510 EncAPRepPart1510, + ext EncAPRepPartExt + } + + + EncAPRepPart1510 ::= [APPLICATION 27] SEQUENCE { + ctime [0] KerberosTime, + cusec [1] Microseconds, + subkey [2] EncryptionKey OPTIONAL, + seq-number [3] SeqNum32 OPTIONAL + } + + + EncAPRepPartExt ::= [APPLICATION 31] SEQUENCE { + ctime [0] KerberosTime, + cusec [1] Microseconds, + subkey [2] EncryptionKey OPTIONAL, + seq-number [3] SeqNum OPTIONAL, + ..., + authorization-data [4] AuthorizationData OPTIONAL, + ... + } + + + AP-REP ::= CHOICE { + rfc1510 AP-REP-1510, + ext AP-REP-EXT + } + + + AP-REP-1510 ::= [APPLICATION 15] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (15), + enc-part [2] EncryptedData { + EncApRepPart1510, + { key-session | key-subsession }, { ku-EncAPRepPart }} + } + + + + + + + + + +Yu Expires: Apr 2007 [Page 68] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + AP-REP-EXT ::= [APPLICATION 19] Signed { + [APPLICATION 19] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (19), + enc-part [2] EncryptedData { + EncAPRepPartExt, + { key-session | key-subsession }, { ku-EncAPRepPart }}, + ..., + extensions [3] ApRepExtensions OPTIONAL, + ... + }, { key-session | key-subsession }, { ku-APRep-cksum } + } + + +11. Session Key Use + + Once a session key has been established, the client and server can + use several kinds of messages to securely transmit data. KRB-SAFE + provides integrity protection for application data, while KRB-PRIV + provides confidentiality along with integrity protection. The KRB- + CRED message provides a means of securely forwarding credentials from + the client host to the server host. + +11.1. KRB-SAFE + + The KRB-SAFE message provides integrity protection for an included + cleartext message. + + KRB-SAFE ::= CHOICE { + rfc1510 KRB-SAFE-1510, + ext KRB-SAFE-EXT + } + + + KRB-SAFE-BODY ::= SEQUENCE { + user-data [0] OCTET STRING, + timestamp [1] KerberosTime OPTIONAL, + usec [2] Microseconds OPTIONAL, + seq-number [3] SeqNum OPTIONAL, + s-address [4] HostAddress, + r-address [5] HostAddress OPTIONAL, + ... -- ASN.1 extensions must be excluded + -- when sending to rfc1510 implementations + } + + +11.2. KRB-PRIV + + The KRB-PRIV message provides confidentiality and integrity + protection. + + +Yu Expires: Apr 2007 [Page 69] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + KRB-PRIV ::= [APPLICATION 21] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (21), + enc-part [3] EncryptedData { + EncKrbPrivPart, + { key-session | key-subsession }, { ku-EncKrbPrivPart }}, + ... + } + + + EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { + user-data [0] OCTET STRING, + timestamp [1] KerberosTime OPTIONAL, + usec [2] Microseconds OPTIONAL, + seq-number [3] SeqNum OPTIONAL, + s-address [4] HostAddress -- sender's addr --, + r-address [5] HostAddress OPTIONAL -- recip's addr --, + ... -- ASN.1 extensions must be excluded + -- when sending to rfc1510 implementations + } + + +11.3. KRB-CRED + + The KRB-CRED message provides a means of securely transferring + credentials from the client to the service. + + KRB-CRED ::= CHOICE { + rfc1510 KRB-CRED-1510, + ext KRB-CRED-EXT + + } + + + KRB-CRED-1510 ::= [APPLICATION 22] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (22), + tickets [2] SEQUENCE OF Ticket, + enc-part [3] EncryptedData { + EncKrbCredPart, + { key-session | key-subsession }, { ku-EncKrbCredPart }} + } + + + + + + + + + + +Yu Expires: Apr 2007 [Page 70] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + KRB-CRED-EXT ::= [APPLICATION 24] Signed { + [APPLICATION 24] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (24), + tickets [2] SEQUENCE OF Ticket, + enc-part [3] EncryptedData { + EncKrbCredPart, + { key-session | key-subsession }, { ku-EncKrbCredPart }}, + ... + }, { key-session | key-subsession }, { ku-KrbCred-cksum } + } + + + + EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { + ticket-info [0] SEQUENCE OF KrbCredInfo, + nonce [1] Nonce OPTIONAL, + timestamp [2] KerberosTime OPTIONAL, + usec [3] Microseconds OPTIONAL, + s-address [4] HostAddress OPTIONAL, + r-address [5] HostAddress OPTIONAL + } + + + KrbCredInfo ::= SEQUENCE { + key [0] EncryptionKey, + prealm [1] Realm OPTIONAL, + pname [2] PrincipalName OPTIONAL, + flags [3] TicketFlags OPTIONAL, + authtime [4] KerberosTime OPTIONAL, + starttime [5] KerberosTime OPTIONAL, + endtime [6] KerberosTime OPTIONAL, + renew-till [7] KerberosTime OPTIONAL, + srealm [8] Realm OPTIONAL, + sname [9] PrincipalName OPTIONAL, + caddr [10] HostAddresses OPTIONAL + } + + +12. Security Considerations + +12.1. Time Synchronization + + Time synchronization between the KDC and application servers is + necessary to prevent acceptance of expired tickets. + + Time synchronization is needed between application servers and + clients to prevent replay attacks if a replay cache is being used. + If negotiated subsession keys are used to encrypt application data, + replay caches may not be necessary. + + +Yu Expires: Apr 2007 [Page 71] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + +12.2. Replays + +12.3. Principal Name Reuse + + See Section 5.3. + +12.4. Password Guessing + +12.5. Forward Secrecy + + [from KCLAR 10.; needs some rewriting] + + The Kerberos protocol in its basic form does not provide perfect + forward secrecy for communications. If traffic has been recorded by + an eavesdropper, then messages encrypted using the KRB-PRIV message, + or messages encrypted using application-specific encryption under + keys exchanged using Kerberos can be decrypted if any of the user's, + application server's, or KDC's key is subsequently discovered. This + is because the session key used to encrypt such messages is + transmitted over the network encrypted in the key of the application + server, and also encrypted under the session key from the user's + ticket-granting ticket when returned to the user in the TGS-REP + message. The session key from the ticket-granting ticket was sent to + the user in the AS-REP message encrypted in the user's secret key, + and embedded in the ticket-granting ticket, which was encrypted in + the key of the KDC. Application requiring perfect forward secrecy + must exchange keys through mechanisms that provide such assurance, + but may use Kerberos for authentication of the encrypted channel + established through such other means. + +12.6. Authorization + + As an authentication service, Kerberos provides a means of verifying + the identity of principals on a network. Kerberos does not, by + itself, provide authorization. Applications SHOULD NOT accept the + mere issuance of a service ticket by the Kerberos server as granting + authority to use the service. + +12.7. Login Authentication + + Some applications, particularly those which provide login access when + provided with a password, SHOULD NOT treat successful acquisition of + credentials as sufficient proof of the user's identity. An attacker + posing as a user could generate an illegitimate KDC-REP message which + decrypts properly. To authenticate a user logging on to a local + system, the credentials obtained SHOULD be used in a TGS exchange to + obtain credentials for a local service. Successful use of those + credentials to authenticate to the local service assures that the + initially obtained credentials are from a valid KDC. + + + +Yu Expires: Apr 2007 [Page 72] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + +13. IANA Considerations + + [ needs more work ] + + Each use of Int32 in this document defines a number space. [ XXX + enumerate these ] Negative numbers are reserved for private use; + local and experimental extensions should use these values. Zero is + reserved and may not be assigned. + + Typed hole contents may be identified by either Int32 values or by + RELATIVE-OID values. Since RELATIVE-OIDs define a hierarchical + namespace, assignments to the top level of the RELATIVE-OID space may + be made on a first-come, first-served basis. + +14. Acknowledgments + + Much of the text here is adapted from draft-ietf-krb-wg-kerberos- + clarifications-07. The description of the general form of the + extensibility framework was derived from text by Sam Hartman. Some + text concerning internationalization of internationalized domain + names in principal names and realm names was contributed by Jeffrey + Altman and Jeffrey Hutzelman. + +Appendices + +A. ASN.1 Module (Normative) + + KerberosV5Spec3 { + iso(1) identified-organization(3) dod(6) internet(1) + security(5) kerberosV5(2) modules(4) krb5spec3(4) + } DEFINITIONS EXPLICIT TAGS ::= BEGIN + + + -- OID arc for KerberosV5 + -- + -- This OID may be used to identify Kerberos protocol messages + -- encapsulated in other protocols. + -- + -- This OID also designates the OID arc for KerberosV5-related + -- OIDs. + -- + -- NOTE: RFC 1510 had an incorrect value (5) for "dod" in its + -- OID. + id-krb5 OBJECT IDENTIFIER ::= { + iso(1) identified-organization(3) dod(6) internet(1) + security(5) kerberosV5(2) + } + + + + + +Yu Expires: Apr 2007 [Page 73] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + -- top-level type + -- + -- Applications should not directly reference any types + -- other than KRB-PDU and its component types. + -- + KRB-PDU ::= CHOICE { + ticket Ticket, + as-req AS-REQ, + as-rep AS-REP, + tgs-req TGS-REQ, + tgs-rep TGS-REP, + ap-req AP-REQ, + ap-rep AP-REP, + krb-safe KRB-SAFE, + krb-priv KRB-PRIV, + krb-cred KRB-CRED, + tgt-req TGT-REQ, + krb-error KRB-ERROR, + ... + } + + + -- + -- *** basic types + -- + + + -- signed values representable in 32 bits + -- + -- These are often used as assigned numbers for various things. + Int32 ::= INTEGER (-2147483648..2147483647) + + + -- Typed hole identifiers + TH-id ::= CHOICE { + int32 Int32, + rel-oid RELATIVE-OID + } + + + -- unsigned 32 bit values + UInt32 ::= INTEGER (0..4294967295) + + + -- unsigned 64 bit values + UInt64 ::= INTEGER (0..18446744073709551615) + + + -- sequence numbers + SeqNum ::= UInt64 + + +Yu Expires: Apr 2007 [Page 74] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + -- nonces + Nonce ::= UInt64 + + + -- microseconds + Microseconds ::= INTEGER (0..999999) + + + KerberosTime ::= GeneralizedTime (CONSTRAINED BY { + -- MUST NOT include fractional seconds + }) + + + -- used for names and for error messages + KerberosString ::= CHOICE { + ia5 GeneralString (IA5String), + utf8 UTF8String, + ... -- no extension may be sent + -- to an rfc1510 implementation -- + } + + + -- IA5 choice only; useful for constraints + KerberosStringIA5 ::= KerberosString + (WITH COMPONENTS { ia5 PRESENT }) + + -- IA5 excluded; useful for constraints + KerberosStringExt ::= KerberosString + (WITH COMPONENTS { ia5 ABSENT }) + + + -- used for language tags + LangTag ::= PrintableString + (FROM ("A".."Z" | "a".."z" | "0".."9" | "-")) + + + + + + + + + + + + + + + + + + +Yu Expires: Apr 2007 [Page 75] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + -- assigned numbers for name types (used in principal names) + NameType ::= Int32 + + -- Name type not known + nt-unknown NameType ::= 0 + -- Just the name of the principal as in DCE, or for users + nt-principal NameType ::= 1 + -- Service and other unique instance (krbtgt) + nt-srv-inst NameType ::= 2 + -- Service with host name as instance (telnet, rcommands) + nt-srv-hst NameType ::= 3 + -- Service with host as remaining components + nt-srv-xhst NameType ::= 4 + -- Unique ID + nt-uid NameType ::= 5 + -- Encoded X.509 Distingished name [RFC 2253] + nt-x500-principal NameType ::= 6 + -- Name in form of SMTP email name (e.g. user@foo.com) + nt-smtp-name NameType ::= 7 + -- Enterprise name - may be mapped to principal name + nt-enterprise NameType ::= 10 + + + PrincipalName { StrType } ::= SEQUENCE { + name-type [0] NameType, + -- May have zero elements, or individual elements may be + -- zero-length, but this is NOT RECOMMENDED. + name-string [1] SEQUENCE OF KerberosString (StrType) + } + + + -- IA5 only + PrincipalNameIA5 ::= PrincipalName { KerberosStringIA5 } + -- IA5 excluded + PrincipalNameExt ::= PrincipalName { KerberosStringExt } + -- Either one? + PrincipalNameEither ::= PrincipalName { KerberosString } + + + Realm { StrType } ::= KerberosString (StrType) + + -- IA5 only + RealmIA5 ::= Realm { KerberosStringIA5 } + + -- IA5 excluded + RealmExt ::= Realm { KerberosStringExt } + + -- Either + RealmEither ::= Realm { KerberosString } + + + +Yu Expires: Apr 2007 [Page 76] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + KerberosFlags { NamedBits } ::= BIT STRING (SIZE (32..MAX)) + (CONSTRAINED BY { + -- MUST be a valid value of -- NamedBits + -- but if the value to be sent would be truncated to shorter + -- than 32 bits according to DER, the value MUST be padded + -- with trailing zero bits to 32 bits. Otherwise, no + -- trailing zero bits may be present. + + }) + + + AddrType ::= Int32 + + HostAddress ::= SEQUENCE { + addr-type [0] AddrType, + address [1] OCTET STRING + } + + -- NOTE: HostAddresses is always used as an OPTIONAL field and + -- should not be a zero-length SEQUENCE OF. + -- + -- The extensible messages explicitly constrain this to be + -- non-empty. + HostAddresses ::= SEQUENCE OF HostAddress + + + -- + -- *** crypto-related types and assignments + -- + + + + + + + + + + + + + + + + + + + + + + + +Yu Expires: Apr 2007 [Page 77] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + -- Assigned numbers denoting encryption mechanisms. + EType ::= Int32 + + -- assigned numbers for encryption schemes + et-des-cbc-crc EType ::= 1 + et-des-cbc-md4 EType ::= 2 + et-des-cbc-md5 EType ::= 3 + -- [reserved] 4 + et-des3-cbc-md5 EType ::= 5 + -- [reserved] 6 + et-des3-cbc-sha1 EType ::= 7 + et-dsaWithSHA1-CmsOID EType ::= 9 + et-md5WithRSAEncryption-CmsOID EType ::= 10 + et-sha1WithRSAEncryption-CmsOID EType ::= 11 + et-rc2CBC-EnvOID EType ::= 12 + et-rsaEncryption-EnvOID EType ::= 13 + et-rsaES-OAEP-ENV-OID EType ::= 14 + et-des-ede3-cbc-Env-OID EType ::= 15 + et-des3-cbc-sha1-kd EType ::= 16 + -- AES + et-aes128-cts-hmac-sha1-96 EType ::= 17 + -- AES + et-aes256-cts-hmac-sha1-96 EType ::= 18 + -- Microsoft + et-rc4-hmac EType ::= 23 + -- Microsoft + et-rc4-hmac-exp EType ::= 24 + -- opaque; PacketCable + et-subkey-keymaterial EType ::= 65 + + + + + + + + + + + + + + + + + + + + + + + +Yu Expires: Apr 2007 [Page 78] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + -- Assigned numbers denoting key usages. + KeyUsage ::= UInt32 + + -- + -- Actual identifier names are provisional and subject to + -- change. + -- + ku-pa-enc-ts KeyUsage ::= 1 + ku-Ticket KeyUsage ::= 2 + ku-EncASRepPart KeyUsage ::= 3 + ku-TGSReqAuthData-sesskey KeyUsage ::= 4 + ku-TGSReqAuthData-subkey KeyUsage ::= 5 + ku-pa-TGSReq-cksum KeyUsage ::= 6 + ku-pa-TGSReq-authenticator KeyUsage ::= 7 + ku-EncTGSRepPart-sesskey KeyUsage ::= 8 + ku-EncTGSRepPart-subkey KeyUsage ::= 9 + ku-Authenticator-cksum KeyUsage ::= 10 + ku-APReq-authenticator KeyUsage ::= 11 + ku-EncAPRepPart KeyUsage ::= 12 + ku-EncKrbPrivPart KeyUsage ::= 13 + ku-EncKrbCredPart KeyUsage ::= 14 + ku-KrbSafe-cksum KeyUsage ::= 15 + ku-ad-KDCIssued-cksum KeyUsage ::= 19 + + + -- The following numbers are provisional... + -- conflicts may exist elsewhere. + ku-Ticket-cksum KeyUsage ::= 29 + ku-ASReq-cksum KeyUsage ::= 30 + ku-TGSReq-cksum KeyUsage ::= 31 + ku-ASRep-cksum KeyUsage ::= 32 + ku-TGSRep-cksum KeyUsage ::= 33 + ku-APReq-cksum KeyUsage ::= 34 + ku-APRep-cksum KeyUsage ::= 35 + ku-KrbCred-cksum KeyUsage ::= 36 + ku-KrbError-cksum KeyUsage ::= 37 + ku-KDCRep-cksum KeyUsage ::= 38 + + ku-kg-acceptor-seal KeyUsage ::= 22 + ku-kg-acceptor-sign KeyUsage ::= 23 + ku-kg-intiator-seal KeyUsage ::= 24 + ku-kg-intiator-sign KeyUsage ::= 25 + + -- KeyUsage values 25..27 used by hardware preauth? + + -- for KINK + ku-kink-encrypt KeyUsage ::= 39 + ku-kink-cksum KeyUsage ::= 40 + + + + +Yu Expires: Apr 2007 [Page 79] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + -- KeyToUse identifies which key is to be used to encrypt or + -- sign a given value. + -- + -- Values of KeyToUse are never actually transmitted over the + -- wire, or even used directly by the implementation in any + -- way, as key usages are; it exists primarily to identify + -- which key gets used for what purpose. Thus, the specific + -- numeric values associated with this type are irrelevant. + KeyToUse ::= ENUMERATED { + -- unspecified + key-unspecified, + -- server long term key + key-server, + -- client long term key + key-client, + -- key selected by KDC for encryption of a KDC-REP + key-kdc-rep, + -- session key from ticket + key-session, + -- subsession key negotiated via AP-REQ/AP-REP + key-subsession, + ... + } + + + EncryptionKey ::= SEQUENCE { + keytype [0] EType, + keyvalue [1] OCTET STRING + } + + + + + + + + + + + + + + + + + + + + + + + +Yu Expires: Apr 2007 [Page 80] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + + -- "Type" specifies which ASN.1 type is encrypted to the + -- ciphertext in the EncryptedData. "Keys" specifies a set of + -- keys of which one key may be used to encrypt the data. + -- "KeyUsages" specifies a set of key usages, one of which may + -- be used to encrypt. + -- + -- None of the parameters is transmitted over the wire. + EncryptedData { + Type, KeyToUse:Keys, KeyUsage:KeyUsages + } ::= SEQUENCE { + etype [0] EType, + kvno [1] UInt32 OPTIONAL, + cipher [2] OCTET STRING (CONSTRAINED BY { + -- must be encryption of -- + OCTET STRING (CONTAINING Type), + -- with one of the keys -- KeyToUse:Keys, + -- with key usage being one of -- + KeyUsage:KeyUsages + }), + ... + } + + + + CksumType ::= Int32 + + -- The parameters specify which key to use to produce the + -- signature, as well as which key usage to use. The + -- parameters are not actually sent over the wire. + Checksum { + KeyToUse:Keys, KeyUsage:KeyUsages + } ::= SEQUENCE { + cksumtype [0] CksumType, + checksum [1] OCTET STRING (CONSTRAINED BY { + -- signed using one of the keys -- + KeyToUse:Keys, + -- with key usage being one of -- + KeyUsage:KeyUsages + }) + } + + + + + + + + + + + +Yu Expires: Apr 2007 [Page 81] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + -- a Checksum that must contain the checksum + -- of a particular type + ChecksumOf { + Type, KeyToUse:Keys, KeyUsage:KeyUsages + } ::= Checksum { Keys, KeyUsages } (WITH COMPONENTS { + ..., + checksum (CONSTRAINED BY { + -- must be checksum of -- + OCTET STRING (CONTAINING Type) + }) + }) + + + -- parameterized type for wrapping authenticated plaintext + Signed { + InnerType, KeyToUse:Keys, KeyUsage:KeyUsages + } ::= SEQUENCE { + cksum [0] ChecksumOf { + InnerType, Keys, KeyUsages + } OPTIONAL, + inner [1] InnerType, + ... + } + + + -- + -- *** Tickets + -- + + + Ticket ::= CHOICE { + rfc1510 Ticket1510, + ext TicketExt + } + + + Ticket1510 ::= [APPLICATION 1] SEQUENCE { + tkt-vno [0] INTEGER (5), + realm [1] RealmIA5, + sname [2] PrincipalNameIA5, + enc-part [3] EncryptedData { + EncTicketPart1510, { key-server }, { ku-Ticket } + } + } + + + + + + + + +Yu Expires: Apr 2007 [Page 82] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + TicketExt ::= [APPLICATION 4] Signed { + [APPLICATION 4] SEQUENCE { + tkt-vno [0] INTEGER (5), + realm [1] RealmExt, + sname [2] PrincipalNameExt, + enc-part [3] EncryptedData { + EncTicketPartExt, { key-server }, { ku-Ticket } + }, + ..., + extensions [4] TicketExtensions OPTIONAL, + ... + }, + { key-ticket }, { ku-Ticket-cksum } + } + + + -- Encrypted part of ticket + EncTicketPart ::= CHOICE { + rfc1510 EncTicketPart1510, + ext EncTicketPartExt + } + + + EncTicketPart1510 ::= [APPLICATION 3] SEQUENCE { + flags [0] TicketFlags, + key [1] EncryptionKey, + crealm [2] RealmIA5, + cname [3] PrincipalNameIA5, + transited [4] TransitedEncoding, + authtime [5] KerberosTime, + starttime [6] KerberosTime OPTIONAL, + endtime [7] KerberosTime, + renew-till [8] KerberosTime OPTIONAL, + caddr [9] HostAddresses OPTIONAL, + authorization-data [10] AuthorizationData OPTIONAL + } + + + + + + + + + + + + + + + + +Yu Expires: Apr 2007 [Page 83] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + EncTicketPartExt ::= [APPLICATION 5] SEQUENCE { + flags [0] TicketFlags, + key [1] EncryptionKey, + crealm [2] RealmExt, + cname [3] PrincipalNameExt, + transited [4] TransitedEncoding, + authtime [5] KerberosTime, + starttime [6] KerberosTime OPTIONAL, + endtime [7] KerberosTime, + renew-till [8] KerberosTime OPTIONAL, + caddr [9] HostAddresses OPTIONAL, + authorization-data [10] AuthorizationData OPTIONAL, + ..., + } + + + -- + -- *** Authorization Data + -- + + + ADType ::= TH-id + + AuthorizationData ::= SEQUENCE OF SEQUENCE { + ad-type [0] ADType, + ad-data [1] OCTET STRING + } + + + ad-if-relevant ADType ::= int32 : 1 + + -- Encapsulates another AuthorizationData. + -- Intended for application servers; receiving application servers + -- MAY ignore. + AD-IF-RELEVANT ::= AuthorizationData + + + -- KDC-issued privilege attributes + ad-kdcissued ADType ::= int32 : 4 + + AD-KDCIssued ::= SEQUENCE { + ad-checksum [0] ChecksumOf { + AuthorizationData, { key-session }, + { ku-ad-KDCIssued-cksum }}, + i-realm [1] Realm OPTIONAL, + i-sname [2] PrincipalName OPTIONAL, + elements [3] AuthorizationData + } + + + + +Yu Expires: Apr 2007 [Page 84] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + ad-and-or ADType ::= int32 : 5 + + AD-AND-OR ::= SEQUENCE { + condition-count [0] Int32, + elements [1] AuthorizationData + } + + + -- KDCs MUST interpret any AuthorizationData wrapped in this. + ad-mandatory-for-kdc ADType ::= int32 : 8 + AD-MANDATORY-FOR-KDC ::= AuthorizationData + + + ad-initial-verified-cas ADType ::= int32 : 9 + + + TrType ::= TH-id -- must be registered + + -- encoded Transited field + TransitedEncoding ::= SEQUENCE { + tr-type [0] TrType, + contents [1] OCTET STRING + } + + + TEType ::= TH-id + + -- ticket extensions: for TicketExt only + TicketExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE { + te-type [0] TEType, + te-data [1] OCTET STRING + } + + + + + + + + + + + + + + + + + + + + +Yu Expires: Apr 2007 [Page 85] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + TicketFlags ::= KerberosFlags { TicketFlagsBits } + + TicketFlagsBits ::= BIT STRING { + reserved (0), + forwardable (1), + forwarded (2), + proxiable (3), + proxy (4), + may-postdate (5), + postdated (6), + invalid (7), + renewable (8), + initial (9), + pre-authent (10), + hw-authent (11), + transited-policy-checked (12), + ok-as-delegate (13), + anonymous (14), + cksummed-ticket (15) + } + + + -- + -- *** KDC protocol + -- + + + AS-REQ ::= CHOICE { + rfc1510 AS-REQ-1510, + ext AS-REQ-EXT + } + AS-REQ-1510 ::= [APPLICATION 10] KDC-REQ-1510 + -- AS-REQ must include client name + + AS-REQ-EXT ::= [APPLICATION 6] Signed { + [APPLICATION 6] KDC-REQ-EXT, { key-client }, { ku-ASReq-cksum } + } + -- AS-REQ must include client name + + + TGS-REQ ::= CHOICE { + rfc1510 TGS-REQ-1510, + ext TGS-REQ-EXT + } + + TGS-REQ-1510 ::= [APPLICATION 12] KDC-REQ-1510 + + TGS-REQ-EXT ::= [APPLICATION 8] Signed { + [APPLICATION 8] KDC-REQ-EXT, { key-session }, { ku-TGSReq-cksum } + } + + +Yu Expires: Apr 2007 [Page 86] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + KDC-REQ-1510 ::= SEQUENCE { + -- NOTE: first tag is [1], not [0] + pvno [1] INTEGER (5), + msg-type [2] INTEGER ( 10 -- AS-REQ -- + | 12 -- TGS-REQ -- ), + padata [3] SEQUENCE OF PA-DATA OPTIONAL, + req-body [4] KDC-REQ-BODY-1510 + } + + + KDC-REQ-EXT ::= SEQUENCE { + pvno [1] INTEGER (5), + msg-type [2] INTEGER ( 6 -- AS-REQ -- + | 8 -- TGS-REQ -- ), + padata [3] SEQUENCE (SIZE (1..MAX)) OF PA-DATA OPTIONAL, + req-body [4] KDC-REQ-BODY-EXT, + ... + } + + + KDC-REQ-BODY-1510 ::= SEQUENCE { + kdc-options [0] KDCOptions, + cname [1] PrincipalNameIA5 OPTIONAL + -- Used only in AS-REQ --, + + realm [2] RealmIA5 + -- Server's realm; also client's in AS-REQ --, + + sname [3] PrincipalNameIA5 OPTIONAL, + from [4] KerberosTime OPTIONAL, + till [5] KerberosTime, + rtime [6] KerberosTime OPTIONAL, + nonce [7] Nonce32, + etype [8] SEQUENCE OF EType + -- in preference order --, + + addresses [9] HostAddresses OPTIONAL, + enc-authorization-data [10] EncryptedData { + AuthorizationData, { key-session | key-subsession }, + { ku-TGSReqAuthData-subkey | + ku-TGSReqAuthData-sesskey } + } OPTIONAL, + + additional-tickets [11] SEQUENCE OF Ticket OPTIONAL + -- NOTE: not empty -- + } + + + + + + +Yu Expires: Apr 2007 [Page 87] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + KDC-REQ-BODY-EXT ::= SEQUENCE { + kdc-options [0] KDCOptions, + cname [1] PrincipalName OPTIONAL + -- Used only in AS-REQ --, + + realm [2] Realm + -- Server's realm; also client's in AS-REQ --, + + sname [3] PrincipalName OPTIONAL, + from [4] KerberosTime OPTIONAL, + till [5] KerberosTime OPTIONAL + -- was required in rfc1510; + -- still required for compat versions + -- of messages --, + + rtime [6] KerberosTime OPTIONAL, + nonce [7] Nonce, + etype [8] SEQUENCE OF EType + -- in preference order --, + + addresses [9] HostAddresses OPTIONAL, + enc-authorization-data [10] EncryptedData { + AuthorizationData, { key-session | key-subsession }, + { ku-TGSReqAuthData-subkey | + ku-TGSReqAuthData-sesskey } + } OPTIONAL, + + additional-tickets [11] SEQUENCE OF Ticket OPTIONAL + -- NOTE: not empty --, + ... + lang-tags [5] SEQUENCE (SIZE (1..MAX)) OF + LangTag OPTIONAL, + ... + } + + + + + + + + + + + + + + + + + + +Yu Expires: Apr 2007 [Page 88] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + KDCOptions ::= KerberosFlags { KDCOptionsBits } + + KDCOptionsBits ::= BIT STRING { + reserved (0), + forwardable (1), + forwarded (2), + proxiable (3), + proxy (4), + allow-postdate (5), + postdated (6), + unused7 (7), + renewable (8), + unused9 (9), + unused10 (10), + unused11 (11), + unused12 (12), + unused13 (13), + requestanonymous (14), + canonicalize (15), + disable-transited-check (26), + renewable-ok (27), + enc-tkt-in-skey (28), + renew (30), + validate (31) + -- XXX need "need ticket1" flag? + } + + + AS-REP ::= CHOICE { + rfc1510 AS-REP-1510, + ext AS-REP-EXT + } + AS-REP-1510 ::= [APPLICATION 11] KDC-REP-1510 + AS-REP-EXT ::= [APPLICATION 7] Signed { + [APPLICATION 7] KDC-REP-EXT, + { key-reply }, { ku-ASRep-cksum } + } + + + TGS-REP ::= CHOICE { + rfc1510 TGS-REP-1510, + ext TGS-REP-EXT + } + TGS-REP-1510 ::= [APPLICATION 13] KDC-REP-1510 { EncTGSRepPart1510 } + TGS-REP-EXT ::= [APPLICATION 9] Signed { + [APPLICATION 9] KDC-REP-EXT { EncTGSRepPartExt }, + { key-reply }, { ku-TGSRep-cksum } + } + + + + +Yu Expires: Apr 2007 [Page 89] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + KDC-REP-1510 { EncPart } ::= SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (11 -- AS-REP.rfc1510 -- | + 13 -- TGS.rfc1510 -- ), + padata [2] SEQUENCE OF PA-DATA OPTIONAL, + crealm [3] RealmIA5, + cname [4] PrincipalNameIA5, + ticket [5] Ticket, + + enc-part [6] EncryptedData { + EncPart, + { key-reply }, + -- maybe reach into EncryptedData in AS-REP/TGS-REP + -- definitions to apply constraints on key usages? + { ku-EncASRepPart -- if AS-REP -- | + ku-EncTGSRepPart-subkey -- if TGS-REP and + -- using Authenticator + -- session key -- | + ku-EncTGSRepPart-sesskey -- if TGS-REP and using + -- subsession key -- } + } + } + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Yu Expires: Apr 2007 [Page 90] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + KDC-REP-EXT { EncPart } ::= SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (7 -- AS-REP.ext -- | + 9 -- TGS-REP.ext -- ), + padata [2] SEQUENCE OF PA-DATA OPTIONAL, + crealm [3] RealmExt, + cname [4] PrincipalNameExt, + ticket [5] Ticket, + + enc-part [6] EncryptedData { + EncPart, + { key-reply }, + -- maybe reach into EncryptedData in AS-REP/TGS-REP + -- definitions to apply constraints on key usages? + { ku-EncASRepPart -- if AS-REP -- | + ku-EncTGSRepPart-subkey -- if TGS-REP and + -- using Authenticator + -- session key -- | + ku-EncTGSRepPart-sesskey -- if TGS-REP and using + -- subsession key -- } + }, + + ..., + -- In extensible version, KDC signs original request + -- to avoid replay attacks against client. + req-cksum [7] ChecksumOf { CHOICE { + as-req AS-REQ, + tgs-req TGS-REQ + }, { key-reply }, { ku-KDCRep-cksum }} OPTIONAL, + lang-tag [8] LangTag OPTIONAL, + ... + } + + + + + + + + + + + + + + + + + + + + +Yu Expires: Apr 2007 [Page 91] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + EncASRepPart1510 ::= [APPLICATION 25] EncKDCRepPart1510 + EncTGSRepPart1510 ::= [APPLICATION 26] EncKDCRepPart1510 + + EncASRepPartExt ::= [APPLICATION 32] EncKDCRepPartExt + EncTGSRepPartExt ::= [APPLICATION 33] EncKDCRepPartExt + + EncKDCRepPart1510 ::= SEQUENCE { + key [0] EncryptionKey, + last-req [1] LastReq, + nonce [2] Nonce32, + key-expiration [3] KerberosTime OPTIONAL, + flags [4] TicketFlags, + authtime [5] KerberosTime, + starttime [6] KerberosTime OPTIONAL, + endtime [7] KerberosTime, + renew-till [8] KerberosTime OPTIONAL, + srealm [9] RealmIA5, + sname [10] PrincipalNameIA5, + caddr [11] HostAddresses OPTIONAL + } + + EncKDCRepPartExt ::= SEQUENCE { + key [0] EncryptionKey, + last-req [1] LastReq, + nonce [2] Nonce, + key-expiration [3] KerberosTime OPTIONAL, + flags [4] TicketFlags, + authtime [5] KerberosTime, + starttime [6] KerberosTime OPTIONAL, + endtime [7] KerberosTime, + renew-till [8] KerberosTime OPTIONAL, + srealm [9] Realm, + sname [10] PrincipalName, + caddr [11] HostAddresses OPTIONAL, + ... + } + + + LRType ::= TH-id + LastReq ::= SEQUENCE OF SEQUENCE { + lr-type [0] LRType, + lr-value [1] KerberosTime + } + + + -- + -- *** preauth + -- + + + + +Yu Expires: Apr 2007 [Page 92] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + PaDataType ::= TH-id + PaDataOID ::= RELATIVE-OID + + PA-DATA ::= SEQUENCE { + -- NOTE: first tag is [1], not [0] + padata-type [1] PaDataType, + padata-value [2] OCTET STRING + } + + + -- AP-REQ authenticating a TGS-REQ + pa-tgs-req PaDataType ::= int32 : 1 + PA-TGS-REQ ::= AP-REQ + + + -- Encrypted timestamp preauth + -- Encryption key used is client's long-term key. + pa-enc-timestamp PaDataType ::= int32 : 2 + + PA-ENC-TIMESTAMP ::= EncryptedData { + PA-ENC-TS-ENC, { key-client }, { ku-pa-enc-ts } + } + + PA-ENC-TS-ENC ::= SEQUENCE { + patimestamp [0] KerberosTime -- client's time --, + pausec [1] Microseconds OPTIONAL + } + + + -- Hints returned in AS-REP or KRB-ERROR to help client + -- choose a password-derived key, either for preauthentication + -- or for decryption of the reply. + pa-etype-info PaDataType ::= int32 : 11 + + ETYPE-INFO ::= SEQUENCE OF ETYPE-INFO-ENTRY + + ETYPE-INFO-ENTRY ::= SEQUENCE { + etype [0] EType, + salt [1] OCTET STRING OPTIONAL + } + + + + + + + + + + + + +Yu Expires: Apr 2007 [Page 93] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + -- Similar to etype-info, but with parameters provided for + -- the string-to-key function. + pa-etype-info2 PaDataType ::= int32 : 19 + + ETYPE-INFO2 ::= SEQUENCE (SIZE (1..MAX)) + OF ETYPE-INFO-ENTRY + + ETYPE-INFO2-ENTRY ::= SEQUENCE { + etype [0] EType, + salt [1] KerberosString OPTIONAL, + s2kparams [2] OCTET STRING OPTIONAL + } + + + -- Obsolescent. Salt for client long-term key + -- Its character encoding is unspecified. + pa-pw-salt PaDataType ::= int32 : 3 + + -- The "padata-value" does not encode an ASN.1 type. + -- Instead, "padata-value" must consist of the salt string to + -- be used by the client, in an unspecified character + -- encoding. + + + -- An extensible AS-REQ may be sent as a padata in a + -- non-extensible AS-REQ to allow for backwards compatibility. + pa-as-req PaDataType ::= int32 : 42 -- provisional + PA-AS-REQ ::= AS-REQ (WITH COMPONENTS ext) + + + -- + -- *** Session key exchange + -- + + + AP-REQ ::= CHOICE { + rfc1510 AP-REQ-1510, + ext AP-REQ-EXT + } + + + + + + + + + + + + + +Yu Expires: Apr 2007 [Page 94] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + AP-REQ-1510 ::= [APPLICATION 14] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (14), + ap-options [2] APOptions, + ticket [3] Ticket1510, + authenticator [4] EncryptedData { + Authenticator1510, + { key-session }, + { ku-APReq-authenticator | + ku-pa-TGSReq-authenticator } + } + } + + + AP-REQ-EXT ::= [APPLICATION 18] Signed { + [APPLICATION 18] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (18), + ap-options [2] APOptions, + ticket [3] Ticket, + authenticator [4] EncryptedData { + AuthenticatorExt, + { key-session }, + { ku-APReq-authenticator | + ku-pa-TGSReq-authenticator } + }, + ..., + extensions [5] ApReqExtensions OPTIONAL, + lang-tag [6] SEQUENCE (SIZE (1..MAX)) + OF LangTag OPTIONAL, + ... + }, { key-session }, { ku-APReq-cksum } + } + + + ApReqExtType ::= TH-id + + ApReqExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE { + apReqExt-Type [0] ApReqExtType, + apReqExt-Data [1] OCTET STRING + } + + + APOptions ::= KerberosFlags { APOptionsBits } + + APOptionsBits ::= BIT STRING { + reserved (0), + use-session-key (1), + mutual-required (2) + } + + +Yu Expires: Apr 2007 [Page 95] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + -- plaintext of authenticator + Authenticator1510 ::= [APPLICATION 2] SEQUENCE { + authenticator-vno [0] INTEGER (5), + crealm [1] RealmIA5, + cname [2] PrincipalNameIA5, + cksum [3] Checksum {{ key-session }, + { ku-Authenticator-cksum | + ku-pa-TGSReq-cksum }} OPTIONAL, + cusec [4] Microseconds, + ctime [5] KerberosTime, + subkey [6] EncryptionKey OPTIONAL, + seq-number [7] SeqNum32 OPTIONAL, + authorization-data [8] AuthorizationData OPTIONAL + } + + AuthenticatorExt ::= [APPLICATION 35] SEQUENCE { + authenticator-vno [0] INTEGER (5), + crealm [1] RealmExt, + cname [2] PrincipalNameExt, + cksum [3] Checksum {{ key-session }, + { ku-Authenticator-cksum | + ku-pa-TGSReq-cksum }} OPTIONAL, + cusec [4] Microseconds, + ctime [5] KerberosTime, + subkey [6] EncryptionKey OPTIONAL, + seq-number [7] SeqNum OPTIONAL, + authorization-data [8] AuthorizationData OPTIONAL, + ... + } + + + AP-REP ::= CHOICE { + rfc1510 AP-REP-1510, + ext AP-REP-EXT + } + + + AP-REP-1510 ::= [APPLICATION 15] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (15), + enc-part [2] EncryptedData { + EncApRepPart1510, + { key-session | key-subsession }, { ku-EncAPRepPart }} + } + + + + + + + + +Yu Expires: Apr 2007 [Page 96] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + AP-REP-EXT ::= [APPLICATION 19] Signed { + [APPLICATION 19] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (19), + enc-part [2] EncryptedData { + EncAPRepPartExt, + { key-session | key-subsession }, { ku-EncAPRepPart }}, + ..., + extensions [3] ApRepExtensions OPTIONAL, + ... + }, { key-session | key-subsession }, { ku-APRep-cksum } + } + + + ApRepExtType ::= TH-id + + ApRepExtensions ::= SEQUENCE (SIZE (1..MAX)) OF SEQUENCE { + apRepExt-Type [0] ApRepExtType, + apRepExt-Data [1] OCTET STRING + } + + + EncAPRepPart ::= CHOICE { + rfc1510 EncAPRepPart1510, + ext EncAPRepPartExt + } + + + EncAPRepPart1510 ::= [APPLICATION 27] SEQUENCE { + ctime [0] KerberosTime, + cusec [1] Microseconds, + subkey [2] EncryptionKey OPTIONAL, + seq-number [3] SeqNum32 OPTIONAL + } + + + EncAPRepPartExt ::= [APPLICATION 31] SEQUENCE { + ctime [0] KerberosTime, + cusec [1] Microseconds, + subkey [2] EncryptionKey OPTIONAL, + seq-number [3] SeqNum OPTIONAL, + ..., + authorization-data [4] AuthorizationData OPTIONAL, + ... + } + + + -- + -- *** Application messages + -- + + +Yu Expires: Apr 2007 [Page 97] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + KRB-SAFE ::= CHOICE { + rfc1510 KRB-SAFE-1510, + ext KRB-SAFE-EXT + } + + + KRB-SAFE-1510 ::= [APPLICATION 20] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (20), + safe-body [2] KRB-SAFE-BODY, + cksum [3] ChecksumOf { + KRB-SAFE-BODY, + { key-session | key-subsession }, { ku-KrbSafe-cksum }} + } + + + -- Has safe-body optional to allow for GSS-MIC type functionality + KRB-SAFE-EXT ::= [APPLICATION 34] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (20), + safe-body [2] KRB-SAFE-BODY OPTIONAL, + cksum [3] ChecksumOf { + KRB-SAFE-BODY, + { key-session | key-subsession }, { ku-KrbSafe-cksum }}, + ... + } + + + KRB-SAFE-BODY ::= SEQUENCE { + user-data [0] OCTET STRING, + timestamp [1] KerberosTime OPTIONAL, + usec [2] Microseconds OPTIONAL, + seq-number [3] SeqNum OPTIONAL, + s-address [4] HostAddress, + r-address [5] HostAddress OPTIONAL, + ... -- ASN.1 extensions must be excluded + -- when sending to rfc1510 implementations + } + + + KRB-PRIV ::= [APPLICATION 21] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (21), + enc-part [3] EncryptedData { + EncKrbPrivPart, + { key-session | key-subsession }, { ku-EncKrbPrivPart }}, + ... + } + + + + +Yu Expires: Apr 2007 [Page 98] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { + user-data [0] OCTET STRING, + timestamp [1] KerberosTime OPTIONAL, + usec [2] Microseconds OPTIONAL, + seq-number [3] SeqNum OPTIONAL, + s-address [4] HostAddress -- sender's addr --, + r-address [5] HostAddress OPTIONAL -- recip's addr --, + ... -- ASN.1 extensions must be excluded + -- when sending to rfc1510 implementations + } + + + KRB-CRED ::= CHOICE { + rfc1510 KRB-CRED-1510, + ext KRB-CRED-EXT + + } + + + KRB-CRED-1510 ::= [APPLICATION 22] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (22), + tickets [2] SEQUENCE OF Ticket, + enc-part [3] EncryptedData { + EncKrbCredPart, + { key-session | key-subsession }, { ku-EncKrbCredPart }} + } + + + KRB-CRED-EXT ::= [APPLICATION 24] Signed { + [APPLICATION 24] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (24), + tickets [2] SEQUENCE OF Ticket, + enc-part [3] EncryptedData { + EncKrbCredPart, + { key-session | key-subsession }, { ku-EncKrbCredPart }}, + ... + }, { key-session | key-subsession }, { ku-KrbCred-cksum } + } + + + + + + + + + + + + +Yu Expires: Apr 2007 [Page 99] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + EncKrbCredPart ::= [APPLICATION 29] SEQUENCE { + ticket-info [0] SEQUENCE OF KrbCredInfo, + nonce [1] Nonce OPTIONAL, + timestamp [2] KerberosTime OPTIONAL, + usec [3] Microseconds OPTIONAL, + s-address [4] HostAddress OPTIONAL, + r-address [5] HostAddress OPTIONAL + } + + + KrbCredInfo ::= SEQUENCE { + key [0] EncryptionKey, + prealm [1] Realm OPTIONAL, + pname [2] PrincipalName OPTIONAL, + flags [3] TicketFlags OPTIONAL, + authtime [4] KerberosTime OPTIONAL, + starttime [5] KerberosTime OPTIONAL, + endtime [6] KerberosTime OPTIONAL, + renew-till [7] KerberosTime OPTIONAL, + srealm [8] Realm OPTIONAL, + sname [9] PrincipalName OPTIONAL, + caddr [10] HostAddresses OPTIONAL + } + + + TGT-REQ ::= [APPLICATION 16] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (16), + sname [2] PrincipalName OPTIONAL, + srealm [3] Realm OPTIONAL, + ... + } + + + -- + -- *** Error messages + -- + + + ErrCode ::= Int32 + + KRB-ERROR ::= CHOICE { + rfc1510 KRB-ERROR-1510, + ext KRB-ERROR-EXT + } + + + + + + + +Yu Expires: Apr 2007 [Page 100] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + KRB-ERROR-1510 ::= [APPLICATION 30] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (30), + ctime [2] KerberosTime OPTIONAL, + cusec [3] Microseconds OPTIONAL, + stime [4] KerberosTime, + susec [5] Microseconds, + error-code [6] ErrCode, + crealm [7] RealmIA5 OPTIONAL, + cname [8] PrincipalNameIA5 OPTIONAL, + realm [9] RealmIA5 -- Correct realm --, + sname [10] PrincipalNameIA5 -- Correct name --, + e-text [11] KerberosString OPTIONAL, + e-data [12] OCTET STRING OPTIONAL + } + + + KRB-ERROR-EXT ::= [APPLICATION 23] Signed { + [APPLICATION 23] SEQUENCE{ + pvno [0] INTEGER (5), + msg-type [1] INTEGER (23), + ctime [2] KerberosTime OPTIONAL, + cusec [3] Microseconds OPTIONAL, + stime [4] KerberosTime, + susec [5] Microseconds, + error-code [6] ErrCode, + crealm [7] Realm OPTIONAL, + cname [8] PrincipalName OPTIONAL, + realm [9] Realm -- Correct realm --, + sname [10] PrincipalName -- Correct name --, + e-text [11] KerberosString OPTIONAL, + e-data [12] OCTET STRING OPTIONAL, + ..., + typed-data [13] TYPED-DATA OPTIONAL, + nonce [14] Nonce OPTIONAL, + lang-tag [15] LangTag OPTIONAL, + ... + }, { }, { ku-KrbError-cksum } + } + + + METHOD-DATA ::= SEQUENCE OF PA-DATA + + + TDType ::= TH-id + + TYPED-DATA ::= SEQUENCE SIZE (1..MAX) OF SEQUENCE { + data-type [0] TDType, + data-value [1] OCTET STRING OPTIONAL + } + + +Yu Expires: Apr 2007 [Page 101] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + td-dh-parameters TDType ::= int32 : 109 + + + -- + -- *** Error codes + -- + + -- No error + kdc-err-none ErrCode ::= 0 + -- Client's entry in database has expired + kdc-err-name-exp ErrCode ::= 1 + -- Server's entry in database has expired + kdc-err-service-exp ErrCode ::= 2 + -- Requested protocol version number not supported + kdc-err-bad-pvno ErrCode ::= 3 + -- Client's key encrypted in old master key + kdc-err-c-old-mast-kvno ErrCode ::= 4 + -- Server's key encrypted in old master key + kdc-err-s-old-mast-kvno ErrCode ::= 5 + -- Client not found in Kerberos database + kdc-err-c-principal-unknown ErrCode ::= 6 + -- Server not found in Kerberos database + kdc-err-s-principal-unknown ErrCode ::= 7 + -- Multiple principal entries in database + kdc-err-principal-not-unique ErrCode ::= 8 + -- The client or server has a null key + kdc-err-null-key ErrCode ::= 9 + -- Ticket not eligible for postdating + kdc-err-cannot-postdate ErrCode ::= 10 + -- Requested start time is later than end time + kdc-err-never-valid ErrCode ::= 11 + -- KDC policy rejects request + kdc-err-policy ErrCode ::= 12 + -- KDC cannot accommodate requested option + kdc-err-badoption ErrCode ::= 13 + -- KDC has no support for encryption type + kdc-err-etype-nosupp ErrCode ::= 14 + -- KDC has no support for checksum type + kdc-err-sumtype-nosupp ErrCode ::= 15 + -- KDC has no support for padata type + kdc-err-padata-type-nosupp ErrCode ::= 16 + -- KDC has no support for transited type + kdc-err-trtype-nosupp ErrCode ::= 17 + -- Clients credentials have been revoked + kdc-err-client-revoked ErrCode ::= 18 + -- Credentials for server have been revoked + kdc-err-service-revoked ErrCode ::= 19 + -- TGT has been revoked + kdc-err-tgt-revoked ErrCode ::= 20 + + + +Yu Expires: Apr 2007 [Page 102] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + -- Client not yet valid - try again later + kdc-err-client-notyet ErrCode ::= 21 + -- Server not yet valid - try again later + kdc-err-service-notyet ErrCode ::= 22 + -- Password has expired - change password to reset + kdc-err-key-expired ErrCode ::= 23 + -- Pre-authentication information was invalid + kdc-err-preauth-failed ErrCode ::= 24 + -- Additional pre-authenticationrequired + kdc-err-preauth-required ErrCode ::= 25 + -- Requested server and ticket don't match + kdc-err-server-nomatch ErrCode ::= 26 + -- Server principal valid for user2user only + kdc-err-must-use-user2user ErrCode ::= 27 + -- KDC Policy rejects transited path + kdc-err-path-not-accpeted ErrCode ::= 28 + -- A service is not available + kdc-err-svc-unavailable ErrCode ::= 29 + -- Integrity check on decrypted field failed + krb-ap-err-bad-integrity ErrCode ::= 31 + -- Ticket expired + krb-ap-err-tkt-expired ErrCode ::= 32 + -- Ticket not yet valid + krb-ap-err-tkt-nyv ErrCode ::= 33 + -- Request is a replay + krb-ap-err-repeat ErrCode ::= 34 + -- The ticket isn't for us + krb-ap-err-not-us ErrCode ::= 35 + -- Ticket and authenticator don't match + krb-ap-err-badmatch ErrCode ::= 36 + -- Clock skew too great + krb-ap-err-skew ErrCode ::= 37 + -- Incorrect net address + krb-ap-err-badaddr ErrCode ::= 38 + -- Protocol version mismatch + krb-ap-err-badversion ErrCode ::= 39 + -- Invalid msg type + krb-ap-err-msg-type ErrCode ::= 40 + + + + + + + + + + + + + + +Yu Expires: Apr 2007 [Page 103] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + -- Message stream modified + krb-ap-err-modified ErrCode ::= 41 + -- Message out of order + krb-ap-err-badorder ErrCode ::= 42 + -- Specified version of key is not available + krb-ap-err-badkeyver ErrCode ::= 44 + -- Service key not available + krb-ap-err-nokey ErrCode ::= 45 + -- Mutual authentication failed + krb-ap-err-mut-fail ErrCode ::= 46 + -- Incorrect message direction + krb-ap-err-baddirection ErrCode ::= 47 + -- Alternative authentication method required + krb-ap-err-method ErrCode ::= 48 + -- Incorrect sequence number in message + krb-ap-err-badseq ErrCode ::= 49 + -- Inappropriate type of checksum in message + krb-ap-err-inapp-cksum ErrCode ::= 50 + -- Policy rejects transited path + krb-ap-path-not-accepted ErrCode ::= 51 + -- Response too big for UDP, retry with TCP + krb-err-response-too-big ErrCode ::= 52 + -- Generic error (description in e-text) + krb-err-generic ErrCode ::= 60 + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Yu Expires: Apr 2007 [Page 104] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + -- Field is too long for this implementation + krb-err-field-toolong ErrCode ::= 61 + -- Reserved for PKINIT + kdc-error-client-not-trusted ErrCode ::= 62 + -- Reserved for PKINIT + kdc-error-kdc-not-trusted ErrCode ::= 63 + -- Reserved for PKINIT + kdc-error-invalid-sig ErrCode ::= 64 + -- Reserved for PKINIT + kdc-err-key-too-weak ErrCode ::= 65 + -- Reserved for PKINIT + kdc-err-certificate-mismatch ErrCode ::= 66 + -- No TGT available to validate USER-TO-USER + krb-ap-err-no-tgt ErrCode ::= 67 + -- USER-TO-USER TGT issued different KDC + kdc-err-wrong-realm ErrCode ::= 68 + -- Ticket must be for USER-TO-USER + krb-ap-err-user-to-user-required ErrCode ::= 69 + -- Reserved for PKINIT + kdc-err-cant-verify-certificate ErrCode ::= 70 + -- Reserved for PKINIT + kdc-err-invalid-certificate ErrCode ::= 71 + -- Reserved for PKINIT + kdc-err-revoked-certificate ErrCode ::= 72 + -- Reserved for PKINIT + kdc-err-revocation-status-unknown ErrCode ::= 73 + -- Reserved for PKINIT + kdc-err-revocation-status-unavailable ErrCode ::= 74 + -- Reserved for PKINIT + kdc-err-client-name-mismatch ErrCode ::= 75 + -- Reserved for PKINIT + kdc-err-kdc-name-mismatch ErrCode ::= 76 + -- Reserved for PKINIT + kdc-err-inconsistent-key-purpose ErrCode ::= 77 + -- Reserved for PKINIT + kdc-err-digest-in-cert-not-accepted ErrCode ::= 78 + -- Reserved for PKINIT + kdc-err-pa-checksum-must-be-included ErrCode ::= 79 + -- Reserved for PKINIT + kdc-err-digest-in-signed-data-not-accepted ErrCode ::= 80 + -- Reserved for PKINIT + kdc-err-public-key-encryption-not-supported ErrCode ::= 81 + + + END + + +B. Kerberos and Character Encodings (Informative) + + [adapted from KCLAR 5.2.1] + + +Yu Expires: Apr 2007 [Page 105] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + The original specification of the Kerberos protocol in RFC 1510 uses + GeneralString in numerous places for human-readable string data. + Historical implementations of Kerberos cannot utilize the full power + of GeneralString. This ASN.1 type requires the use of designation + and invocation escape sequences as specified in ISO 2022 | ECMA-35 + [ISO2022] to switch character sets, and the default character set + that is designated as G0 is the ISO 646 | ECMA-6 [ISO646] + International Reference Version (IRV) (aka U.S. ASCII), which mostly + works. + + ISO 2022 | ECMA-35 defines four character-set code elements (G0..G3) + and two Control-function code elements (C0..C1). DER previously + [X690-1997] prohibited the designation of character sets as any but + the G0 and C0 sets. This had the side effect of prohibiting the use + of (ISO Latin) character-sets such as ISO 8859-1 [ISO8859-1] or any + other character-sets that utilize a 96-character set, since it is + prohibited by ISO 2022 | ECMA-35 to designate them as the G0 code + element. Recent revisions to the ASN.1 standards resolve this + contradiction. + + In practice, many implementations treat RFC 1510 GeneralStrings as if + they were 8-bit strings of whichever character set the implementation + defaults to, without regard for correct usage of character-set + designation escape sequences. The default character set is often + determined by the current user's operating system dependent locale. + At least one major implementation places unescaped UTF-8 encoded + Unicode characters in the GeneralString. This failure to conform to + the GeneralString specifications results in interoperability issues + when conflicting character encodings are utilized by the Kerberos + clients, services, and KDC. + + This unfortunate situation is the result of improper documentation of + the restrictions of the ASN.1 GeneralString type in prior Kerberos + specifications. + + [the following should probably be rewritten and moved into the + principal name section] + + For compatibility, implementations MAY choose to accept GeneralString + values that contain characters other than those permitted by + IA5String, but they should be aware that character set designation + codes will likely be absent, and that the encoding should probably be + treated as locale-specific in almost every way. Implementations MAY + also choose to emit GeneralString values that are beyond those + permitted by IA5String, but should be aware that doing so is + extraordinarily risky from an interoperability perspective. + + Some existing implementations use GeneralString to encode unescaped + locale-specific characters. This is a violation of the ASN.1 + standard. Most of these implementations encode US-ASCII in the left- + hand half, so as long the implementation transmits only US-ASCII, the + +Yu Expires: Apr 2007 [Page 106] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + ASN.1 standard is not violated in this regard. As soon as such an + implementation encodes unescaped locale-specific characters with the + high bit set, it violates the ASN.1 standard. + + Other implementations have been known to use GeneralString to contain + a UTF-8 encoding. This also violates the ASN.1 standard, since UTF-8 + is a different encoding, not a 94 or 96 character "G" set as defined + by ISO 2022. It is believed that these implementations do not even + use the ISO 2022 escape sequence to change the character encoding. + Even if implementations were to announce the change of encoding by + using that escape sequence, the ASN.1 standard prohibits the use of + any escape sequences other than those used to designate/invoke "G" or + "C" sets allowed by GeneralString. + +C. Kerberos History (Informative) + + [Adapted from KCLAR "BACKGROUND"] + + The Kerberos model is based in part on Needham and Schroeder's + trusted third-party authentication protocol [NS78] and on + modifications suggested by Denning and Sacco [DS81]. The original + design and implementation of Kerberos Versions 1 through 4 was the + work of two former Project Athena staff members, Steve Miller of + Digital Equipment Corporation and Clifford Neuman (now at the + Information Sciences Institute of the University of Southern + California), along with Jerome Saltzer, Technical Director of Project + Athena, and Jeffrey Schiller, MIT Campus Network Manager. Many other + members of Project Athena have also contributed to the work on + Kerberos. + + Version 5 of the Kerberos protocol (described in this document) has + evolved from Version 4 based on new requirements and desires for + features not available in Version 4. The design of Version 5 of the + Kerberos protocol was led by Clifford Neuman and John Kohl with much + input from the community. The development of the MIT reference + implementation was led at MIT by John Kohl and Theodore Ts'o, with + help and contributed code from many others. Since RFC1510 was + issued, extensions and revisions to the protocol have been proposed + by many individuals. Some of these proposals are reflected in this + document. Where such changes involved significant effort, the + document cites the contribution of the proposer. + + Reference implementations of both version 4 and version 5 of Kerberos + are publicly available and commercial implementations have been + developed and are widely used. Details on the differences between + Kerberos Versions 4 and 5 can be found in [KNT94]. + +D. Notational Differences from [KCLAR] + + [ possible point for discussion ] + + +Yu Expires: Apr 2007 [Page 107] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + [KCLAR] uses notational conventions slightly different from this + document. As a derivative of RFC 1510, the text of [KCLAR] uses C- + language style identifier names for defined values. In ASN.1 + notation, identifiers referencing defined values must begin with a + lowercase letter and contain hyphen (-) characters rather than + underscore (_) characters, while identifiers referencing types begin + with an uppercase letter. [KCLAR] and RFC 1510 use all-uppercase + identifiers with underscores to identify defined values. This has + the potential to create confusion, but neither document defines + values using actual ASN.1 value-assignment notation. + + It is debatable whether it is advantageous to write all identifier + names (regardless of their ASN.1 token type) in all-uppercase letters + for the purpose of emphasis in running text. The alternative is to + use double-quote characters (") when ambiguity is possible. + +Normative References + + [ISO646] + "7-bit coded character set", ISO/IEC 646:1991 | ECMA-6:1991. + + [ISO2022] + "Information technology -- Character code structure and + extension techniques", ISO/IEC 2022:1994 | ECMA-35:1994. + + [KCRYPTO] + K. Raeburn, "Encryption and Checksum Specifications for Kerberos + 5", draft-ietf-krb-wg-crypto-07.txt, work in progress. + + [RFC2119] + S. Bradner, RFC2119: "Key words for use in RFC's to Indicate + Requirement Levels", March 1997. + + [RFC3660] + H. Alvestrand, "Tags for the Identification of Languages", + RFC 3660, January 2001. + + [SASLPREP] + Kurt D. Zeilenga, "SASLprep: Stringprep profile for user names + and passwords", draft-ietf-sasl-saslprep-10.txt, work in + progress. + + [X680] + "Information technology -- Abstract Syntax Notation One (ASN.1): + Specification of basic notation", ITU-T Recommendation X.680 + (2002) | ISO/IEC 8824-1:2002. + + [X682] + "Information technology -- Abstract Syntax Notation One (ASN.1): + Constraint specification", ITU-T Recommendation X.682 (2002) | + ISO/IEC 8824-3:2002. + +Yu Expires: Apr 2007 [Page 108] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + [X683] + "Information technology -- Abstract Syntax Notation One (ASN.1): + Parameterization of ASN.1 specifications", ITU-T Recommendation + X.683 (2002) | ISO/IEC 8824-4:2002. + + [X690] + "Information technology -- ASN.1 encoding Rules: Specification + of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) + and Distinguished Encoding Rules (DER)", ITU-T Recommendation + X.690 (2002) | ISO/IEC 8825-1:2002. + +Informative References + + [DS81] + Dorothy E. Denning and Giovanni Maria Sacco, "Time-stamps in Key + Distribution Protocols," Communications of the ACM, Vol. 24(8), + pp. 533-536 (August 1981). + + [Dub00] + Olivier Dubuisson, "ASN.1 - Communication between Heterogeneous + Systems", Elsevier-Morgan Kaufmann, 2000. + + + [ISO8859-1] + "Information technology -- 8-bit single-byte coded graphic + character sets -- Part 1: Latin alphabet No. 1", ISO/IEC 8859- + 1:1998. + + [KCLAR] + Clifford Neuman, Tom Yu, Sam Hartman, Ken Raeburn, "The Kerberos + Network Authentication Service (V5)", draft-ietf-krb-wg- + kerberos-clarifications-07.txt, work in progress. + + [KNT94] + John T. Kohl, B. Clifford Neuman, and Theodore Y. Ts'o, "The + Evolution of the Kerberos Authentication System". In + Distributed Open Systems, pages 78-94. IEEE Computer Society + Press, 1994. + + [Lar96] + John Larmouth, "Understanding OSI", International Thomson + Computer Press, 1996. + + + [Lar99] + John Larmouth, "ASN.1 Complete", Elsevier-Morgan Kaufmann, + 1999. + + [NS78] + Roger M. Needham and Michael D. Schroeder, "Using Encryption for + Authentication in Large Networks of Computers", Communications + +Yu Expires: Apr 2007 [Page 109] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + of the ACM, Vol. 21(12), pp. 993-999 (December, 1978). + + [RFC1510] + J. Kohl and B. C. Neuman, "The Kerberos Network Authentication + Service (v5)", RFC1510, September 1993, Status: Proposed + Standard. + + [RFC1964] + J. Linn, "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, + June 1996, Status: Proposed Standard. + + [X690-2002] + "Information technology -- ASN.1 encoding rules: Specification + of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) + and Distinguished Encoding Rules (DER)", ITU-T Recommendation + X.690 (2002) | ISO/IEC 8825-1:2002. + +Author's Address + + Tom Yu + 77 Massachusetts Ave + Cambridge, MA 02139 + USA + tlyu@mit.edu + +Copyright Statement + + Copyright (C) The Internet Society (2006). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set forth therein, the authors retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + + +Yu Expires: Apr 2007 [Page 110] + +Internet-Draft rfc1510ter-03 23 Oct 2006 + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Yu Expires: Apr 2007 [Page 111] + + diff --git a/doc/standardisation/draft-josefsson-kerberos5-starttls-00.txt b/doc/standardisation/draft-josefsson-kerberos5-starttls-00.txt new file mode 100644 index 000000000..e5be859ae --- /dev/null +++ b/doc/standardisation/draft-josefsson-kerberos5-starttls-00.txt @@ -0,0 +1,447 @@ +Network Working Group S. Josefsson +Internet-Draft November 13, 2004 +Expires: May 14, 2005 + + + Using Transport Layer Security (TLS) with Kerberos 5 + draft-josefsson-kerberos5-starttls-00 + +Status of this Memo + + This document is an Internet-Draft and is subject to all provisions + of section 3 of RFC 3667. By submitting this Internet-Draft, each + author represents that any applicable patent or other IPR claims of + which he or she is aware have been or will be disclosed, and any of + which he or she become aware will be disclosed, in accordance with + RFC 3668. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as + Internet-Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on May 14, 2005. + +Copyright Notice + + Copyright (C) The Internet Society (2004). + +Abstract + + This document specify how the Transport Layer Security (TLS) protocol + is used in conjunction with the Kerberos 5 protocol. + + + + + + + + + +Josefsson Expires May 14, 2005 [Page 1] + +Internet-Draft Using TLS with Kerberos 5 November 2004 + + +Table of Contents + + 1. Introduction and Background . . . . . . . . . . . . . . . . . 3 + 2. Extension Mechanism for TCP/IP transport . . . . . . . . . . . 4 + 3. Kerberos 5 STARTTLS Extension . . . . . . . . . . . . . . . . 4 + 3.1 STARTTLS requested by client (extension 1) . . . . . . . . 4 + 3.2 STARTTLS request accepted by server (extension 2) . . . . 5 + 3.3 Proceeding after successful TLS negotiation . . . . . . . 5 + 3.4 Proceeding after failed TLS negotiation . . . . . . . . . 5 + 3.5 STARTTLS aware KDC Discovery . . . . . . . . . . . . . . . 5 + 3.6 Initial Authentication via TLS . . . . . . . . . . . . . . 5 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 + 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 5.1 Normative References . . . . . . . . . . . . . . . . . . . . 6 + 5.2 Informative References . . . . . . . . . . . . . . . . . . . 6 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7 + Intellectual Property and Copyright Statements . . . . . . . . 8 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Josefsson Expires May 14, 2005 [Page 2] + +Internet-Draft Using TLS with Kerberos 5 November 2004 + + +1. Introduction and Background + + This document describe how Shishi, a Kerberos 5 [1] implementation, + upgrade communication between clients and Key Distribution Centers + (KDCs) to use the Transport Layer Security (TLS) [2] protocol. + + The TLS protocol offer integrity and privacy protected exchanges that + can be authentication using X.509 certificates, OpenPGP keys [6], and + user name and passwords via SRP [5]. + + An inconclusive list of the motivation for using TLS with Kerberos 5 + is given below. + + o Explicit server authentication of the KDC to the client. In + traditional Kerberos 5, authentication of the KDC is proved as a + side effect that the KDC knows your encryption key (i.e., your + password). + + o Flexible authentication against KDC. Kerberos 5 assume the user + knows a key (usually in the form of a password). Sometimes + external factors make this hard to fulfill. In some situations, + users are equipped with smart cards with a RSA authentication key. + In others, users have a OpenPGP client on their desktop, with a + public OpenPGP key known to the server. In some situations, the + policy may be that password authentication may only be done + through SRP. + + o Kerberos exchanges are privacy protected. Part of many Kerberos + packets are transfered without privacy protection (i.e., + encryption). That part contains information, such as the client + principal name, the server principal name, the encryption types + supported by the client, the lifetime of tickets, etc. Revealing + such information is, in some threat models, considered a problem. + + o Prevents downgrade attacks affecting encryption types. The + encryption type of the ticket in KDC-REQ are sent in the clear in + Kerberos 5. This allows an attacker to replace the encryption + type with a compromised mechanisms, e.g. 56-bit DES. Since + clients in general cannot know the encryption types other servers + support, it is difficult for the client to detect if there was a + man-in-the-middle or if the remote server simply did not support a + stronger mechanism. Clients could chose to refuse 56-bit DES + altogether, but in some environments this leads to operational + difficulties. + + o The TLS protocol has been studied by many parties. In some threat + models, the designer prefer to reduce the number of protocols that + can hurt the overall system security if they are compromised. + + + +Josefsson Expires May 14, 2005 [Page 3] + +Internet-Draft Using TLS with Kerberos 5 November 2004 + + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [4]. + +2. Extension Mechanism for TCP/IP transport + + Kerberos 5 require Key Distribution Centers (KDCs) to accept requests + over TCP. Each request and response is prefixed by 4 octets, + encoding an integer in network byte order, that indicate the length + of the packet. The high bit of the 4 octet length field was reserved + for future expansion. Servers that do not understand how to + interpret a set high bit are required to return a KRB-ERROR with the + KRB_ERR_FIELD_TOOLONG error code, and to close the TCP stream. + + We will use the reserved bit to provide an extension mechanism. When + the reserved high bit is set, the remaining 31 bits of the 4 octets + are treated as an extensible typed hole, and thus form a 31 bit + integer enumerating various extensions. Each of the values indicate + a specific extended operation mode, two of which are used and defined + here, and the rest are left for others to use. + + If the KDC do not understand a requested extension, it MUST return a + KRB-ERROR with a KRB_ERR_FIELD_TOOLONG value (prefixed by the 4 octet + length integer, with the high bit clear, as usual) and close the TCP + stream. + + The following table specify the meaning of the 31 lower bits in the 4 + octet field, when the high bit is set: + + 0 RESERVED. + 1 STARTTLS requested by client. + 2 STARTTLS request accepted by server. + 3...2147483647 AVAILABLE for registration (via bug-shishi@josefsson.org) +. + 2147483648 RESERVED. + + +3. Kerberos 5 STARTTLS Extension + +3.1 STARTTLS requested by client (extension 1) + + When this message is sent by the client, the client is requesting the + server to start TLS negotiation on the TCP stream. The client MUST + NOT start TLS negotiation immediately. Instead, the client wait for + either a KRB-ERROR (sent normally, prefixed by a 4 octet length + integer) indicating the server do not understand the set high bit, or + 4 octets which is to be interpreted as an integer in network byte + order, where the high bit is set and the remaining 31 bit are + interpreted as an integer specifying ``STARTTLS request accepted by + + + +Josefsson Expires May 14, 2005 [Page 4] + +Internet-Draft Using TLS with Kerberos 5 November 2004 + + + server'' (extension 2). In the first case, the client infer that the + server do not understand (or wish to support) STARTTLS, and can + re-try using normal TCP, if unprotected Kerberos 5 exchanges are + acceptable to the client policy. In the latter case, it should + invoke TLS negotiation on the stream. If any other data is received, + the client MUST close the TCP stream. + +3.2 STARTTLS request accepted by server (extension 2) + + This message should be sent by the server when it has received the + extension 1 message. The message is an acknowledgment of the + client's request to initiate STARTTLS on the channel. The server + MUST then invoke a TLS negotiation. + +3.3 Proceeding after successful TLS negotiation + + If the TLS negotiation ended successfully, possibly also considering + client or server policies, the exchange within the TLS protected + stream is performed like normal UDP Kerberos 5 exchanges, i.e., there + is no TCP 4 octet length field before each packet. Instead each + Kerberos packet MUST be sent within one TLS record, so the + application can use the TLS record length as the Kerberos 5 packet + length. + +3.4 Proceeding after failed TLS negotiation + + If the TLS negotiation fails, possibly due to client or server policy + (e.g., inadequate support of encryption types in TLS, or lack of + client or server authentication) the entity that detect the failure + MUST disconnected the connection. It is expected that any error + messages that explain the error condition is transfered by TLS. + +3.5 STARTTLS aware KDC Discovery + + Section 7.2.3 of Kerberos 5 [1] describe how Domain Name System (DNS) + SRV records [3] can be used to find the address of an KDC. To locate + a KDC that support the STARTTLS extension, we use the "_tls" domain. + For example: + + _kerberos._tls._tcp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com. + _kerberos._tls._tcp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com. + + +3.6 Initial Authentication via TLS + + The server MAY consider the authentication performed by the TLS + exchange as sufficient to issue Kerberos 5 tickets to the client, + without requiring, e.g., pre-authentication. However, it is not an + + + +Josefsson Expires May 14, 2005 [Page 5] + +Internet-Draft Using TLS with Kerberos 5 November 2004 + + + error to require or use pre-authentication as well. + + The client may also indicate that it wishes to use TLS both for + authentication and data protection by using the NULL encryption type + in its request. The server can decide from its local policy whether + or not issuing tickets based solely on TLS authentication, and + whether NULL encryption within TLS, is acceptable or not. + +4. Security Considerations + + Because the initial token is not protected, it is possible for an + active attacker to make it appear to the client that the server do + not support this extension. It is up to client configuration to + disallow non-TLS connections, if that vulnerability is deemed + unacceptable. For interoperability, we suggest the default behaviour + should be to allow automatic fall back to TCP or UDP. + + The security considerations of both TLS and Kerberos 5 are inherited. + Using TLS for authentication and/or data protection together with + Kerberos alter the authentication logic fundamentally. Thus, it may + be that even if the TLS and Kerberos 5 protocols and implementations + were secure, the combination of TLS and Kerberos 5 described here + could be insecure. + + No channel bindings are provided in the Kerberos messages. It is an + open question whether, and how, this could be solved. One idea for + solving this may be to specify a new encryption algorithm in Kerberos + 5 that is similar to the NULL encryption algorithm, but also include + the TLS session identifier. + +5. References + +5.1 Normative References + + [1] Neuman, C., "The Kerberos Network Authentication Service (V5)", + draft-ietf-krb-wg-kerberos-clarifications-07 (work in progress), + September 2004. + + [2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC + 2246, January 1999. + + [3] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for + specifying the location of services (DNS SRV)", RFC 2782, + February 2000. + +5.2 Informative References + + [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement + + + +Josefsson Expires May 14, 2005 [Page 6] + +Internet-Draft Using TLS with Kerberos 5 November 2004 + + + Levels", BCP 14, RFC 2119, March 1997. + + [5] Taylor, D., "Using SRP for TLS Authentication", + draft-ietf-tls-srp-08 (work in progress), August 2004. + + [6] Mavroyanopoulos, N., "Using OpenPGP keys for TLS + authentication", draft-ietf-tls-openpgp-keys-05 (work in + progress), April 2004. + + +Author's Address + + Simon Josefsson + + EMail: simon@josefsson.org + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Josefsson Expires May 14, 2005 [Page 7] + +Internet-Draft Using TLS with Kerberos 5 November 2004 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Disclaimer of Validity + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Copyright Statement + + Copyright (C) The Internet Society (2004). This document is subject + to the rights, licenses and restrictions contained in BCP 78, and + except as set for +th therein, the authors retain all their rights. + + +Acknowledgment + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + +Josefsson Expires May 14, 2005 [Page 8] \ No newline at end of file diff --git a/doc/standardisation/draft-josefsson-kerberos5-starttls-01.txt b/doc/standardisation/draft-josefsson-kerberos5-starttls-01.txt new file mode 100644 index 000000000..35a790dbb --- /dev/null +++ b/doc/standardisation/draft-josefsson-kerberos5-starttls-01.txt @@ -0,0 +1,672 @@ + + + +Network Working Group S. Josefsson +Internet-Draft SJD +Intended status: Standards Track October 4, 2006 +Expires: April 7, 2007 + + + Using Kerberos V5 over the Transport Layer Security (TLS) protocol + draft-josefsson-kerberos5-starttls-01 + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on April 7, 2007. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + + + + + + + + + + + + + + +Josefsson Expires April 7, 2007 [Page 1] + +Internet-Draft Protecting Kerberos V5 with TLS October 2006 + + +Abstract + + This document specify how the Kerberos V5 protocol can be transported + over the Transport Layer Security (TLS) protocol, to provide + additional security features. + + +Table of Contents + + 1. Introduction and Background . . . . . . . . . . . . . . . . . 3 + 2. Kerberos V5 STARTTLS Extension . . . . . . . . . . . . . . . . 5 + 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 4. STARTTLS aware KDC Discovery . . . . . . . . . . . . . . . . . 7 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 + 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 + Intellectual Property and Copyright Statements . . . . . . . . . . 12 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Josefsson Expires April 7, 2007 [Page 2] + +Internet-Draft Protecting Kerberos V5 with TLS October 2006 + + +1. Introduction and Background + + This document describe how a Kerberos V5 [2] implementation may + upgrade communication between clients and Key Distribution Centers + (KDCs) to use the Transport Layer Security (TLS) [4] protocol. + + The TLS protocol offer integrity and privacy protected exchanges that + can be authentication using X.509 certificates, OpenPGP keys [7], and + user name and passwords via SRP [6]. + + There are several reasons to use Kerberos V5 over TLS. + + o Kerberos exchanges are privacy protected. Part of many Kerberos + packets are transfered without privacy protection (i.e., + encryption). That part contains information, such as the client + principal name, the server principal name, the encryption types + supported by the client, the lifetime of tickets, etc. Revealing + such information is, in some threat models, considered a problem. + + + o Prevents downgrade attacks affecting encryption types. The + encryption type of the ticket in KDC-REQ are sent in the clear in + Kerberos 5. This allows an attacker to replace the encryption + type with a compromised mechanisms, e.g., 56-bit DES. Since + clients in general cannot know the encryption types other servers + support, it is difficult for the client to detect if there was a + man-in-the-middle or if the remote server simply did not support a + stronger mechanism. Clients could chose to refuse, e.g., 56-bit + DES altogether, but in some environments this leads to operational + difficulties. + + + o Additional authentication against the KDC. In some situations, + users are equipped with smart cards with a RSA authentication key. + In others, users have a OpenPGP client on their desktop, with a + public OpenPGP key known to the server. In some situations, the + policy may be that password authentication may only be done + through SRP. + + + o The TLS protocol has been studied by many parties. In some threat + models, the designer prefer to reduce the number of protocols that + can hurt the overall system security if they are compromised. + + + o Explicit server authentication of the KDC to the client. In + traditional Kerberos 5, authentication of the KDC is proved as a + side effect that the KDC knows your encryption key (i.e., your + + + +Josefsson Expires April 7, 2007 [Page 3] + +Internet-Draft Protecting Kerberos V5 with TLS October 2006 + + + password). + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [1]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Josefsson Expires April 7, 2007 [Page 4] + +Internet-Draft Protecting Kerberos V5 with TLS October 2006 + + +2. Kerberos V5 STARTTLS Extension + + The STARTTLS extension uses the Kerberos V5 TCP extension mechanism + [3]. The extension uses bit #TBD in the extension bitmask. + + The protocol is as follows. After the server has sent the 4-octet + value 0x00000000 to indicate support of this extension, the stream + will be controlled by the TLS protocol and its framing. The TLS + protocol is initiated by the client. + + Typically, the client initiate the TLS handshake protocol by sending + a client hello, and the server responds, and the handshake continues + until it either succeed or fails. + + If for any reason the handshake fails, the STARTTLS protocol will + also fail, and the TLS error is used as the error indication. + + If the handshake succeeds, the Kerberos V5 authentication protocol is + performed within the protected TLS channel, like a normal TCP + Kerberos V5 exchange. In particular, this means that every Kerberos + V5 packet will be prefixed by a 4-octet length field, that indicate + the length of the Kerberos V5 packet. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Josefsson Expires April 7, 2007 [Page 5] + +Internet-Draft Protecting Kerberos V5 with TLS October 2006 + + +3. Examples + + A complete packet flow for a successful AS-REQ/REP exchange protected + by this mechanism will be as follows. The "STARTTLS-bit" is a + 4-octet value with only the bit allocated for this extension set. + + Client Server + + [ Kerberos V5 TCP extension mechanism negotiation starts ] + + [0x70000000 & STARTTLS-bit] --------> + [0x00000000] + <-------- + + [ TLS negotiation starts ] + + + ClientHello --------> + ServerHello + Certificate* + ServerKeyExchange* + CertificateRequest* + <-------- ServerHelloDone + Certificate* + ClientKeyExchange + CertificateVerify* + [ChangeCipherSpec] + Finished --------> + [ChangeCipherSpec] + <-------- Finished + + [ Kerberos V5 negotiation starts ] + + Kerberos V5 AS-REQ --------> + Kerberos V5 AS-REP + <-------- + + * Indicates optional or situation-dependent messages that are not + always sent. + + + + + + + + + + + + +Josefsson Expires April 7, 2007 [Page 6] + +Internet-Draft Protecting Kerberos V5 with TLS October 2006 + + +4. STARTTLS aware KDC Discovery + + Section 7.2.3 of Kerberos V5 [2] describe how Domain Name System + (DNS) SRV records [5] can be used to find the address of an KDC. + Using the terminology of Section 7.2.3 of RFC 4120, we define a new + Proto of "tls" to indicate that the particular KDC is intended to + support this STARTTLS extension. The Service, Realm, TTL, Class, + SRV, Priority, Weight, Port and Target have the same meaning as in + RFC 4120. + + For example: + + _kerberos._tls.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com. + _kerberos._tls.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Josefsson Expires April 7, 2007 [Page 7] + +Internet-Draft Protecting Kerberos V5 with TLS October 2006 + + +5. IANA Considerations + + The IANA is requested to allocate a bit in the "Kerberos TCP + Extensions" registry for the extension described in this document, as + per [3]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Josefsson Expires April 7, 2007 [Page 8] + +Internet-Draft Protecting Kerberos V5 with TLS October 2006 + + +6. Security Considerations + + The security considerations in Kerberos V5, TLS, and the extension + mechanism framework are inherited. + + To protect against the inherent downgrade attack in the extension + framework, it is suggested that implementations offer a policy to + require that this extension is successfully negotiated. For + interoperability with implementations that do not support this + extension, it is suggested that the policy is disabled by default. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Josefsson Expires April 7, 2007 [Page 9] + +Internet-Draft Protecting Kerberos V5 with TLS October 2006 + + +7. References + +7.1. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos + Network Authentication Service (V5)", RFC 4120, July 2005. + + [3] Josefsson, S., "Extended Kerberos Version 5 Key Distribution + Center (KDC) Exchanges Over TCP", + draft-ietf-krb-wg-tcp-expansion-01 (work in progress), + September 2006. + + [4] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) + Protocol Version 1.1", RFC 4346, April 2006. + + [5] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for + specifying the location of services (DNS SRV)", RFC 2782, + February 2000. + +7.2. Informative References + + [6] Taylor, D., "Using SRP for TLS Authentication", + draft-ietf-tls-srp-12 (work in progress), June 2006. + + [7] Mavroyanopoulos, N., "Using OpenPGP keys for TLS + authentication", draft-ietf-tls-openpgp-keys-10 (work in + progress), June 2006. + + + + + + + + + + + + + + + + + + + + + +Josefsson Expires April 7, 2007 [Page 10] + +Internet-Draft Protecting Kerberos V5 with TLS October 2006 + + +Author's Address + + Simon Josefsson + SJD + + Email: simon@josefsson.org + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Josefsson Expires April 7, 2007 [Page 11] + +Internet-Draft Protecting Kerberos V5 with TLS October 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Acknowledgment + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + +Josefsson Expires April 7, 2007 [Page 12] + diff --git a/doc/standardisation/draft-josefsson-kerberos5-starttls-02.txt b/doc/standardisation/draft-josefsson-kerberos5-starttls-02.txt new file mode 100644 index 000000000..5793b7053 --- /dev/null +++ b/doc/standardisation/draft-josefsson-kerberos5-starttls-02.txt @@ -0,0 +1,672 @@ + + + +Network Working Group S. Josefsson +Internet-Draft SJD +Intended status: Standards Track October 21, 2006 +Expires: April 24, 2007 + + + Using Kerberos V5 over the Transport Layer Security (TLS) protocol + draft-josefsson-kerberos5-starttls-02 + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on April 24, 2007. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + + + + + + + + + + + + + + +Josefsson Expires April 24, 2007 [Page 1] + +Internet-Draft Protecting Kerberos V5 with TLS October 2006 + + +Abstract + + This document specify how the Kerberos V5 protocol can be transported + over the Transport Layer Security (TLS) protocol, to provide + additional security features. + + +Table of Contents + + 1. Introduction and Background . . . . . . . . . . . . . . . . . 3 + 2. Kerberos V5 STARTTLS Extension . . . . . . . . . . . . . . . . 5 + 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 4. STARTTLS aware KDC Discovery . . . . . . . . . . . . . . . . . 7 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 + 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 + Intellectual Property and Copyright Statements . . . . . . . . . . 12 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Josefsson Expires April 24, 2007 [Page 2] + +Internet-Draft Protecting Kerberos V5 with TLS October 2006 + + +1. Introduction and Background + + This document describe how a Kerberos V5 [2] implementation may + upgrade communication between clients and Key Distribution Centers + (KDCs) to use the Transport Layer Security (TLS) [4] protocol. + + The TLS protocol offer integrity and privacy protected exchanges that + can be authentication using X.509 certificates, OpenPGP keys [7], and + user name and passwords via SRP [6]. + + There are several reasons to use Kerberos V5 over TLS. + + o Prevents downgrade attacks affecting, e.g., encryption types and + pre-auth data negotiation. The encryption type field in KDC-REQ, + and the METHOD-DATA field with the requested pre-auth types from + the server in KDC_ERR_PREAUTH_REQUIRED errors in KDC-REP, are sent + without integrity or privacy protection in Kerberos 5. This + allows an attacker to replace the encryption type with a + compromised encryption type, e.g., 56-bit DES, or request that + clients should use a broken pre-auth type. Since clients in + general cannot know the encryption types other servers support, or + the pre-auth types servers prefer or require, it is difficult for + the client to detect if there was a man-in-the-middle or if the + remote server simply did not support a stronger encryption type or + preferred another pre-auth type. + + + o Kerberos exchanges are privacy protected. Part of many Kerberos + packets are transfered without privacy protection (i.e., + encryption). That part contains information, such as the client + principal name, the server principal name, the encryption types + supported by the client, the lifetime of tickets, etc. Revealing + such information is, in some threat models, considered a problem. + + + o Additional authentication against the KDC. In some situations, + users are equipped with smart cards with a RSA authentication key. + In others, users have a OpenPGP client on their desktop, with a + public OpenPGP key known to the server. + + o The TLS protocol has been studied by many parties. In some threat + models, the designer prefer to reduce the number of protocols that + can hurt the overall system security if they are compromised. + + + o Explicit server authentication of the KDC to the client. In + traditional Kerberos 5, authentication of the KDC is proved as a + side effect that the KDC knows your encryption key (i.e., your + + + +Josefsson Expires April 24, 2007 [Page 3] + +Internet-Draft Protecting Kerberos V5 with TLS October 2006 + + + password). + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [1]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Josefsson Expires April 24, 2007 [Page 4] + +Internet-Draft Protecting Kerberos V5 with TLS October 2006 + + +2. Kerberos V5 STARTTLS Extension + + The STARTTLS extension uses the Kerberos V5 TCP extension mechanism + [3]. The extension uses bit #TBD in the extension bitmask. + + The protocol is as follows. After the server has sent the 4-octet + value 0x00000000 to indicate support of this extension, the stream + will be controlled by the TLS protocol and its framing. The TLS + protocol is initiated by the client. + + Typically, the client initiate the TLS handshake protocol by sending + a client hello, and the server responds, and the handshake continues + until it either succeed or fails. + + If for any reason the handshake fails, the STARTTLS protocol will + also fail, and the TLS error is used as the error indication. + + If the handshake succeeds, the Kerberos V5 authentication protocol is + performed within the protected TLS channel, like a normal TCP + Kerberos V5 exchange. In particular, this means that every Kerberos + V5 packet will be prefixed by a 4-octet length field, that indicate + the length of the Kerberos V5 packet. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Josefsson Expires April 24, 2007 [Page 5] + +Internet-Draft Protecting Kerberos V5 with TLS October 2006 + + +3. Examples + + A complete packet flow for a successful AS-REQ/REP exchange protected + by this mechanism will be as follows. The "STARTTLS-bit" is a + 4-octet value with only the bit allocated for this extension set. + + Client Server + + [ Kerberos V5 TCP extension mechanism negotiation starts ] + + [0x70000000 & STARTTLS-bit] --------> + [0x00000000] + <-------- + + [ TLS negotiation starts ] + + + ClientHello --------> + ServerHello + Certificate* + ServerKeyExchange* + CertificateRequest* + <-------- ServerHelloDone + Certificate* + ClientKeyExchange + CertificateVerify* + [ChangeCipherSpec] + Finished --------> + [ChangeCipherSpec] + <-------- Finished + + [ Kerberos V5 negotiation starts ] + + 4 octet length field + Kerberos V5 AS-REQ --------> + 4 octet length field + Kerberos V5 AS-REP + <-------- + + * Indicates optional or situation-dependent messages that are not + always sent. + + + + + + + + + + +Josefsson Expires April 24, 2007 [Page 6] + +Internet-Draft Protecting Kerberos V5 with TLS October 2006 + + +4. STARTTLS aware KDC Discovery + + Section 7.2.3 of Kerberos V5 [2] describe how Domain Name System + (DNS) SRV records [5] can be used to find the address of an KDC. + Using the terminology of Section 7.2.3 of RFC 4120, we define a new + Proto of "tls" to indicate that the particular KDC is intended to + support this STARTTLS extension. The Service, Realm, TTL, Class, + SRV, Priority, Weight, Port and Target have the same meaning as in + RFC 4120. + + For example: + + _kerberos._tls.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com. + _kerberos._tls.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Josefsson Expires April 24, 2007 [Page 7] + +Internet-Draft Protecting Kerberos V5 with TLS October 2006 + + +5. IANA Considerations + + The IANA is requested to allocate a bit in the "Kerberos TCP + Extensions" registry for the extension described in this document, as + per [3]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Josefsson Expires April 24, 2007 [Page 8] + +Internet-Draft Protecting Kerberos V5 with TLS October 2006 + + +6. Security Considerations + + The security considerations in Kerberos V5, TLS, and the extension + mechanism framework are inherited. + + To protect against the inherent downgrade attack in the extension + framework, it is suggested that implementations offer a policy to + require that this extension is successfully negotiated. For + interoperability with implementations that do not support this + extension, it is suggested that the policy is disabled by default. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Josefsson Expires April 24, 2007 [Page 9] + +Internet-Draft Protecting Kerberos V5 with TLS October 2006 + + +7. References + +7.1. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos + Network Authentication Service (V5)", RFC 4120, July 2005. + + [3] Josefsson, S., "Extended Kerberos Version 5 Key Distribution + Center (KDC) Exchanges Over TCP", + draft-ietf-krb-wg-tcp-expansion-01 (work in progress), + September 2006. + + [4] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) + Protocol Version 1.1", RFC 4346, April 2006. + + [5] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for + specifying the location of services (DNS SRV)", RFC 2782, + February 2000. + +7.2. Informative References + + [6] Taylor, D., "Using SRP for TLS Authentication", + draft-ietf-tls-srp-12 (work in progress), June 2006. + + [7] Mavroyanopoulos, N., "Using OpenPGP keys for TLS + authentication", draft-ietf-tls-openpgp-keys-10 (work in + progress), June 2006. + + + + + + + + + + + + + + + + + + + + + +Josefsson Expires April 24, 2007 [Page 10] + +Internet-Draft Protecting Kerberos V5 with TLS October 2006 + + +Author's Address + + Simon Josefsson + SJD + + Email: simon@josefsson.org + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Josefsson Expires April 24, 2007 [Page 11] + +Internet-Draft Protecting Kerberos V5 with TLS October 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Acknowledgment + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + +Josefsson Expires April 24, 2007 [Page 12] + diff --git a/doc/standardisation/draft-richards-otp-kerberos-01.txt b/doc/standardisation/draft-richards-otp-kerberos-01.txt new file mode 100644 index 000000000..5db9c39f8 --- /dev/null +++ b/doc/standardisation/draft-richards-otp-kerberos-01.txt @@ -0,0 +1,1232 @@ + + + +Network Working Group G. Richards +Internet-Draft RSA, The Security Division of EMC +Intended status: Standards Track October 11, 2006 +Expires: April 14, 2007 + + + OTP Kerberos + draft-richards-otp-kerberos-01 + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on April 14, 2007. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + The Kerberos protocol provides a framework authenticating a client + using the exchange of pre-authentication data. This document + describes the use of this framework to carry out One Time Password + (OTP) authentication. + + + + + + + +Richards Expires April 14, 2007 [Page 1] + +Internet-Draft OTP Kerberos October 2006 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Usage Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.1. Pre-Authentication . . . . . . . . . . . . . . . . . . . . 3 + 2.2. PIN Change . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2.3. Re-Synchronization . . . . . . . . . . . . . . . . . . . . 4 + 3. Pre-Authentication Protocol Details . . . . . . . . . . . . . 4 + 3.1. Shared Secret . . . . . . . . . . . . . . . . . . . . . . 4 + 3.2. Client Request . . . . . . . . . . . . . . . . . . . . . . 5 + 3.3. KDC Challenge . . . . . . . . . . . . . . . . . . . . . . 5 + 3.4. Client Response . . . . . . . . . . . . . . . . . . . . . 7 + 3.5. Verifying the pre-auth Data . . . . . . . . . . . . . . . 7 + 3.6. Updating the Secret . . . . . . . . . . . . . . . . . . . 9 + 4. Reply Key Generation Algorithms . . . . . . . . . . . . . . . 9 + 4.1. Using the OTP Value Directly . . . . . . . . . . . . . . . 9 + 4.2. Hardening the OTP Value . . . . . . . . . . . . . . . . . 9 + 4.2.1. Using an Iteration Count . . . . . . . . . . . . . . . 10 + 4.2.2. Using a Shared Secret and OTP . . . . . . . . . . . . 10 + 4.2.3. Using a Password and OTP . . . . . . . . . . . . . . . 11 + 4.3. Generating the Key without the OTP . . . . . . . . . . . . 11 + 4.3.1. Using the Password . . . . . . . . . . . . . . . . . . 11 + 4.3.2. Using a Shared Secret . . . . . . . . . . . . . . . . 11 + 5. OTP Kerberos Types . . . . . . . . . . . . . . . . . . . . . . 12 + 5.1. PA-OTP-CHALLENGE . . . . . . . . . . . . . . . . . . . . . 12 + 5.2. PA-OTP-RESPONSE . . . . . . . . . . . . . . . . . . . . . 13 + 5.3. PA-OTP-CONFIRM . . . . . . . . . . . . . . . . . . . . . . 16 + 5.4. PA-ENC-PIN . . . . . . . . . . . . . . . . . . . . . . . . 16 + 5.5. OTPChalKeyParam . . . . . . . . . . . . . . . . . . . . . 17 + 5.6. OTPRespKeyParam . . . . . . . . . . . . . . . . . . . . . 18 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 + 7.1. Active attacks . . . . . . . . . . . . . . . . . . . . . . 19 + 7.2. Denial of service attacks . . . . . . . . . . . . . . . . 19 + 7.3. Use of a Shared Secret Value . . . . . . . . . . . . . . . 19 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 + 8.2. Informative References . . . . . . . . . . . . . . . . . . 20 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 + Intellectual Property and Copyright Statements . . . . . . . . . . 22 + + + + + + + + + + + +Richards Expires April 14, 2007 [Page 2] + +Internet-Draft OTP Kerberos October 2006 + + +1. Introduction + + A One-Time Password (OTP) token may be a handheld hardware device, a + hardware device connected to a personal computer through an + electronic interface such as USB or a software module resident on a + personal computer. All these devices generate one-time passwords + that may be used to authenticate a user towards some service. This + document describes extensions to Kerberos V5 [RFC4120] to support + pre-authentication using an OTP. + + In this proposal, the KDC sends the client a random nonce, + information on which OTP token is to be used, how the OTP is to be + generated using that token and how the Reply Key is to be generated. + The Reply Key is then used to encrypt the nonce value and the + encrypted value is returned to the KDC as the pre-authentication + data. Depending on whether the KDC can obtain the OTP value, the OTP + value is either used in the generation of the Reply Key or is + encrypted using the key and returned to the KDC along with the + encrypted nonce. The encrypted nonce, an optional encrypted OTP + value and information on how the Reply Key and OTP value were + generated are sent to the KDC and used by the KDC to generate the + same Reply Key and decrypt and verify the nonce. + + This proposal is partially based upon previous work on integrating + single-use authentication mechanisms into Kerberos [HoReNeZo04] and + uses the existing password-change extensions to handle PIN change as + described in [RFC3244]. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + << This is an early draft of this document and so is liable to change + significantly. >> + + +2. Usage Overview + +2.1. Pre-Authentication + + The approach uses pre-authentication data in KRB_AS_REQ, KRB_AS_REP + and KRB_ERROR. The client begins by sending an initial KRB_AS_REQ to + the KDC that may contain pre-authentication data such as the standard + Kerberos password data. The KDC will then determine, in an + implementation dependent fashion, whether OTP authentication is + required and if it is, it will respond with a KRB_ERROR message + containing a PA-OTP-CHALLENGE in the PA-DATA. + + + + +Richards Expires April 14, 2007 [Page 3] + +Internet-Draft OTP Kerberos October 2006 + + + The PA-OTP-CHALLENGE contains information on how the OTP should be + generated, how the Reply Key should be generated and a nonce. The + client uses this information to locate the token and generate the + OTP, generate the Reply Key and then encrypt the nonce using the + generated key. Depending on the type of OTP, the Reply Key may be + generated using the OTP value or alternatively, the generated OTP + will instead be encrypted along with the nonce using the key. + + The encrypted nonce along with information on how the OTP and Reply + Key were generated are then sent to the KDC in a PA-OTP-RESPONSE PA- + DATA element. The KDC then uses this information to generate the + same key as the client, allowing it to verify the pre-authentication + by decrypting the nonce. If the validation succeeds then the KDC + returns the TGT in a KRB_AS_REP. + +2.2. PIN Change + + If, following successful validation of a PA-OTP-RESPONSE in a + KRB_AS_REQ, the KDC requires that the user changes their PIN then it + will return PA-DATA of type PA-OTP-PIN-CHANGE in the KRB_AS_REP. + This pre-auth data can be used to return a new PIN to the user if the + KDC has updated the PIN or to indicate to the user that they must + change their PIN. + + In the latter case, user PIN change shall be handled by a PIN change + service supporting the ChangePasswdData in a KRB_AP_REQ as described + in [RFC3244]. If such a user PIN change is required then the KDC + SHALL return a TGT in the KRB_AS_REP but it is RECOMMENDED that it + only issues tickets for the PIN change service until the PIN has been + changed. + +2.3. Re-Synchronization + + It is possible with time and event-based tokens, that the client and + OTP server will loose synchronization. If, when processing a PA-OTP- + RESPONSE, the pre-authentication validation fails for this reason + then the KDC SHALL return a KRB_ERROR message containing a PA-OTP- + CHALLENGE in the PA-DATA with the "nextOTP" flag set. The setting of + this flag will cause the client to re-try the authentication using + the OTP for the next token "state". + + +3. Pre-Authentication Protocol Details + +3.1. Shared Secret + + The method of deriving the Reply Key shall depend upon: + + + + +Richards Expires April 14, 2007 [Page 4] + +Internet-Draft OTP Kerberos October 2006 + + + o Whether the OTP is of sufficiently high entropy to generate the + key alone. + + o Whether the OTP has insufficient entropy and so must be + strengthened. + + o Whether the OTP value used can be obtained by the KDC. + + If the OTP value is of low entropy then it is important to slow down + an attacker sufficiently to make it economically unattractive to + brute-force search for an OTP given an observed OTP-Kerberos + exchange. If the OTP value cannot be obtained by the KDC then it + cannot be used in the derivation of the Reply Key but shall be + encrypted using the generated key rather than used to derive the key + and so the Reply Key must be derived from some other value. Both of + these issues can be solved using shared secret value known by the + client and KDC but unknown to the attacker. + + This protocol supports the following types of secret: + + o A pre-shared secret can be established between the client and KDC + and stored on the client. + + o Diffie-Hellman key agreement (as defined in [RFC2631]) can be used + to establish a shared secret value ZZ. The server's public key, + and the base and prime are stored on the client. + + The pre-shared secret value or the Diffie-Hellman shared secret + value, ZZ, are converted to a value of the required length for the + encryption scheme's random-to-key function using the n-fold function + (both defined in [RFC3961]). + +3.2. Client Request + + The client begins by sending an initial KRB_AS_REQ possibly + containing other pre-authentication data. If the KDC determines that + OTP-based pre-authentication is required and the request does not + contain a PA-OTP-RESPONSE then it will respond as described in + Section 3.3. + + Alternatively, if the client has all the necessary information, it + MAY construct a PA-OTP-RESPONSE as described in Section 3.4 and + include it in the initial request. + +3.3. KDC Challenge + + If the user is required to authenticate using an OTP then the KDC + SHALL respond to the initial KRB_AS_REQ with a KRB_ERROR containing: + + + +Richards Expires April 14, 2007 [Page 5] + +Internet-Draft OTP Kerberos October 2006 + + + o An error code of KDC_ERR_PREAUTH_REQUIRED + + o An e-data field containing PA-DATA with a PA-OTP-CHALLENGE. + + The PA-OTP-CHALLENGE SHALL contain a nonce value to be encrypted by + the generated Reply Key and it MAY also contain information on how + the OTP value is to be generated and information on how the Reply Key + is to be generated in an otp-keyParam element. + + Use of the otp-keyParam element is OPTIONAL. If it is not present + the Reply Key SHALL be generated directly from the OTP value as + specified in Section 4.1 and the OTP value SHALL NOT be included in + the client response. + + If the otp-keyParam element is present and the "sendOTP" flag is set + then the OTP value MUST NOT be used in the generation of the Reply + Key but it must instead be returned to the KDC encrypted using the + key. The Reply Key MUST be derived using one of the methods + described in Section 4.3. If the "sendOTP" flag is not set then the + OTP value is to be used in the key derivation then the client MUST + use one of the methods described in Section 4.2. + + The otp-keyParam element will control the use of a shared secret in + the key derivation. If the "noSecret" flag is set the the client + MUST NOT use a secret value in the key derivation. If the "noSecret" + flag is not set and secret identifier is present then the client MUST + NOT use any other secret value. If the "noSecret" flag is not set + and a secret identifier is not present then the client MAY still use + a value if there is a value associated with the KDC. + + If the "noSecret" flag is not set and the client can locate a secret + value for the KDC then the Reply Key will be generated using one of + the following methods: + + o If the OTP is to be included in the key derivation then the key + SHALL be derived as specified in Section 4.2.2. + + o If the OTP is to be sent encrypted in the response then the key + SHALL be derived as specified in Section 4.3.2. + + If the client fails to find a shared secret for the KDC or the + "noSecret" flag was set in the challenge then the Reply Key will be + generated using one of the following methods: + + o If the OTP is to be used in the key derivation then the KDC MAY + specify an iteration count. If such a value is specified then the + key SHALL be derived from the OTP as described in Section 4.2.1. + + + + +Richards Expires April 14, 2007 [Page 6] + +Internet-Draft OTP Kerberos October 2006 + + + o If the OTP is to be used in the key derivation but an iteration + count was not specified then the key SHALL be derived from the OTP + value and the user's Kerberos password as described in + Section 4.2.3. + + o If the OTP is to be sent encrypted then the key SHALL be derived + from the user's Kerberos password as described in section + Section 4.3.1. + +3.4. Client Response + + The client will use the generated Reply Key to encrypt the nonce from + the KDC challenge and, if required, to encrypt the OTP value. This + encrypted data SHALL be sent to the KDC in the otp-encData of a PA- + OTP-RESPONSE PA-DATA element included in a KRB_AS_REQ. + + This response MAY also include information on how the Reply Key was + generated in an optional otp-keyParam element. The client MUST NOT + include this element if the Reply Key was generated directly from the + OTP value. The element MUST be included if the Reply Key was + generated using either a secret value or an iteration count and + contain the secret identifier and iteration count value. If the + Reply Key was generated using a password then the element MUST be + present and MUST be empty. + + The response SHOULD also include information on the generated OTP + value. + +3.5. Verifying the pre-auth Data + + If KRB_AS_REQ contains a PA-OTP-RESPONSE then the KDC will then use + the information in the otp-keyParam to generate the same Reply Key + and decrypt the encrypted nonce contained in the otp-encData. + + If the encrypted OTP value is not included in the otp-encData then + the Reply Key was generated using the OTP value. The KDC SHALL + therefore use the OTP information in the PA-OTP-RESPONSE to obtain + the OTP value for the user and use the value along with the + information in the otp-keyParam to generate the Reply Key. This + information SHALL be used as follows: + + o If the otp-keyParam is not present then the Reply Key SHALL be + generated directly from the OTP value as described in Section 4.1. + + o If the otp-keyParam is present but empty then the Reply Key SHALL + be generated using the OTP value and the user's Kerberos Password + as described in Section 4.2.3. + + + + +Richards Expires April 14, 2007 [Page 7] + +Internet-Draft OTP Kerberos October 2006 + + + o If the otp-keyParam is present and contains a secret identifier + then the Reply Key SHALL be generated using the OTP value and the + secret value as described in Section 4.2.2. + + If the identified secret value can not be found then the KDC SHALL + respond with a KDC_ERR_PREAUTH_REQUIRED error as described above + but SHALL set the "noSecret" flag in the PA-OTP-CHALLENGE. + + o if the otp-keyParam is present and contains an iteration count + then the Reply Key shall be generated from the OTP value using the + iteration count value as described in Section 4.2.1. + + If the encrypted OTP value is included in the otp-encData then the + Reply Key was not generated using the OTP value but was instead used + to encrypt the OTP value. The KDC SHALL therefore use the + information in the otp-keyParam to generate the Reply Key and decrypt + the OTP value. It SHALL then validate the decrypted value using the + OTP information included in the response and fail the authentication + if the value is not valid. + + This Reply Key SHALL be generated as follows: + + o If the otp-keyParam is not present the the KDC SHALL fail the pre- + authentication with an error of KDC_ERR_PREAUTH_FAILED. + + If the otp-keyParam is omitted then the Reply Key was generated + directly from the OTP value and so is an error if the OTP value is + encrypted using the key. + + o If the otp-keyParam is present but empty then the Reply Key SHALL + be generated using the user's Kerberos Password as described in + Section 4.3.1. + + o If the otp-keyParam is present and contains a secret identifier + then the Reply Key SHALL be generated using the secret value as + described in Section 4.3.2. + + If the identified secret value can not be found then the KDC SHALL + respond with a KDC_ERR_PREAUTH_REQUIRED error as described above + but SHALL set the "noSecret" flag in the PA-OTP-CHALLENGE. + + o If the otp-keyParam is present and contains an iteration count + then the KDC SHALL fail the authentication with an error of + KDC_ERR_PREAUTH_FAILED. + + + + + + + +Richards Expires April 14, 2007 [Page 8] + +Internet-Draft OTP Kerberos October 2006 + + +3.6. Updating the Secret + + The secret value can be pre-configured on the client but MAY also be + transferred from the KDC to the client in encrypted form in the PA- + OTP-CONFIRM of the KRB_AS_REP. If a client receives a new secret + value in this way then it MUST update any stored value associated + with the KDC. + + +4. Reply Key Generation Algorithms + +4.1. Using the OTP Value Directly + + If only the OTP value is to be used then the Reply Key SHALL be + generated by passing the OTP value through string-to-key (defined in + [RFC3961]). + + K = string-to-key(OTP) + + The salt and additional parameters for string-to-key will be as + defined in section 3.1.3 of [RFC4120]. + +4.2. Hardening the OTP Value + + If the OTP value requires strengthening then several methods shall be + supported. + + o The OTP can be used on its own in the key derivation but run + through an iteration process many times as described in + Section 4.2.1. + + o A secret value, shared between the KDC and client can be used + along with the OTP value to derive the key as described in + Section 4.2.2. + + o The user's Kerberos password can be used along with the OTP value + in the key derivation as described in Section 4.2.3. + + A shared secret can only be used if the client supports the storing + of persistent values and has such a value stored. The other two + methods could be used to establish a secret value or when client are + not capable of storing such values. + + <> + + + + + + +Richards Expires April 14, 2007 [Page 9] + +Internet-Draft OTP Kerberos October 2006 + + +4.2.1. Using an Iteration Count + + An initial key is generated by running the OTP value through string- + to-key. + + K = string-to-key(OTP) + + The following key generation process is then repeated iteration count + times with the resulting key being used as the protocol key for the + next iteration. + + A sequence of octets, R, is produced from K by iterating over calls + to the function pseudo-random (defined in [RFC3961]) and appending + the results until at least the number of bits required by random-to- + key have been produced. If the result of the iteration is longer + than the required length then the result shall be truncated. + + The octet string parameter for pseudo-random shall be the ASCII + string "CombineA" with the loop number appended. This string has the + following byte value: + + {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x41} + + A new key is then generated by running R through random-to-key. + + K = random-to-key(R) + +4.2.2. Using a Shared Secret and OTP + + Two intermediate keys, K1 and K2, shall be generated by running the + OTP value once through string-to-key and the shared secret through + random-to-key. + + K1 = random-to-key(shared secret) + K2 = string-to-key(OTP) + + Two sequences of octets, R1 and R2, are then produced from K1 and K2 + by iterating over calls to pseudo-random and appending the results + until the required number of bits have been generated for random-to- + key. If the result of the iteration is longer than the required + length then the result shall be truncated. + + The octet string parameter for pseudo-random shall be the ASCII + string "CombineA" for K1 and "CombineB" for K2 with the loop number + appended. These have the following byte values: + + + + + + +Richards Expires April 14, 2007 [Page 10] + +Internet-Draft OTP Kerberos October 2006 + + + {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x41} + {0x43, 0x6f, 0x6d, 0x62, 0x69, 0x6e, 0x65, 0x42} + + The final key is then generated by combining R1 and R2 using + exclusive-OR and running the result through random-to-key. + + K = random-to-key(R1 ^ R2) + + << Check on issue around combining DES keys. >> + +4.2.3. Using a Password and OTP + + Two intermediate keys, K1 and K2, shall be generated by running the + OTP and password through string-to-key. + + K1 = string-to-key(Password) + K2 = string-to-key(OTP) + + The same process as described in Section 4.2.2 is then used to derive + the final reply key. + +4.3. Generating the Key without the OTP + + If the OTP value cannot be used in the derivation of the reply key + then this protocol supports the following options: + + o A secret value, shared between the KDC and client can be used to + derive the key as described in Section 4.3.2. + + o The user's Kerberos password can be used in the key derivation as + described in Section 4.3.1. + + A shared secret can only be used if the client supports the storing + of persistent values and has such a value stored. The password-only + method could be used to establish a secret value or when clients are + not capable of storing such values. + +4.3.1. Using the Password + + The Reply Key SHALL be generated by passing the password value + through string-to-key (defined in [RFC3961]). + +4.3.2. Using a Shared Secret + + The reply key shall be generated by running the shared secret value + through random-to-key. + + K = random-to-key(shared secret) + + + +Richards Expires April 14, 2007 [Page 11] + +Internet-Draft OTP Kerberos October 2006 + + +5. OTP Kerberos Types + +5.1. PA-OTP-CHALLENGE + + This is a pre-authentication type sent by the KDC to the client in a + KRB_ERROR. It contains information for the client on how to generate + the OTP and reply key. + + PA-OTP-CHALLENGE ::= SEQUENCE { + otp-flags OTPFlags, + otp-nonce UInt32, + otp-etype INTEGER, + otp-track-id [0] OCTET STRING OPTIONAL, + otp-challenge [1] OCTET STRING OPTIONAL, + otp-length [2] INTEGER OPTIONAL, + otp-service [3] UTF8String OPTIONAL, + otp-keyID [4] OCTET STRING OPTIONAL, + otp-algID [5] INTEGER OPTIONAL, + otp-keyParam [6] OTPChalKeyParam OPTIONAL + } + + OTPFlags ::= KerberosFlags + -- nextOTP (0) + + otp-flags + If the "nextOTP" flag is set then the OTP calculated SHALL be + based on the next token "state" rather than the current one. As + an example, for a time-based token, this means the next time slot. + For an event-based token, this could mean the next counter value, + if counter values are used. + + otp-nonce + A KDC-supplied nonce value to be encrypted by the client in the + PA-OTP-RESPONSE. + + otp-etype + The encryption type to be used by the client for all encrypted + fields in the PA-OTP-RESPONSE. + + otp-track-id + This optional element is used by the KDC to link a client response + to the corresponding KDC challenge. If present, this element MUST + be copied by the client to the corresponding element in the PA- + OTP-RESPONSE. + + + + + + + +Richards Expires April 14, 2007 [Page 12] + +Internet-Draft OTP Kerberos October 2006 + + + otp-challenge + The otp-challenge is used by the KDC to send a challenge value for + use in the OTP calculation. The challenge is an optional octet + string that SHOULD be uniquely generated for each request it is + present in, and SHOULD be eight octets or longer when present. + When the challenge is not present, the OTP will be calculated on + the current token state only. The client MAY ignore a provided + challenge if and only if the OTP token the client is interacting + with is not capable of including a challenge in the OTP + calculation. In this case, KDC policies will determine whether to + accept a provided OTP value or not. + + otp-length + The otp-length is used by the KDC to specify the desired length of + the generated OTP. + + otp-service + An identifier of the service supported by the KDC. This value can + be used by the client to locate information such as the shared + secret value and OTP key to use. + + otp-keyID + The identifier of the OTP key to be used in the OTP calculation. + If this value is not present then the client SHOULD use other + values such as the otp-service and otp-algID to locate the + appropriate key. + + otp-algID + The identifier of the algorithm to use when generating the OTP. + + otp-keyParam + Information on how the Reply Key should be generated from the OTP + and shared secret. If the value is not present then the reply key + MUST be generated directly from the OTP value. + + <> + +5.2. PA-OTP-RESPONSE + + This is a pre-authentication type sent by the client to the KDC in a + KRB_AS_REQ containing the encrypted pre-authentication data. It + contains information on the OTP used and how the key was generated + that encrypts the pre-authentication data. This information will + then allow the KDC to generate the same key and validate the pre- + authentication data. + + + + + +Richards Expires April 14, 2007 [Page 13] + +Internet-Draft OTP Kerberos October 2006 + + + PA-OTP-RESPONSE ::= SEQUENCE { + otp-flags OTPFlags, + otp-nonce UInt32, + otp-encData EncryptedData, + -- PA-ENC-RESPONSE + -- Key usage of <> + otp-track-id [0] OCTET STRING OPTIONAL, + otp-challenge [1] OCTET STRING OPTIONAL, + otp-time [2] KerberosTime OPTIONAL, + otp-counter [3] OCTET STRING OPTIONAL, + otp-format [4] OTPFormat OPTIONAL, + otp-keyID [5] OCTET STRING OPTIONAL, + otp-keyParam [6] OTPRespKeyParam OPTIONAL + } + + + + OTPFormat ::= INTEGER { + decimal(0), + hexadecimal(1), + alphanumeric(2), + binary(3) + } + + + + PA-ENC-RESPONSE ::= SEQUENCE { + nonce OCTET STRING OPTIONAL, + otp [0] OCTET STRING OPTIONAL + } + + otp-flags + If the "nextOTP" flag is set then the OTP was calculated based on + the next token "state" rather than the current one. This flag + MUST be set if and only if it was set in a corresponding PA-OTP- + CHALLENGE. + + otp-nonce + The nonce value encrypted in the otp-encData. If the PA-OTP- + RESPONSE is sent as a result of a PA-OTP_CHALLENGE then the value + MUST be a copy of the corresponding value in the challenge. If no + challenge was received then the nonce value MUST be generated by + the client. + + + + + + + + +Richards Expires April 14, 2007 [Page 14] + +Internet-Draft OTP Kerberos October 2006 + + + otp-track-id + This element MUST be included if and only if an otp-track-id was + included in the corresponding PA-OTP-CHALLENGE. If included, then + the value MUST be copied from the PA-OTP-CHALLENGE. + + otp-challenge + Value used by the client to send the challenge used in the OTP + calculation. It MUST be sent to the KDC if and only if the value + would otherwise be unknown to the KDC. For example, the token or + client modified or generated challenge. + + otp-time + Value used by the client to send the time used in the OTP + calculation. + + otp-counter + The counter value used in the OTP calculation. Use of this + element is OPTIONAL but it MAY be used by a client to simplify the + OTP calculations of the KDC to contain the counter value as + reported by the OTP token. + + otp-format + The format of the generated OTP. + + otp-keyID + The identifier of the OTP key used. + + otp-keyParam + Information on how the reply key was generated from the OTP and + shared secret. If the value is not present then the reply key was + generated directly from the OTP value. + + otp-encData + The otp-encData field contains the result of the pre- + authentication process and is encrypted using the generated Reply + Key. The fields of this element are populated as follows: + + nonce + The value of otp-nonce. + + otp + The generated OTP value. Present if the "sendOTP" flag is set + in the challenge. + + <> + + + + + +Richards Expires April 14, 2007 [Page 15] + +Internet-Draft OTP Kerberos October 2006 + + +5.3. PA-OTP-CONFIRM + + This is a pre-authentication type returned by the KDC in a KRB_AS_REP + if the client requires a new shared secret value. The value is + encrypted as described in section 5.2.9 of [RFC4120] using the + current reply key as derived by the KDC from the OTP. + + PA-OTP-CONFIRM ::= SEQUENCE { + identifier OCTET STRING, + newSecretValue EncryptedData -- OTPNewSecret + -- Key usage of <> + } + + OTPNewSecret ::= CHOICE { + sharedSecret [0] OCTET STRING, + dhParams [1] DHParam + } + + DHParam ::= SEQUENCE { + dhParameter DHParameter, + dhPublic INTEGER + } + + identifier + An octet string identifying the new secret value. + + newSecretValue + The new secret data encrypted using the current Reply Key. The + encrypted data can be of one of the following types: + + sharedSecret + A random bit string. + + dhParams + A Diffie-Hellman public value, prime and modulus. + +5.4. PA-ENC-PIN + + Pre-authentication type returned by the KDC in a KRB_AS_REP if the + user must change their PIN or if the user's PIN has been changed. + + + + + + + + + + + +Richards Expires April 14, 2007 [Page 16] + +Internet-Draft OTP Kerberos October 2006 + + + PA-ENC-PIN ::= EncryptedData -- PA-ENC-PIN-ENC + -- Key usage of <> + PA-ENC-PIN-ENC ::= SEQUENCE { + flags PinFlags, + pin [0] UTF8String OPTIONAL, + minLength [1] INTEGER OPTIONAL, + maxLength [2] INTEGER OPTIONAL + } + + PinFlags ::= KerberosFlags + -- systemSetPin (0) + + If the "systemSetPin" flag is set then the user's PIN has been + changed and the new PIN value is contained in the pin field. The PIN + field MUST therefore be present. + + If the "systemSetPin" flag is not set then the user's PIN has not + been changed by the server but it MUST instead be changed by the user + using the PIN change service. Restrictions on the size of the PIN + MAY be given by the minLength and maxLength fields. If the pin field + is present then it contains a PIN value that MAY be used by the user + when changing the PIN. The KDC MAY only issue tickets for the PIN + change service until the PIN has been changed. + +5.5. OTPChalKeyParam + + This data type can optionally be included by the KDC in a PA-OTP- + CHALLENGE to instruct the client on how to generate the reply key. + + This value is included in the challenge if the OTP generated by the + token is too weak to be used alone in the generation of the key. + + OTPChalKeyParam ::= SEQUENCE { + flags ChallengeFlags, + identifer [0] OCTET STRING OPTIONAL, + iterationCount [1] INTEGER OPTIONAL + } + + ChallengeFlags ::= KerberosFlags + -- sendOTP (0) + -- noSecret (1) + + flags + Flags controlling the generation of the Reply Key. + + + + + + + +Richards Expires April 14, 2007 [Page 17] + +Internet-Draft OTP Kerberos October 2006 + + + sendOTP + If the "sendOTP" flag is set then the client MUST NOT use the + OTP value to generate the reply key. It must instead use the + generated key to encrypt the OTP value and include the + encrypted value in the PA-OTP-RESPONSE. + + noSecret + If the "noSecret" flag is set then the client MUST NOT use any + stored secret value in the derivation of the Reply Key. If the + "sendOTP" flag is also set then the Kerberos password MUST be + used. If the "sendOTP" flag is not set then the iteration + count MUST be used if it is present or the Kerberos password + MUST be used if the iteration count is not specified. + + identifier + Name of the secret that the client SHOULD use to generate the + reply key. + + If a secret is specified but cannot be located by the client and + an iteration count is specified then the client should generate + the key using the iteration count. If a secret value is specified + and cannot be located and an iteration count is not specified then + the reply key MUST be generated using the user's Kerberos + password. + + iterationCount + This value contains the iteration count to use when the generated + OTP value is used in the derivation of the reply key. This value + is used by the client if a shared secret is not specified or is + specified but cannot be found. The value has no meaning if the + "sendOTP" flag is set. + +5.6. OTPRespKeyParam + + This data type can optionally be included by the client in a PA-OTP- + RESPONSE to inform the KDC of how the reply key was generated. + + OTPRespKeyParam ::= SEQUENCE { + iterationCount [0] INTEGER OPTIONAL, + secret SEQUENCE { + identifier OCTET STRING, + dhPublic [1] INTEGER OPTIONAL + } + } + + + + + + + +Richards Expires April 14, 2007 [Page 18] + +Internet-Draft OTP Kerberos October 2006 + + + iterationCount + The actual value of the iteration count used by the client in the + key derivation. If omitted then no iteration was used in the + derivation of the reply key. + + secret + Information on the secret used in the key derivation. If this + value is omitted then no shared secret was used. + + identifier + An octet string identifying the shared secret value used by the + client in the key derivation. + dhPublic + The client's Diffie-Hellman public key. Present only if a + Diffie-Hellman secret was used. + + +6. IANA Considerations + + A registry may be required for the otp-AlgID values as introduced in + Section 5.1. No other IANA actions are anticipated. + + +7. Security Considerations + +7.1. Active attacks + + <> + +7.2. Denial of service attacks + + An active attacker may replace the iteration count value in the PA- + OTP-RESPONSE sent by the client to slow down an authentication + server. Authentication servers SHOULD protect against this, e.g. by + disregarding PA-OTP-RESPONSE elements with an iteration count value + higher than some pre- or dynamically- (depending on load) set number. + +7.3. Use of a Shared Secret Value + + As described in Section 3.1, the use of a shared secret value will + slow down an attacker's search for a matching OTP. The ability to + transfer such a value in encrypted form from the KDC to the client + means that, even though there may be an initial computational cost + for the KDC to authenticate the user if an iteration count is used, + subsequent authentications will be efficient, while at the same time + more secure, since a pre-shared, value will not be easily found by an + attacker. + + + + +Richards Expires April 14, 2007 [Page 19] + +Internet-Draft OTP Kerberos October 2006 + + + If a client does not have a pre-configured secret value for a KDC + then it will have to generate the Reply Key using an iteration count + or the Kerberos password. If an iteration count is used then an + attacker observing such a KRB_AS_REQ may, depending on available + resources, be able to successfully attack that request. Once the + correct OTP has been found, eavesdropping on the KDC's PA_OTP_CONFIRM + will potentially give the attacker access to the server-provided + secret value. For this reason, initial exchanges with KDC servers + SHOULD occur in a secure environment and the lifetime of this value + must also be calculated with this in mind. Finally, the value MUST + be securely stored by the client and the KDC, associated with the + user. + + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", + RFC 2631, June 1999. + + [RFC3244] Swift, M., Trostle, J., and J. Brezak, "Microsoft Windows + 2000 Kerberos Change Password and Set Password Protocols", + RFC 3244, February 2002. + + [RFC3961] Raeburn, K., "Encryption and Checksum Specifications for + Kerberos 5", RFC 3961, February 2005. + + [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The + Kerberos Network Authentication Service (V5)", RFC 4120, + July 2005. + +8.2. Informative References + + [HoReNeZo04] + Horstein, K., Renard, K., Neuman, C., and G. Zorn, + "Integrating Single-use Authentication Mechanisms with + Kerberos", draft-ietf-krb-wg-kerberos-sam-03 (work in + progress), July 2004. + + + + + + + + + +Richards Expires April 14, 2007 [Page 20] + +Internet-Draft OTP Kerberos October 2006 + + +Author's Address + + Gareth Richards + RSA, The Security Division of EMC + RSA House + Western Road + Bracknell, Berkshire RG12 1RT + UK + + Email: grichards@rsa.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Richards Expires April 14, 2007 [Page 21] + +Internet-Draft OTP Kerberos October 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Acknowledgment + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + +Richards Expires April 14, 2007 [Page 22] + diff --git a/doc/standardisation/draft-sakane-krb-cross-problem-statement-01.txt b/doc/standardisation/draft-sakane-krb-cross-problem-statement-01.txt new file mode 100644 index 000000000..d70f3c9dc --- /dev/null +++ b/doc/standardisation/draft-sakane-krb-cross-problem-statement-01.txt @@ -0,0 +1,731 @@ + + + + + + +INTERNET-DRAFT S. Sakane +Expires: April 29, 2007 Yokogawa Electric Corp. + S. Zrelli + JAIST + M. Ishiyama + Toshiba Corp. + October 26, 2006 + + + Problem statement on the cross-realm operation + of Kerberos in a specific system + draft-sakane-krb-cross-problem-statement-01.txt + + + + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress". + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html + + This Internet-Draft expires in April 29, 2007. + + +Copyright Notice + + Copyright (C) The Internet Society (2006). + + + + + + +S.Sakane, et al. [Page 1] + +Internet-Draft October 2006 + + +Abstract + + There are some issues when the cross-realm operation of the Kerberos + Version 5 [RFC4120] is employed into the specific systems. This + document describes some manners of the real example, and lists + requirements of the operation in such real system. Then it clarifies + issues when we apply the cross-realm operation to such specific + system. + + + +Conventions used in this document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + + It is assumed that the readers are familiar with the terms and + concepts described in the Kerberos Version 5 [RFC4120]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +S.Sakane, et al. [Page 2] + +Internet-Draft October 2006 + + +Table of Contents + + 1. Introduction ................................................. 4 + 2. Kerberos system .............................................. 4 + 2.1. Kerberos basic operation ................................ 4 + 2.2. Cross-realm operation ................................... 5 + 3. Manner of operations in the real environment ................. 6 + 4. Requirement .................................................. 7 + 5. Issues ....................................................... 8 + 5.1. Scalability of the direct trust model ................... 8 + 5.2. Exposure to DoS Attacks ................................. 8 + 5.3. No PFS in case of the indirect trust model .............. 9 + 5.4. Unreliability of authentication chain ................... 9 + 5.5. Client's performance .................................... 9 + 5.6. Pre-authentication problem in roaming scenarios ......... 10 + 6. Implementation consideration ................................. 10 + 7. IANA Considerations .......................................... 11 + 8. Security Considerations ...................................... 11 + 9. Acknowledgments .............................................. 11 + 10. References ................................................... 11 + 10.1. Normative References ................................... 11 + 10.2. Informative References ................................. 11 + Authors' Addresses ............................................... 12 + Full Copyright Statement ......................................... 12 + Intellectual Property Statement .................................. 13 + + + + + + + + + + + + + + + + + + + + + + + + + + +S.Sakane, et al. [Page 3] + +Internet-Draft October 2006 + + +1. Introduction + + The Kerberos Version 5 is a widely deployed mechanism that a server + can authenticate a client access. Each client belongs to a managed + domain called realm. Kerberos supports the authentication in case of + situation that a client and a server belong to different realms. + This is called the cross-realm operation. + + Meanwhile, there are lots of manners of operation in the real system, + where Kerberos could be applied. Sometimes, there are several + managed domain in such system. and it requires the authentication + mechanism over the different managed domains. When the cross-realm + operation of Kerberos is applied to such specific systems, some + issues come out. + + This document briefly describes the Kerberos Version 5 system and the + cross-realm operation. Then, it describes two real systems that can + be applied the Kerberos system, and describes nine requirements of + those systems in term both of management and operation. Finally, it + lists six issues of the cross-realm operation when it is applied to + those system. + + Note that it might not describe whole of issues of the cross-realm + operation. It also does not propose any solution to solve issues + described in this document. In further step, we have to analyze, and + compare candidates of solutions. This work will be in another + document. + + This document is assumed that the readers are familiar with the terms + and concepts described in the Kerberos Version 5 [RFC4120]. + + +2. Kerberos system + + +2.1. Kerberos basic operation + + Kerberos [RFC4120] is a widely deployed authentication system. The + authentication process in Kerberos involves principals and a Key + Distribution Center (KDC). The principals can be users or services. + Each KDC maintains a principals database and shares a secret key with + each registered principal. + + The authentication process allows a user to acquire the needed + credentials from the KDC. These credentials allow services to + authenticate the users before granting them access to the resources. + An important part of the credentials are called Tickets. There are + two kind of tickets: Ticket Granting Ticket (TGT) and Service Ticket. + + + +S.Sakane, et al. [Page 4] + +Internet-Draft October 2006 + + + The TGT is obtained periodically from the KDC and has a limited limit + after which it expires and the user must renew it. The TGT is used + to obtain the other kind of tickets, Service Tickets. The user + obtains a TGT from the Authentication Service (AS), a logical + component of the KDC. The process of obtaining a TGT is referred to + as 'AS exchange'. When a TGT request is issued by an user, the AS + responds by sending a reply packet containing the credentials which + consists of the TGT along with a random key called 'TGS Session Key'. + The TGT contains a set of information encrypted using a secret key + associated with a special service referred to as TGS (Ticket Granting + Service). The TGS session key is encrypted using the user's key so + that the user can obtain the TGS session key only if she knows the + secret key shared with the KDC. The TGT then is used to obtain + Service Tickets from the Ticket Granting Service (TGS)- the second + component of the KDC. The process of obtaining service tickets is + referred to as 'TGS exchange'. The request for a service ticket + consists on a packet containing a TGT and an 'Authenticator'. The + Authenticator is encrypted using the TGS session key and contains the + identity of the user as well as time stamps (for protection against + replay attacks). After decrypting the TGT (which was encrypted by + the AS using the TGS's secret key), the TGS extracts the TGS session + key. Using that session key, it decrypts the Authenticator and + authenticates the user. Then, the TGS issues credentials requested + by the user. These credentials consist on a service ticket and a + session key that will be used to authenticate the user with the + desired application service. + + +2.2. Cross-realm operation + + The Kerberos protocol provides the cross-realm authentication + capabilities. This allows users to obtain service tickets to access + services in foreign realms. In order to access such services, the + users first contact their home KDC asking for a TGT that will be used + with the TGS of the foreign realm. If the home realm and the foreign + realm share keys and have an established trust relationship, the home + KDC delivers the requested TGT. + + However, if the home realm does not share cross-realm keys with the + foreign realm, the home KDC will provide a TGT that can be used with + an intermediary foreign realm that is likely to be sharing cross- + realm keys with the target realm. The client can use this + 'intermediary TGT' to communicate with the intermediary KDC which + will iterate the actions taken by the home KDC: If the intermediary + KDC does not share cross-realm keys with the target foreign realm it + will point the user to another intermediary KDC (just as in the first + exchange between the user and its home KDC). However, in the other + case (when it shares cross- realm keys with the target realm), the + + + +S.Sakane, et al. [Page 5] + +Internet-Draft October 2006 + + + intermediary KDC will issue a TGT that can be used with the KDC of + the target realm. After obtaining a TGT for the desired foreign + realm, the client uses it to obtain service tickets from the TGS of + the foreign realm. Finally, the user access the service using the + service ticket. + + When the realms belong to the same institution, a chain of trust can + be determined by the client or the KDC by following the DNS domain + hierarchy and supposing that the parent domains share keys with all + its child sub-domains. However, because the inter-realm trust model + is not necessarily constructing the hierarchic approach anytime, the + trust path must be specified manually. When intermediary realms are + involved, the success of the cross-realm operation completely depends + on the realms that are part of the authentication path. + + +3. Manner of operations in the real environment + + This section describes examples of operation in the real environment. + And it also describes its requirement in term of both management and + operation. These requirements make the issues easier understanding. + We refers to the world's largest petrochemical company [SHELLCHEM]. + It produces bulk petrochemicals and their delivery to large + industrial customers. There are 43 typical plants of the company all + over the world. They are managed by the operation sites placed in 35 + countries. This section shows two examples of them. + + One is the CSPC (CNOOC and Shell Petrochemical Company Limited) + [CSPC], an example of the centralized plant. The CSPC is a joint + enterprise of CNOOC and SHELL. Its plant is one of the hugest + systems of a petrochemical industry placed in the area of 3.4 square + meters in the north coast of Daya Bay, Guangdong, which is at the + southeast of China. 3,000 network segments are established in the + system. 16,000 control devices are connected to the local area + network. These devices belong to different 9 sub systems, A control + device has some control points, which are controlled and monitored by + other devices remotely. There are 200,000 control points in all. + They are controlled by 3 different control center. + + Another is the NAM (Nederlandse Aardolie Maatschappij), an example of + the distributed plant system. The NAM is a partnership enterprise of + Shell and Exxon. It is a plant system group that geographically + distributes to scatter in the area of 863 square meters of + Netherlands. 26 plants, each is named "cluster", are scattered in + the area. They are connected each other by a private ATM WAN. Each + cluster has approximately 500-1,000 control devices. These devices + are managed by each local control center in each cluster. In the + entire system of the NAM, there are one million control points. + + + +S.Sakane, et al. [Page 6] + +Internet-Draft October 2006 + + + The end control devices in the both of the systems are basically + connected to a local network by a twisted pair cable, which is a low + band-width of 32 kbps. Every system supposes that no ad-hoc device + is never connected to the system since they are well designed before + they are implemented. Low clock CPU, for example H8 [RNSS-H8] and + M16C [RNSS-M16C], are employed by many control devices. Furthermore, + to suppress power consumption, these CPU may be lowered the number of + clocks. A controller in this system collects condition of device + from multiple control devices, and the system uses them to make a + decision how to control devices. If it took time for data to reach, + they could not be associated. The travel time of data from the + device to the controller is demanded within 1 second. A part of the + operation, like control of these system, maintenance, and the + environmental monitoring, is consigned to an external organization. + Agents who are consigned walk around the plant to get their + information, or watch the plant from a remote site. Currently, each + plant is independently operated. However, it is not impossible to + monitor and control all of plants distributed in the world. + + +4. Requirement + + This section listed requirements derived from the previous section. + There are seven requirements in term of management domain separation. + + A-1 It is necessary to allow different independent management + domains to coexist because two or more organizations enter to + the system. + + A-2 It is necessary to allow a management domain to delegate its + management authority to its sub domains or another management + domain because the plants are distributed to the wide area. + + A-3 It is necessary that a device controls other devices that belong + to a same domain from remote because the plants are distributed + to the wide area. + + A-4 It is necessary that a device controls other devices that belong + to a different domain from local. + + A-5 It is necessary that a device controls other devices that belong + to a different domain from remote. + + A-6 It is necessary for the agents who are consigned to watch and + control the device at the plant, which is different domain from + the agents' one. + + Because of above requirements, the cross-realm operation of Kerberos + + + +S.Sakane, et al. [Page 7] + +Internet-Draft October 2006 + + + seems suitable for this system. The requirements derived from other + viewpoints is listed as follows. + + B-1 It is demanded to reduce the management cost as much as + possible. + + B-2 The communication for observing and controlling devices must + have confidentiality and integrity. And, it is necessary to + think about the threat of other security like the DoS attack. + + B-3 It is necessary to consider the processing performance of the + device. And, it is necessary to suppress the power consumption + of the device. + + B-4 It is necessary to consider bandwidth of the communication. + + +5. Issues + + This section lists the issues in the cross-realm operation when we + consider the above requirements. + + +5.1. Scalability of the direct trust model + + In the direct relationship of trust between each realm, the realms + involved in the cross-realm operation share keys and their respective + TGS principals are registered in each other's KDC. When direct trust + relationships are used, the KDC of each realm must maintain keys with + all foreign realms. This can become a cumbersome task when the + number of realms increase. This also increases maintenance cost. + + This issue will happen as a by-product of a result meeting the + requirements A-1 and A-2, and is related to B-1. + + +5.2. Exposure to DoS Attacks + + One of the assumption made when allowing the cross-realm operation in + Kerberos is that users can communicate with KDCs located in remote + realms. This practice introduces security threats because KDCs are + open to the public network. Administrators may think of restricting + the access to the KDC to the trusted realms only. However, this + approach is not scalable and does not really protect the KDC. + Indeed, when the remote realms have several IP prefixes (e.g. control + centers or outsourcing companies, located world wide), then the + administrator of the local KDC must collect the list of prefixes that + belong to these organization. The filtering rules must then + + + +S.Sakane, et al. [Page 8] + +Internet-Draft October 2006 + + + explicitly allow the incoming traffic from any host that belongs to + one of these prefixes. This makes the administrator's tasks more + complicated and prone to human errors. And also, the maintenance + cost increases. On the other hand, when ranges of external IP + addresses are allowed to communicate with the KDC, the risk of + becoming target to attacks from remote malicious users increases. + + This issue will happen as a result meeting the requirements A-3, A-4 + and A-5. And it is related to B-1 and B-2. + + +5.3. No PFS in case of the indirect trust model + + In [SPECCROSS], any KDC in the authentication path can learn the + session key that will be used between the client and the desired + service. This means that any intermediary realm is able to spoof the + identity either of the service or the client as well as to eavesdrop + on the communication between the client and the server. + + This issue will happen as a by-product of a result meeting the + requirements A-1 and A-2, and is related to B-2. + + +5.4. Unreliability of authentication chain + + When the relationship of trust is constructed like a chain or + hierarchical, the authentication path is not dependable since it + strongly depends on intermediary realms that might not be under the + same authority. If any of the realms in the authentication path is + not available, then the principals of the end-realms can not perform + the cross-realm operation. + + The end-point realms do not have full control and responsibility of + the success of the operations even if their respective KDCs are fully + functional. Dependability of a system decreases if the system relies + on uncontrolled components. We can not be sure at 100% about the + result of the authentication since we do not know how is it going in + intermediary realms. + + This issue will happen as a by-product of a result meeting the + requirements A-1 and A-2, and is related to B-2. + + +5.5. Client's performance + + In the cross-realm operation, Kerberos clients have to perform TGS + exchanges with all the KDCs in the trust path, including the home KDC + and the target KDC. TGS exchange requires cryptographic operations. + + + +S.Sakane, et al. [Page 9] + +Internet-Draft October 2006 + + + This exchange demands important processing time especially when the + client has limited computational capabilities. The overhead of these + cross-realm exchanges grows into unacceptable delays. + + We ported the MIT Kerberos library (version 1.2.4), implemented a + Kerberos client on our original board with H8 (16-bit, 20MHz), and + measured the process time of each Kerberos message. It takes 195 + milliseconds to perform a TGS exchange with the on-board H/W crypto + engine. Indeed, this result seems reasonable to the requirement of + the response time for the control network. However, we did not + modify the clock speed of the H8 during our measurement. The + processing time must be slower in a real environment because H8 is + used with lowered clock speed in such system. Also, the delays can + grow to unacceptable delays when the number of intermediary realms + increases. + + This issue will happen as a by-product of a result meeting the + requirements A-1 and A-2, and is related to B-3. + + +5.6. Pre-authentication problem in roaming scenarios + + In roaming scenarios, the client needs to contact her home KDC to + obtain a cross-realm TGT for the local (or visited) realm. However, + the policy of the network access providers or the gateway in the + local network usually does not allow clients to communicate with + hosts in the Internet unless they provide valid authentication + credentials. In this manner, the client encounters a chicken-and-egg + problem where two resources are interdependent; the Internet + connection is needed to contact the home KDC and for obtaining + credentials, and on the other hand, the Internet connection is only + granted for clients who have valid credentials. As a result, the + Kerberos protocol can not be used as it is for authenticating roaming + clients requesting network access. + + This issue will happen as a result meeting the requirements A-6. + + +6. Implementation consideration + + This document just describes issues of the cross-realm operation in + the specific systems. However, there are important matters to be + considered, when we solve these issues and implement solution. + Solution must not introduce new problem. Solution should use + existing components or protocols as much as possible, should not + introduce any definition of new component. Solution must not require + a KDC to have any additional process. You must not forget that there + would be a trade-off matter anytime. So an implementation may not + + + +S.Sakane, et al. [Page 10] + +Internet-Draft October 2006 + + + solve all of the problems stated in this document. + + +7. IANA Considerations + + This document makes no request of IANA. + + +8. Security Considerations + + This document just clarifies some issues of the cross-realm operation + of the Kerberos V system. There is especially not describing + security. Some troubles might be caused to your system by malicious + user who misuses the description of this document if it dares to say. + + +9. Acknowledgments + + The authors are very grateful to Nobuo Okabe, Kazunori Miyazawa, + Ken'ichi Kamada and Atsushi Inoue. They gave us lots of comments and + input for this document. + + +10. References + + +10.1. Normative References + + [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The + Kerberos Network Authentication Service (V5)", RFC + 4120, July 2005. + + +10.2. Informative References + + [CSPC] http://www.shellchemicals.com/news/1,1098,72-news_id= + 531,00.html + + [RNSS-H8] http://www.renesas.com/fmwk.jsp?cnt=h8_family_landing. + jsp&fp=/products/mpumcu/h8_family/ + + [RNSS-M16C] http://www.renesas.com/fmwk.jsp?cnt=m16c_family_landi + ng.jsp&fp=/products/mpumcu/m16c_family/ + + [RFC2119] S.Bradner, "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119, March 1997. + + + + + +S.Sakane, et al. [Page 11] + +Internet-Draft October 2006 + + + [SHELLCHEM] http://www.shellchemicals.com/home/1,1098,-1,00.html + + [SPECCROSS] I. Cervesato and A. Jaggard and A. Scedrov and C. + Walstad, "Specifying Kerberos 5 Cross-Realm + Authentication", Fifth Workshop on Issues in the Theory + of Security, Jan 2005. + +Authors' Addresses + + Shoichi Sakane + Yokogawa Electric Corporation + 2-9-32 Nakacho, Musashino-shi, + Tokyo 180-8750 Japan + E-mail: Shouichi.Sakane@jp.yokogawa.com, + + + Saber Zrelli + Japan Advanced Institute of Science and Technology + 1-1 Asahidai, Nomi, + Ishikawa 923-1292 Japan + E-mail: zrelli@jaist.ac.jp + + + Masahiro Ishiyama + Toshiba Corporation + 1, komukai-toshiba-cho, Saiwai-ku, + Kawasaki 212-8582 Japan + E-mail: masahiro@isl.rdc.toshiba.co.jp + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + +S.Sakane, et al. [Page 12] + +Internet-Draft October 2006 + + +Intellectual Property Statement + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +S.Sakane, et al. [Page 13] +