From 955fa37d001ae66e96f7f14b67697fbb8566979f Mon Sep 17 00:00:00 2001 From: Simon Josefsson Date: Wed, 7 Mar 2007 21:29:08 +0000 Subject: [PATCH] Add. --- .../draft-ietf-krb-wg-kerberos-referrals-09.txt | 896 +++ .../draft-ietf-krb-wg-kerberos-set-passwd-06.txt | 1233 ++++ doc/specifications/draft-ietf-krb-wg-naming-03.txt | 392 ++ .../draft-ietf-krb-wg-pkinit-alg-agility-02.txt | 807 +++ .../draft-ietf-krb-wg-preauth-framework-05.txt | 1938 ++++++ .../draft-ietf-krb-wg-rfc1510ter-04.txt | 6385 ++++++++++++++++++++ 6 files changed, 11651 insertions(+) create mode 100644 doc/specifications/draft-ietf-krb-wg-kerberos-referrals-09.txt create mode 100644 doc/specifications/draft-ietf-krb-wg-kerberos-set-passwd-06.txt create mode 100644 doc/specifications/draft-ietf-krb-wg-naming-03.txt create mode 100644 doc/specifications/draft-ietf-krb-wg-pkinit-alg-agility-02.txt create mode 100644 doc/specifications/draft-ietf-krb-wg-preauth-framework-05.txt create mode 100644 doc/specifications/draft-ietf-krb-wg-rfc1510ter-04.txt diff --git a/doc/specifications/draft-ietf-krb-wg-kerberos-referrals-09.txt b/doc/specifications/draft-ietf-krb-wg-kerberos-referrals-09.txt new file mode 100644 index 00000000..24e3ace2 --- /dev/null +++ b/doc/specifications/draft-ietf-krb-wg-kerberos-referrals-09.txt @@ -0,0 +1,896 @@ + + + +NETWORK WORKING GROUP K. Raeburn +Internet-Draft MIT +Updates: 4120 (if approved) L. Zhu +Intended status: Standards Track Microsoft Corporation +Expires: September 6, 2007 March 5, 2007 + + + Generating KDC Referrals to Locate Kerberos Realms + draft-ietf-krb-wg-kerberos-referrals-09 + +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 September 6, 2007. + +Copyright Notice + + Copyright (C) The IETF Trust (2007). + +Abstract + + The memo documents a method for a Kerberos Key Distribution Center + (KDC) to respond to client requests for Kerberos tickets when the + client does not have detailed configuration information on the realms + of users or services. The KDC will handle requests for principals in + other realms by returning either a referral error or a cross-realm + TGT to another realm on the referral path. The clients will use this + referral information to reach the realm of the target principal and + + + +Raeburn & Zhu Expires September 6, 2007 [Page 1] + +Internet-Draft KDC Referrals March 2007 + + + then receive the ticket. + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 + 3. Requesting a Referral . . . . . . . . . . . . . . . . . . . . 4 + 4. Realm Organization Model . . . . . . . . . . . . . . . . . . . 5 + 5. Client Name Canonicalization . . . . . . . . . . . . . . . . . 5 + 6. Client Referrals . . . . . . . . . . . . . . . . . . . . . . . 7 + 7. Server Referrals . . . . . . . . . . . . . . . . . . . . . . . 8 + 8. Server Name Canonicalization (Informative) . . . . . . . . . . 10 + 9. Cross Realm Routing . . . . . . . . . . . . . . . . . . . . . 10 + 10. Caching Information . . . . . . . . . . . . . . . . . . . . . 11 + 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 12. Security Considerations . . . . . . . . . . . . . . . . . . . 12 + 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 + 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 14.1. Normative References . . . . . . . . . . . . . . . . . . 12 + 14.2. Informative References . . . . . . . . . . . . . . . . . 12 + Appendix A. Compatibility with Earlier Implementations of + Name Canonicalization . . . . . . . . . . . . . . . . 13 + Appendix B. Document history . . . . . . . . . . . . . . . . . . 14 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 + Intellectual Property and Copyright Statements . . . . . . . . . . 16 + + + + + + + + + + + + + + + + + + + + + + + + + +Raeburn & Zhu Expires September 6, 2007 [Page 2] + +Internet-Draft KDC Referrals March 2007 + + +1. Introduction + + Current implementations of the Kerberos AS and TGS protocols, as + defined in [RFC4120], use principal names constructed from a known + user or service name and realm. A service name is typically + constructed from a name of the service and the DNS host name of the + computer that is providing the service. Many existing deployments of + Kerberos use a single Kerberos realm where all users and services + would be using the same realm. However in an environment where there + are multiple trusted Kerberos realms, the client needs to be able to + determine what realm a particular user or service is in before making + an AS or TGS request. Traditionally this requires client + configuration to make this possible. + + When having to deal with multiple trusted realms, users are forced to + know what realm they are in before they can obtain a ticket granting + ticket (TGT) with an AS request. However, in many cases the user + would like to use a more familiar name that is not directly related + to the realm of their Kerberos principal name. A good example of + this is an RFC 822 style email name. This document describes a + mechanism that would allow a user to specify a user principal name + that is an alias for the user's Kerberos principal name. In practice + this would be the name that the user specifies to obtain a TGT from a + Kerberos KDC. The user principal name no longer has a direct + relationship with the Kerberos principal or realm. Thus the + administrator is able to move the user's principal to other realms + without the user having to know that it happened. + + Once a user has a TGT, they would like to be able to access services + in any trusted Kerberos realm. To do this requires that the client + be able to determine what realm the target service principal is in + before making the TGS request. Current implementations of Kerberos + typically have a table that maps DNS host names to corresponding + Kerberos realms. The user-supplied host name or its domain component + is looked up in this table (often using the result of some form of + host name lookup performed with insecure DNS queries, in violation of + [RFC4120]). The corresponding realm is then used to complete the + target service principal name. + + This traditional mechanism requires that each client have very + detailed configuration information about the hosts that are providing + services and their corresponding realms. Having client side + configuration information can be very costly from an administration + point of view - especially if there are many realms and computers in + the environment. + + There are also cases where specific DNS aliases (local names) have + been setup in an organization to refer to a server in another + + + +Raeburn & Zhu Expires September 6, 2007 [Page 3] + +Internet-Draft KDC Referrals March 2007 + + + organization (remote server). The server has different DNS names in + each organization and each organization has a Kerberos realm that is + configured to service DNS names within that organization. Ideally + users are able to authenticate to the server in the other + organization using the local server name. This would mean that the + local realm be able to produce a ticket to the remote server under + its name. The administrator in the local realm could give that + remote server an identity in the local realm and then have that + remote server maintain a separate secret for each alias it is known + as. Alternatively the administrator could arrange to have the local + realm issue a referral to the remote realm and notify the requesting + client of the server's remote name that should be used in order to + request a ticket. + + This memo proposes a solution for these problems and simplifies + administration by minimizing the configuration information needed on + each computer using Kerberos. Specifically it describes a mechanism + to allow the KDC to handle canonicalization of names, provide for + principal aliases for users and services and allow the KDC to + determine the trusted realm authentication path by being able to + generate referrals to other realms in order to locate principals. + + Two kinds of KDC referrals are introduced in this memo: + + 1. Client referrals, in which the client doesn't know which realm + contains a user account. + 2. Server referrals, in which the client doesn't know which realm + contains a server account. + + +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]. + + +3. Requesting a Referral + + In order to request referrals defined in section 5, 6, and 7, the + Kerberos client MUST explicitly request the canonicalize KDC option + (bit 15) [RFC4120] for the AS-REQ or TGS-REQ. This flag indicates to + the KDC that the client is prepared to receive a reply that contains + a principal name other than the one requested. + + + KDCOptions ::= KerberosFlags + -- canonicalize (15) + + + +Raeburn & Zhu Expires September 6, 2007 [Page 4] + +Internet-Draft KDC Referrals March 2007 + + + -- other KDCOptions values omitted + + The client should expect, when sending names with the "canonicalize" + KDC option, that names in the KDC's reply MAY be different than the + name in the request. A referral TGT is a cross realm TGT that is + returned with the server name of the ticket being different from the + server name in the request [RFC4120]. + + +4. Realm Organization Model + + This memo assumes that the world of principals is arranged on + multiple levels: the realm, the enterprise, and the world. A KDC may + issue tickets for any principal in its realm or cross-realm tickets + for realms with which it has a direct trust relationship. The KDC + also has access to a trusted name service that can resolve any name + from within its enterprise into a realm. This trusted name service + removes the need to use an un-trusted DNS lookup for name resolution. + + For example, consider the following configuration, where lines + indicate trust relationships: + + EXAMPLE.COM + / \ + / \ + ADMIN.EXAMPLE.COM DEV.EXAMPLE.COM + + In this configuration, all users in the EXAMPLE.COM enterprise could + have principal names such as alice@EXAMPLE.COM, with the same realm + portion. In addition, servers at EXAMPLE.COM should be able to have + DNS host names from any DNS domain independent of what Kerberos realm + their principals reside in. + + +5. Client Name Canonicalization + + A client account may have multiple principal names. More useful, + though, is a globally unique name that allows unification of email + and security principal names. For example, all users at EXAMPLE.COM + may have a client principal name of the form "joe@EXAMPLE.COM" even + though the principals are contained in multiple realms. This global + name is again an alias for the true client principal name, which + indicates what realm contains the principal. Thus, accounts "alice" + in the realm DEV.EXAMPLE.COM and "bob" in ADMIN.EXAMPLE.COM may log + on as "alice@EXAMPLE.COM" and "bob@EXAMPLE.COM". + + This utilizes a new client principal name type, as the AS-REQ message + only contains a single realm field, and the realm portion of this + + + +Raeburn & Zhu Expires September 6, 2007 [Page 5] + +Internet-Draft KDC Referrals March 2007 + + + name corresponds to the Kerberos realm with which the request is + made. Thus, the entire name "alice@EXAMPLE.COM" is transmitted as a + single component in the client name field of the AS-REQ message, with + a name type of NT-ENTERPRISE [RFC4120] (and the local realm name). + The KDC will recognize this name type and then transform the + requested name into the true principal name if the client account + resides in the local realm. The true principal name can have a name + type different from the requested name type. Typically the true + principal name will be a NT-PRINCIPAL [RFC4120]. + + If the "canonicalize" KDC option is set, then the KDC MAY change the + client principal name and type in the AS response and ticket returned + from the name type of the client name in the request, and include a + mandatory PA-DATA object authenticating the client name mapping: + + ReferralInfo ::= SEQUENCE { + requested-name [0] PrincipalName, + mapped-name [1] PrincipalName, + ... + } + PA-CLIENT-CANONICALIZED ::= SEQUENCE { + names [0] ReferralInfo, + canon-checksum [1] Checksum + } + + The canon-checksum field is computed over the DER encoding of the + names sequences, using the AS reply key and a key usage value of + (TBD). + + If the client name is unchanged, the PA-CLIENT-CANONICALIZED data is + not included. If the client name is changed, and the PA-CLIENT- + CANONICALIZED field does not exist, or the checksum cannot be + verified, or the requested-name field doesn't match the client name + in the originally-transmitted request, the client should discard the + response. + + For example the AS request may specify a client name of "bob@ + EXAMPLE.COM" as an NT-ENTERPRISE name with the "canonicalize" KDC + option set and the KDC will return with a client name of "104567" as + a NT-UID, and a PA-CLIENT-CANONICALIZED field listing the NT- + ENTERPRISE "bob@EXAMPLE.COM" principal as the requested-name and the + NT-UID "104567" principal as the mapped-name. + + (It is assumed that the client discovers whether the KDC supports the + NT-ENTERPRISE name type via out of band mechanisms.) + + In order to enable one party in a user-to-user exchange to confirm + the identity of another when only the alias is known, the KDC MAY + + + +Raeburn & Zhu Expires September 6, 2007 [Page 6] + +Internet-Draft KDC Referrals March 2007 + + + include the following authorization data element, wrapped in AD-KDC- + ISSUED, in the initial credentials and copy it from a ticket-granting + ticket into additional credentials: + + AD-LOGIN-ALIAS ::= SEQUENCE { -- ad-type number TBD -- + login-aliases [0] SEQUENCE(1..MAX) OF PrincipalName, + } + + The login-aliases field lists one or more of the aliases the + principal may have used in the initial ticket request. + + The recipient of this authenticator must check the AD-LOGIN-ALIAS + names, if present, in addition to the normal client name field, + against the identity of the party with which it wishes to + authenticate; either should be allowed to match. (Note that this is + not backwards compatible with [RFC4120]; if the server side of the + user-to-user exchange does not support this extension, and does not + know the true principal name, authentication may fail if the alias is + sought in the client name field.) + + +6. Client Referrals + + The simplest form of ticket referral is for a user requesting a + ticket using an AS-REQ. In this case, the client machine will send + the AS-REQ to a convenient trusted realm, for example the realm of + the client machine. In the case of the name alice@EXAMPLE.COM, the + client MAY optimistically choose to send the request to EXAMPLE.COM. + The realm in the AS-REQ is always the name of the realm that the + request is for as specified in [RFC4120]. + + The KDC will try to lookup the name in its local account database. + If the account is present in the realm of the request, it SHOULD + return a KDC reply structure with the appropriate ticket. + + If the account is not present in the realm specified in the request + and the "canonicalize" KDC option is set, the KDC will try to lookup + the entire name, alice@EXAMPLE.COM, using a name service. If this + lookup is unsuccessful, it MUST return the error + KDC_ERR_C_PRINCIPAL_UNKNOWN [RFC4120]. If the lookup is successful, + it MUST return an error KDC_ERR_WRONG_REALM [RFC4120] and in the + error message the crealm field will contain either the true realm of + the client or another realm that MAY have better information about + the client's true realm. The client SHALL NOT use a cname returned + from a Kerberos error until that name is validated. + + If the client receives a KDC_ERR_WRONG_REALM error, it will issue a + new AS request with the same client principal name used to generate + + + +Raeburn & Zhu Expires September 6, 2007 [Page 7] + +Internet-Draft KDC Referrals March 2007 + + + the first referral to the realm specified by the realm field of the + Kerberos error message corresponding to the first request. (The + client realm name will be updated in the new request to refer to this + new realm.) The client SHOULD repeat these steps until it finds the + true realm of the client. To avoid infinite referral loops, an + implementation should limit the number of referrals. A suggested + limit is 5 referrals before giving up. + + Since the same client name is sent to the referring and referred-to + realms, both realms must recognize the same client names. In + particular, the referring realm cannot (usefully) define principal + name aliases that the referred-to realm will not know. + + The true principal name of the client, returned in AS-REQ, can be + validated in a subsequent TGS message exchange where its value is + communicated back to the KDC via the authenticator in the PA-TGS-REQ + padata [RFC4120]. + + +7. Server Referrals + + The primary difference in server referrals is that the KDC MUST + return a referral TGT rather than an error message as is done in the + client referrals. There needs to be a place to include in the reply + information about what realm contains the server. This is done by + returning information about the server name in the pre-authentication + data field of the KDC reply [RFC4120], as specified later in this + section. + + If the KDC resolves the server principal name into a principal in the + realm specified by the service realm name, it will return a normal + ticket. + + If the "canonicalize" flag in the KDC options is not set, the KDC + MUST only look up the name as a normal principal name in the + specified server realm. If the "canonicalize" flag in the KDC + options is set and the KDC doesn't find the principal locally, the + KDC MAY return a cross-realm ticket granting ticket to the next hop + on the trust path towards a realm that may be able to resolve the + principal name. The true principal name of the server SHALL be + returned in the padata of the reply if it is different from what is + specified the request. + + When a referral TGT is returned, the KDC MUST return the target realm + for the referral TGT as an KDC supplied pre-authentication data + element in the response. This referral information in pre- + authentication data MUST be encrypted using the session key from the + reply ticket. The key usage value for the encryption operation used + + + +Raeburn & Zhu Expires September 6, 2007 [Page 8] + +Internet-Draft KDC Referrals March 2007 + + + by PA-SERVER-REFERRAL is 26. + + The pre-authentication data returned by the KDC, which contains the + referred realm and the true principal name of server, is encoded in + DER as follows. + + PA-SERVER-REFERRAL 25 + + PA-SERVER-REFERRAL-DATA ::= EncryptedData + -- ServerReferralData -- + + ServerReferralData ::= SEQUENCE { + referred-realm [0] Realm OPTIONAL, + -- target realm of the referral TGT + true-principal-name [1] PrincipalName OPTIONAL, + -- true server principal name + requested-principal-name [2] PrincipalName OPTIONAL, + -- requested server name + ... + } + + Clients SHALL NOT accept a reply ticket, whose the server principal + name is different from that of the request, if the KDC response does + not contain a PA-SERVER-REFERRAL padata entry. + + The requested-principal-name MUST be included by the KDC, and MUST be + verified by the client, if the client sent an AS-REQ, as protection + against a man-in-the-middle modification to the AS-REQ message. + + The referred-realm field is present if and only if the returned + ticket is a referral TGT, not a service ticket for the requested + server principal. + + When a referral TGT is returned and the true-principal-name field is + present, the client MUST use that name in the subsequent requests to + the server realm when following the referral. + + Client SHALL NOT accept a true server principal name for a service + ticket if the true-principal-name field is not present in the PA- + SERVER-REFERRAL data. + + The client will use this referral information to request a chain of + cross-realm ticket granting tickets until it reaches the realm of the + server, and can then expect to receive a valid service ticket. + + However an implementation should limit the number of referrals that + it processes to avoid infinite referral loops. A suggested limit is + 5 referrals before giving up. + + + +Raeburn & Zhu Expires September 6, 2007 [Page 9] + +Internet-Draft KDC Referrals March 2007 + + + Here is an example of a client requesting a service ticket for a + service in realm DEV.EXAMPLE.COM where the client is in + ADMIN.EXAMPLE.COM. + + +NC = Canonicalize KDCOption set + +PA-REFERRAL = returned PA-SERVER-REFERRAL + C: TGS-REQ sname=http/foo.dev.example.com +NC to ADMIN.EXAMPLE.COM + S: TGS-REP sname=krbtgt/EXAMPLE.COM@ADMIN.EXAMPLE.COM +PA-REFERRAL + containing EXAMPLE.COM as the referred realm with no + true-principal-name + C: TGS-REQ sname=http/foo.dev.example.com +NC to EXAMPLE.COM + S: TGS-REP sname=krbtgt/DEV.EXAMPLE.COM@EXAMPLE.COM +PA-REFERRAL + containing DEV.EXAMPLE.COM as the referred realm with no + true-principal-name + C: TGS-REQ sname=http/foo.dev.example.com +NC to DEV.EXAMPLE.COM + S: TGS-REP sname=http/foo.dev.example.com@DEV.EXAMPLE.COM + + Note that any referral or alias processing of the server name in + user-to-user authentication should use the same data as client name + canonicalization or referral. Otherwise, the name used by one user + to log in may not be useable by another for user-to-user + authentication to the first. + + +8. Server Name Canonicalization (Informative) + + No attempt is being made in this document to provide a means for + dealing with local-realm server principal name canonicalization or + aliasing. The most obvious use case for this would be a hostname- + based service principal name ("host/foobar.example.com"), with a DNS + alias ("foo") for the server host which is used by the client. There + are other ways this can be handled, currently, though they may + require additional configuration on the application server or KDC or + both. + + +9. Cross Realm Routing + + The current Kerberos protocol requires the client to explicitly + request a cross-realm TGT for each pair of realms on a referral + chain. As a result, the client need to be aware of the trust + hierarchy and of any short-cut trusts (those that aren't parent- + child trusts). + + Instead, using the server referral routing mechanism as defined in + Section 7, The KDC will determine the best path for the client and + return a cross-realm TGT as the referral TGT, and the target realm + for this TGT in the PA-SERVER-REFERRAL of the KDC reply. + + + +Raeburn & Zhu Expires September 6, 2007 [Page 10] + +Internet-Draft KDC Referrals March 2007 + + + If the "canonicalize" KDC option is not set, the KDC SHALL NOT return + a referral TGT. Clients SHALL NOT process referral TGTs if the KDC + response does not contain the PA-SERVER-REFERRAL padata. + + +10. Caching Information + + It is possible that the client may wish to get additional credentials + for the same service principal, perhaps with different authorization- + data restrictions or other changed attributes. The return of a + server referral from a KDC can be taken as an indication that the + requested principal does not currently exist in the local realm. + Clearly, it would reduce network traffic if the clients could cache + that information and use it when acquiring the second set of + credentials for a service, rather than always having to re-check with + the local KDC to see if the name has been created locally. + + Rather than introduce a new timeout field for this cached + information, we can use the lifetime of the returned TGT in this + case. When the TGT expires, the previously returned referral from + the local KDC should be considered invalid, and the local KDC must be + asked again for information for the desired service principal name. + (Note that the client may get back multiple referral TGTs from the + local KDC to the same remote realm, with different lifetimes. The + lifetime information must be properly associated with the requested + service principal names. Simply having another TGT for the same + remote realm does not extend the validity of previously acquired + information about one service principal name.) If the client is + still in contact with the service and needs to reauthenticate to the + same service regardless of local service principal name assignments, + it should use the referred-realm and true-principal-name values when + requesting new credentials. + + Accordingly, KDC authors and maintainers should consider what factors + (e.g., DNS alias lifetimes) they may or may not wish to incorporate + into credential expiration times in cases of referrals. + + +11. Open Issues + + When should client name aliases be included in credentials? + + Should all known client name aliases be included, or only the one + used at initial ticket acquisition? + + We still don't discuss what "validation" of the returned information + means. + + + + +Raeburn & Zhu Expires September 6, 2007 [Page 11] + +Internet-Draft KDC Referrals March 2007 + + +12. Security Considerations + + For the AS exchange case, it is important that the logon mechanism + not trust a name that has not been used to authenticate the user. + For example, the name that the user enters as part of a logon + exchange may not be the name that the user authenticates as, given + that the KDC_ERR_WRONG_REALM error may have been returned. The + relevant Kerberos naming information for logon (if any), is the + client name and client realm in the service ticket targeted at the + workstation that was obtained using the user's initial TGT. + + How the client name and client realm is mapped into a local account + for logon is a local matter, but the client logon mechanism MUST use + additional information such as the client realm and/or authorization + attributes from the service ticket presented to the workstation by + the user, when mapping the logon credentials to a local account on + the workstation. + + +13. Acknowledgments + + Sam Hartman and authors came up with the idea of using the ticket key + to encrypt the referral data, which prevents cut and paste attack + using the referral data and referral TGTs. + + John Brezak, Mike Swift, and Jonathan Trostle wrote the initial + version of this document. + + Karthik Jaganathan contributed to earlier versions. + + +14. References + +14.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The + Kerberos Network Authentication Service (V5)", RFC 4120, + July 2005. + +14.2. Informative References + + [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet + X.509 Public Key Infrastructure Certificate and + Certificate Revocation List (CRL) Profile", RFC 3280, + April 2002. + + + +Raeburn & Zhu Expires September 6, 2007 [Page 12] + +Internet-Draft KDC Referrals March 2007 + + + [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial + Authentication in Kerberos (PKINIT)", RFC 4556, June 2006. + + [XPR] Trostle, J., Kosinovsky, I., and M. Swift, "Implementation + of Crossrealm Referral Handling in the MIT Kerberos + Client", Network and Distributed System Security + Symposium, February 2001. + + +Appendix A. Compatibility with Earlier Implementations of Name + Canonicalization + + (Remove this section when Microsoft publishes this information in a + separate document.) + + The Microsoft Windows 2000 and Windows 2003 releases included an + earlier form of name-canonicalization [XPR]. Here are the + differences: + + 1) The TGS referral data is returned inside of the KDC message as + "encrypted pre-authentication data". + + + + EncKDCRepPart ::= SEQUENCE { + key [0] EncryptionKey, + last-req [1] LastReq, + nonce [2] UInt32, + 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, + encrypted-pa-data [12] SEQUENCE OF PA-DATA OPTIONAL + } + + 2) The preauth data type definition in the encrypted preauth data is + as follows: + + + + + + + + + +Raeburn & Zhu Expires September 6, 2007 [Page 13] + +Internet-Draft KDC Referrals March 2007 + + + PA-SVR-REFERRAL-INFO 20 + + PA-SVR-REFERRAL-DATA ::= SEQUENCE { + referred-name [1] PrincipalName OPTIONAL, + referred-realm [0] Realm + }} + + 3) When PKINIT ([RFC4556]) is used, the NT-ENTERPRISE client name is + encoded as a Subject Alternative Name (SAN) extension [RFC3280] in + the client's X.509 certificate. The type of the otherName field + for this SAN extension is AnotherName [RFC3280]. The type-id + field of the type AnotherName is id-ms-sc-logon-upn + (1.3.6.1.4.1.311.20.2.3) and the value field of the type + AnotherName is a KerberosString [RFC4120]. The value of this + KerberosString type is the single component in the name-string + [RFC4120] sequence for the corresponding NT-ENTERPRISE name type. + + In Microsoft's current implementation through the use of global + catalogs any domain in one forest is reachable from any other domain + in the same forest or another trusted forest with 3 or less + referrals. A forest is a collection of realms with hierarchical + trust relationships: there can be multiple trust trees in a forest; + each child and parent realm pair and each root realm pair have + bidirectional transitive direct rusts between them. + + While we might want to permit multiple aliases to exist and even be + reported in AD-LOGIN-ALIAS, the Microsoft implementation permits only + one NT-ENTERPRISE alias to exist, so this question had not previously + arisen. + + +Appendix B. Document history + + [REMOVE BEFORE PUBLICATION.] + + 09 Changed to EXAMPLE.COM instead of using Morgan Stanley's domain. + Rewrote description of existing practice. (Don't name the lookup + table consulted. Mention that DNS "canonicalization" is contrary + to [RFC4120].) Noted Microsoft behavior should be moved out into + a separate document. Changed some second-person references in the + introduction to identify the proper parties. Changed PA-CLIENT- + CANONICALIZED to use a separate type for the actual referral data, + add an extension marker to that type, and change the checksum key + from the "returned session key" to the "AS reply key". Changed + AD-LOGIN-ALIAS to contain a sequence of names, to be contained in + AD-KDC-ISSUED instead of AD-IF-RELEVANT, and to drop the no longer + needed separate checksum. Attempt to clarify the cache lifetime + of referral information. + + + +Raeburn & Zhu Expires September 6, 2007 [Page 14] + +Internet-Draft KDC Referrals March 2007 + + + 08 Moved Microsoft implementation info to appendix. Clarify lack of + local server name canonicalization. Added optional authz-data for + login alias, to support user-to-user case. Added requested- + principal-name to ServerReferralData. Added discussion of caching + information, and referral TGT lifetime. + 07 Re-issued with new editor. Fixed up some references. Started + history. + + +Authors' Addresses + + Kenneth Raeburn + Massachusetts Institute of Technology + 77 Massachusetts Avenue + Cambridge, MA 02139 + US + + Email: raeburn@mit.edu + + + Larry Zhu + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + US + + Email: lzhu@microsoft.com + + + + + + + + + + + + + + + + + + + + + + + + +Raeburn & Zhu Expires September 6, 2007 [Page 15] + +Internet-Draft KDC Referrals March 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + 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, THE IETF TRUST 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). + + + + + +Raeburn & Zhu Expires September 6, 2007 [Page 16] + diff --git a/doc/specifications/draft-ietf-krb-wg-kerberos-set-passwd-06.txt b/doc/specifications/draft-ietf-krb-wg-kerberos-set-passwd-06.txt new file mode 100644 index 00000000..2454a058 --- /dev/null +++ b/doc/specifications/draft-ietf-krb-wg-kerberos-set-passwd-06.txt @@ -0,0 +1,1233 @@ + + + +NETWORK WORKING GROUP N. Williams +Internet-Draft Sun +Expires: September 6, 2007 March 5, 2007 + + + Kerberos Set/Change Key/Password Protocol Version 2 + draft-ietf-krb-wg-kerberos-set-passwd-06.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 will expire on September 6, 2007. + +Copyright Notice + + Copyright (C) The IETF Trust (2007). + + + + + + + + + + + + + + + +Williams Expires September 6, 2007 [Page 1] + +Internet-Draft Kerberos Set/Change Password v2 March 2007 + + +Abstract + + This document specifies an extensible protocol for setting keys and + changing the passwords of Kerberos V principals. + + +Table of Contents + + 1. Conventions used in this document . . . . . . . . . . . . 3 + 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. The Protocol . . . . . . . . . . . . . . . . . . . . . . . 5 + 3.1. Transports . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3.1.1. Protocol Framing . . . . . . . . . . . . . . . . . . . . . 5 + 3.2. Protocol Version Negotiation . . . . . . . . . . . . . . . 6 + 3.2.1. Protocol Major Version Negotiation . . . . . . . . . . . . 6 + 3.2.2. Protocol Minor Version Negotiation . . . . . . . . . . . . 7 + 3.3. Use of Kerberos V and Key Exchange . . . . . . . . . . . . 7 + 3.4. Use of ASN.1 . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.5. Internationalization . . . . . . . . . . . . . . . . . . . 8 + 3.5.1. Normalization Forms for UTF-8 Strings . . . . . . . . . . 8 + 3.5.2. Language Negotiation . . . . . . . . . . . . . . . . . . . 8 + 3.6. Protocol Extensibility . . . . . . . . . . . . . . . . . . 9 + 3.7. Protocol Subsets . . . . . . . . . . . . . . . . . . . . . 9 + 4. Protocol Elements . . . . . . . . . . . . . . . . . . . . 10 + 4.1. Password Quality Policies . . . . . . . . . . . . . . . . 10 + 4.1.1. Standard Password Quality Policies . . . . . . . . . . . . 11 + 4.2. PDUs . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 4.3. Operations . . . . . . . . . . . . . . . . . . . . . . . . 14 + 4.3.1. Null . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 4.3.2. Change Kerberos Password . . . . . . . . . . . . . . . . . 14 + 4.3.3. Set Kerberos Password . . . . . . . . . . . . . . . . . . 14 + 4.3.4. Set Kerberos Keys . . . . . . . . . . . . . . . . . . . . 14 + 4.3.5. Generate Kerberos Keys . . . . . . . . . . . . . . . . . . 15 + 4.3.6. Get New Keys . . . . . . . . . . . . . . . . . . . . . . . 15 + 4.3.7. Commit New Keys . . . . . . . . . . . . . . . . . . . . . 16 + 4.3.8. Get Password Quality Policy . . . . . . . . . . . . . . . 16 + 4.3.9. Get Principal Aliases . . . . . . . . . . . . . . . . . . 16 + 4.3.10. Get Realm's Supported Kerberos V Version and Features . . 16 + 4.3.11. Retrieve Principal's S2K Params and Preferred Params . . . 17 + 4.4. Principal Aliases . . . . . . . . . . . . . . . . . . . . 17 + 4.5. Kerberos V Feature Negotiation . . . . . . . . . . . . . . 17 + 5. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . 18 + 6. Security Considerations . . . . . . . . . . . . . . . . . 19 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . 20 + 7.1. Normative References . . . . . . . . . . . . . . . . . . . 20 + 7.2. Informative References . . . . . . . . . . . . . . . . . . 20 + Author's Address . . . . . . . . . . . . . . . . . . . . . 21 + Intellectual Property and Copyright Statements . . . . . . 22 + + + +Williams Expires September 6, 2007 [Page 2] + +Internet-Draft Kerberos Set/Change Password v2 March 2007 + + +1. 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]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Williams Expires September 6, 2007 [Page 3] + +Internet-Draft Kerberos Set/Change Password v2 March 2007 + + +2. Introduction + + Up to this point Kerberos V has lacked a single, standard protocol + for changing passwords and keys. While several vendor-specific + protocols exist for changing Kerberos passwords/keys, none are + properly internationalized and all are incomplete in one respect or + another and none are sufficiently extensible to cope with new + features that may be added to Kerberos V at some future time. + + This document defines a protocol that is somewhat backward-compatible + with the "kpasswd" protocol defined in [RFC3244] that uses more or + less the same protocol framing. + + This new protocol is designed to be extensible and properly + internationalized. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Williams Expires September 6, 2007 [Page 4] + +Internet-Draft Kerberos Set/Change Password v2 March 2007 + + +3. The Protocol + + The structure of the protocol is quite similar to that of typical RPC + protocols. Each transaction consists of a data structure specific to + an operation which is then wrapped in a data structure which is + general to all operations of the protocol. These data structures are + defined with the Abstract Syntax Notation 1 (ASN.1) [CCITT.X680.2002] + and they are encoded using the Distinguished Encoding Rules (DER) + [CCITT.X690.2002]. + + All protocol data is wrapped KRB-PRIV messages, or, in some cases, a + KRB-ERROR, and framed in a header that is backwards compatible with + [RFC3244]. + +3.1. Transports + + The service supports only connection-oriented transports, + specifically TCP, and SHOULD accept requests on TCP port 464, the + same as in [RFC3244]. + +3.1.1. Protocol Framing + + Requests and responses are exchanged using the same framing as in + [RFC3244], but with the following differences: + + o the protocol number field MUST be set to 0x2 (not 0xff80 or 0x1) + + o the 'AP-REQ length' field of the request can be set to 0x0, in + which case the 'AP-REQ' field of the request is excluded + + o the 'KRB-PRIV' field of the request and reply is mutually + exclusive with the 'AP-REQ' field of the request + + o the 'AP-REP length' field of the reply can be set to 0x0, in which + case the 'AP-REP' field of the reply is excluded + + o all errors MUST be sent in a KRB-PRIV if the client's AP-REQ can + be or has been accepted by the server + + o any KRB-ERROR messages are framed and sent in the 'AP-REP' field + of the reply + + The initial message from the client MUST carry an AP-REQ and the + response to any request bearing an AP-REQ MUST carry an AP-REP or + MUST be a KRB-ERROR. + + Subsequent messages exchanged on the same TCP connection MAY involve + Kerberos V AP exchanges, but generally the client SHOULD NOT initiate + + + +Williams Expires September 6, 2007 [Page 5] + +Internet-Draft Kerberos Set/Change Password v2 March 2007 + + + a new AP exchange except when it desires to authenticate as a + different principal, when the ticket last used for authentication + expires or when the server responds with an error indicating that the + client must re-authenticate. + +3.2. Protocol Version Negotiation + + There are several major versions of this protocol. Version 2 also + introduces a notion of protocol minor versions for use in negotiating + protocol extensions. As of this time only one minor version is + defined for major version 2: minor version 0, defined herein. + +3.2.1. Protocol Major Version Negotiation + + Version 2 clients that also support other versions, such as 0xff80, + as in [RFC3244], SHOULD attempt to use version 2 of the protocol + first. + + Servers which do not support version 2 of this protocol typically + include their preferred version number in the reply and/or may + include a reply in the e-data of a KRB-ERROR, or in a KRB-PRIV with a + status code of KRB5_KPASSWD_MALFORMED. + + Note that some [RFC3244] server implementations close the TCP + connection without returning any other response. Note also that + there is no integrity protection for the major version number in the + protocol framing or for any data in a KRB-ERROR. + + As a result change password protocol major version negotiation is + subject to downgrade attacks. Therefore major version negotiation is + NOT RECOMMENDED. + + Where the server indicates that it does not support version 2, the + client MAY, but SHOULD NOT, unless configured to do so, fall back on + another major version of this protocol. + + Version 2 servers MAY respond to non-v2 requests using whatever + response is appropriate for the versions used by the clients, but if + a server does not do this or know how to do this then it MUST respond + with an error framed as in Section 3.1.1, using an AP-REP and KRB- + PRIV if the client's AP-REQ can be accepted, or a KRB-ERROR otherwise + and using a ProtocolErrorCode value of unsupported-major-version. + + It is expected that implementations of as yet unspecified future + major versions of this protocol will be required to support version 2 + integrity protected error replies for properly indicating no support + for version 2 of the protocl. We also hope that no further major + versions of this protocol will be needed. + + + +Williams Expires September 6, 2007 [Page 6] + +Internet-Draft Kerberos Set/Change Password v2 March 2007 + + +3.2.2. Protocol Minor Version Negotiation + + Version 2 clients are free to use whatever protocol minor version and + message extensions are available to them in their initial messages to + version 2 servers, provided that the minor versions (other than 0) + have been defined through IETF documents. + + Version 2 servers MUST answer with the highest protocol minor version + number supported by the server and the client. + + Version 2 clients MUST use the protocol minor version used in a + server's reply for any subsequent messages in the same TCP session. + + See Section 3.6 for further description of the protocol's + extensibility and its relation to protocol minor versions and the + negotiation thereof. + +3.3. Use of Kerberos V and Key Exchange + + This protocol makes use of messages defined in [RFC4120]. + Specifically, AP-REQ, AP-REP, KRB-ERROR and KRB-PRIV. + + All operations are to be performed by the server on behalf of the + client principal. + + Clients SHOULD use "kadmin/setpw" as the principal name of the server + for all requests except when changing the client principal's own + expired password, for which they should use "kadmin/changepw". The + "kadmin/changepw" service exists to allow KDCs to limit principals + with expired passwords to getting initial tickets to the password + changing service only and only for changing expired passwords. + + Servers MUST limit clients that used the "kadmin/changepw" service + principal name to changing the password of the client principal. + + The client MUST request mutual authentication and the client MUST + MUST request the use of sequence numbers. + + Servers MAY force the use of INITIAL or fresh tickets for any + requests -- see Section 4.3. Traditionally users with expired + passwords are allowed only INITIAL tickets for the password changing + server, therefore clients MUST support the use of INITIAL tickets. + + Servers MUST specify a sub-session key. + + The encrypted part of KRB-PRIVs MUST be encrypted with the server's + sub-session key and key usage 20 (client->server) or 21 + (server->client). + + + +Williams Expires September 6, 2007 [Page 7] + +Internet-Draft Kerberos Set/Change Password v2 March 2007 + + + After each new AP exchange the client and server MUST destroy the + session keys, if any, resulting from the previous AP exchange. + +3.4. Use of ASN.1 + + This protocol's messages are defined in ASN.1, using only features + from [CCITT.X680.2002]. All ASN.1 types defined herein are to be + encoded in DER [CCITT.X690.2002]. A complete ASN.1 module is given + in Section 5. + + The DER encoding of the ASN.1 PDUs are exchanged wrapped in a KRB- + PRIV as described above and/or as e-data in KRB-ERROR messages. + +3.5. Internationalization + + This protocol's request PDU carries an optional field indicating the + languages spoken by the client user; the client SHOULD send its list + of spoken languages to the server (once per-TCP session). + + The server SHOULD localize all strings intended for display to users + to a language in common with the languages spoken by the client user. + + Strings for Kerberos principal and realm names used in this protocol + are be constrained as per [RFC4120]. + +3.5.1. Normalization Forms for UTF-8 Strings + + Because Kerberos V [RFC4120] restricts principal names, realm names + and passwords to IA5String, this protocol uses UTF8String with an + extensible constraint to IA5String. + + Future versions of Kerberos may relax this constraint; if so then a + minor version of this protocol should relax this constraint + accordingly. + +3.5.2. Language Negotiation + + The server MUST pick a language from the client's input list or the + default language tag (see [RFC3066]) for text in its responses which + is meant for the user to read. + + The server SHOULD use a language selection algorithm such that + consideration is first given to exact matches between the client's + spoken languages and the server's available locales, followed by + "fuzzy" matches where only the first sub-tags of the client's + language tag list are used for matching against the servers available + locales. + + + + +Williams Expires September 6, 2007 [Page 8] + +Internet-Draft Kerberos Set/Change Password v2 March 2007 + + + Servers MUST cache the optional language tag lists from prior + requests for use with subsequent requests that exclude the language + tag list. Clients MAY expect such server behaviour and send the + language tag lists only once per-TCP session. Clients SHOULD send + the server the language tag list at least once. + + When the server has a message catalog for one of the client's spoken + languages the server SHOULD localize any text strings intended for + display to users. + +3.6. Protocol Extensibility + + The protocol is defined in ASN.1 and uses extensibility markers + throughout. As such, the module presented herein can be extended + within the framework of [CCITT.X680.2002]. + + Typed holes are not used in this protocol as it is very simple and + does not require the ability to deal with abstract data types defined + in different layers. For this reason, the only way to extend this + protocol is by extending the ASN.1 module within the framework of the + IETF; all future extensions to this protocol have to be defined in + IETF documents unless otherwise specified in a future IETF revision + of this protocol. + + A protocol minor version number is used to negotiate use of + extensions. See Section 3.2.2 for the minor version negotiation. + + Servers SHOULD ignore unknown additions to the ASN.1 types, in + initial requests, where the syntax allows them, except for extensions + to the "Op-req" type, which MUST result in an error. + + Servers MUST respond with an error (ProtocolErrorCode value of proto- + unsupported-operation) to clients that use operations unknown to the + server. + +3.7. Protocol Subsets + + The structure of the protocol is such that the ASN.1 syntaxes for the + various operations supported by the protocol are independent of the + each other. Client and server implementations MAY implement subsets + of the overall protocol by removing some alternatives to the Op-req, + Op-rep and Op-err CHOICEs from the ASN.1 module given in Section 5. + + For example, it should be possible to have a password-change only + client that cannot set principal's keys - and vice versa. + + + + + + +Williams Expires September 6, 2007 [Page 9] + +Internet-Draft Kerberos Set/Change Password v2 March 2007 + + +4. Protocol Elements + + The protocol as defined herein supports the following operations + relating to the management of Kerberos principal's passwords or keys: + + o change password (or enctypes and string-to-key parameters) + + o set password (administrative) + + o set new keys + + o generate new keys + + o get new, un-committed keys + + o commit new keys + + o get password policy name and/or description of principal + + o list aliases of a principal + + o list enctypes and version of Kerberos V supported by realm + + The operation for retrieving a list of aliases of a principal is + needed where KDCs implement aliasing of principal names and allows + clients to properly setup their key databases when principal aliasing + is in use. + + Operations such as creation or deletion of principals are outside the + scope of this document, and should be performed via other means, such + as through directories or other Kerberos administration protocols. + + The individual operations are described in Section 4.3. + +4.1. Password Quality Policies + + Servers may reject new user passwords for failing to meet password + quality policies. When this happens the server must be able to + communicate the policy to the user so that the user may select a + better password. + + The protocol allows for two ways to do this: + + o through error codes that identify specific password quality + policies known; + + o through localized error strings. + + + + +Williams Expires September 6, 2007 [Page 10] + +Internet-Draft Kerberos Set/Change Password v2 March 2007 + + + The use of localized error strings allows servers to convey non- + standard password quality policies to users, but it requires server- + side message catalogs for localization and support for language + negotiation. The use of error codes only allows for standard + password quality policies that clients must be aware of a priori, + therefore use of error codes requires the distribution of new message + catalogs to clients whenever new error codes are added; this + simplifies servers at the expense of password quality extensibility. + + When a server would reject a password due to its failing to meet a + standard password quality policy the the server MUST use the + appropriate error codes (see below) and the server SHOULD send a + localized error message to the user. + + When a server would reject a password due to its failing to meet a + non-standard password quality policy (one not described herein) the + the server MUST send a localized error message to the user. + +4.1.1. Standard Password Quality Policies + + o pwq-too-soon + + It is too soon for the principal to change its password or long- + term keys. + + + o pwq-history + + The new password is one that the principal has used before or is + too similar to a password that it has used before. + + + o pwq-too-short + + The new password is too short. + + + o pwq-dictionary-words + + The new password is or contains words that are in the dictionary. + + + o pwq-prohibited-codepoints + + The new password contains prohibited codepoints. + + + + + + +Williams Expires September 6, 2007 [Page 11] + +Internet-Draft Kerberos Set/Change Password v2 March 2007 + + + o pwq-need-more-char-classes + + The new password does not have characters from enough character + classes (lower-case letters, upper-case letters, digits, + punctuation, etc...). + + +4.2. PDUs + + The types "Request," "Response" and "Error-Response" are the ASN.1 + module's PDUs. + + The "Request" and "Response" PDUs are always to be sent wrapped in + KRB-PRIV messages, except for the "Error-Response" PDU which MUST be + sent as KRB-ERROR e-data (see Section 3.3) when AP exchanges fail, + otherwise it MUST be sent wrapped in a KRB-PRIV. + + The ASN.1 syntax for the PDUs is given in Section 5. + + Note that the first field of each PDU is the major version of the + protocol, defaulted to 2, meaning that it is never included in + version 2 exchanges. Similarly, the second field of each PDU is the + minor version, defaulted to 0. + + The request, responses and error PDUs consist of an outer structure + ("Request," "Response" and "Error-Response") containing fields common + to all requests, responses and errors, respectively, and an inner + structure for fields that are specific to each operation's requests/ + responses. The inner structure is optional in the case of the Error- + Response PDU and need not be included when generic errors occur for + which there is a suitable ProtocolErrorCode. + + Specifically, the outer Request structure has a field for passing a + client user's spoken (read) languages to the server. It also has two + optional fields for identifying the requested operation's target + principal's name and realm (if not sent then the server MUST use the + client's principal name and realm as the target). A boolean field + for indicating whether or not the request should be dry-run is also + included; dry-runs can be used to test server policies, and servers + MUST NOT modify any principals when processing dry-run requests. + + The Response and Error PDUs' outer structures include a field + indicating the language that the server has chosen for localization + of text intended to be displayed to users; this field is defaulted to + "i-default". This language tag applies to all UTF8 strings in the + inner structure (Op-rep and Op-err) that are meant to be displayed to + users. + + + + +Williams Expires September 6, 2007 [Page 12] + +Internet-Draft Kerberos Set/Change Password v2 March 2007 + + + The protocol error codes are: + + o proto-generic-error + + An operation-specific error ocurred, see the inner Op-error. + + o proto-format-error + + The server failed to parse a message sent by the client. + + o proto-unsupported-major-version + + The server does not support the major version of this protocol + requested by the client. + + o proto-unsupported-minor-version + + The server does not support the minor version of this protocol + requested by the client. + + o proto-unsupported-operation + + The server does not support the operation requested by the client. + + o proto-wrong-service-principal + + Use kadmin/setpw for the server's principal name. + + o proto-re-authentication-required + + The server demands that the client re-authenticate through a new + AP exchange. + + o proto-initial-ticket-required + + Use of an INITIAL ticket is required for the requested operation. + + o proto-client-and-target-realm-mismatch + + The server requires that the client's principal name and the + target principal of the operation share the same realm name. + + o proto-target-principal-unknown + + The target of the client's operation is not a valid principal. + + o proto-authorization-failed + + + + +Williams Expires September 6, 2007 [Page 13] + +Internet-Draft Kerberos Set/Change Password v2 March 2007 + + + The client principal is not authorized to perform the requested + operation. + + o proto-fresh-ticket-required + + The server would like the client to re-authenticate using a fresh + ticket. + +4.3. Operations + + This section describes the semantics of each operation request and + response defined in the ASN.1 module in Section 5. + +4.3.1. Null + + + + + + +4.3.2. Change Kerberos Password + + + + + + +4.3.3. Set Kerberos Password + + + + + + +4.3.4. Set Kerberos Keys + + + + + + + + + + + + + + + + +Williams Expires September 6, 2007 [Page 14] + +Internet-Draft Kerberos Set/Change Password v2 March 2007 + + +4.3.5. Generate Kerberos Keys + + + + + + +4.3.6. Get New Keys + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Williams Expires September 6, 2007 [Page 15] + +Internet-Draft Kerberos Set/Change Password v2 March 2007 + + +4.3.7. Commit New Keys + + + + + + +4.3.8. Get Password Quality Policy + + + + + + +4.3.9. Get Principal Aliases + + + + + + +4.3.10. Get Realm's Supported Kerberos V Version and Features + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Williams Expires September 6, 2007 [Page 16] + +Internet-Draft Kerberos Set/Change Password v2 March 2007 + + +4.3.11. Retrieve Principal's S2K Params and Preferred Params + + + + + + +4.4. Principal Aliases + + Applications that use Kerberos often have to derive acceptor + principal names from hostnames entered by users. Such hostnames may + be aliases, they may be fully qualified, partially qualified or not + qualified at all. Some implementations have resorted to deriving + principal names from such hostnames by utilizing the names services + to canonicalize the hostname first; such practices are not secure + unless the name service are secure, which often aren't. + + One method for securely deriving principal names from hostnames is to + alias principals at the KDC such that the KDC will issue tickets for + principal names which are aliases of others. It is helpful for + principals to know what are their aliases as known by the KDCs. + + Note that changing a principal's aliases is out of scope for this + protocol. + +4.5. Kerberos V Feature Negotiation + + Principals and realms' KDCs may need to know about additional + Kerberos V features and extensions that they each support. Several + operations (see above) provide a way for clients and servers to + exchange such infomration, in the form of lists of types supported + for the various typed holes used in Kerberos V. + + + + + + + + + + + + + + + + + + + +Williams Expires September 6, 2007 [Page 17] + +Internet-Draft Kerberos Set/Change Password v2 March 2007 + + +5. ASN.1 Module + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Williams Expires September 6, 2007 [Page 18] + +Internet-Draft Kerberos Set/Change Password v2 March 2007 + + +6. Security Considerations + + Implementors and site administrators should note that the redundancy + of UTF-8 encodings of passwords varies by language. Password quality + policies SHOULD, therefore, take this into account when estimating + the amount of redundancy and entropy in a proposed new password. + + Kerberos set/change password/key protocol major version negotiation + cannot be done securely; a downgrade attack is possible against + clients that attempt to negotiate the protocol major version to use + with a server. It is not clear at this time that the attacker would + gain much from such a downgrade attack other than denial of service + (DoS) by forcing the client to use a protocol version which does not + support some feature needed by the client (Kerberos V in general is + subject to a variety of DoS attacks anyways [RFC4120]). Clients + SHOULD NOT negotiate support for legacy major versions of this + protocol unless configured otherwise. + + This protocol does not have Perfect Forward Security (PFS). As a + result, any passive network snooper watching password/key changing + operations who has stolen a principal's password or long-term keys + can find out what the new ones are. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Williams Expires September 6, 2007 [Page 19] + +Internet-Draft Kerberos Set/Change Password v2 March 2007 + + +7. References + +7.1. Normative References + + [CCITT.X680.2002] + International International Telephone and Telegraph + Consultative Committee, "Abstract Syntax Notation One + (ASN.1): Specification of basic notation", + CCITT Recommendation X.680, July 2002. + + [CCITT.X690.2002] + International International Telephone and Telegraph + Consultative Committee, "ASN.1 encoding rules: + Specification of basic encoding Rules (BER), Canonical + encoding rules (CER) and Distinguished encoding rules + (DER)", CCITT Recommendation X.690, July 2002. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3066] Alvestrand, H., "Tags for the Identification of + Languages", RFC 3066, January 2001. + + [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The + Kerberos Network Authentication Service (V5)", RFC 4120, + July 2005. + +7.2. Informative References + + [RFC3244] Swift, M., Trostle, J., and J. Brezak, "Microsoft Windows + 2000 Kerberos Change Password and Set Password Protocols", + RFC 3244, February 2002. + + + + + + + + + + + + + + + + + + + +Williams Expires September 6, 2007 [Page 20] + +Internet-Draft Kerberos Set/Change Password v2 March 2007 + + +Author's Address + + Nicolas Williams + Sun Microsystems + 5300 Riata Trace Ct + Austin, TX 78727 + US + + Email: Nicolas.Williams@sun.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Williams Expires September 6, 2007 [Page 21] + +Internet-Draft Kerberos Set/Change Password v2 March 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + 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, THE IETF TRUST 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). + + + + + +Williams Expires September 6, 2007 [Page 22] + + diff --git a/doc/specifications/draft-ietf-krb-wg-naming-03.txt b/doc/specifications/draft-ietf-krb-wg-naming-03.txt new file mode 100644 index 00000000..1abdacc1 --- /dev/null +++ b/doc/specifications/draft-ietf-krb-wg-naming-03.txt @@ -0,0 +1,392 @@ + + +NETWORK WORKING GROUP L. Zhu +Internet-Draft Microsoft Corporation +Updates: 4120 (if approved) March 3, 2007 +Intended status: Standards Track +Expires: September 4, 2007 + + + Additional Kerberos Naming Constraints + draft-ietf-krb-wg-naming-03 + +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 September 4, 2007. + +Copyright Notice + + Copyright (C) The IETF Trust (2007). + +Abstract + + This document defines new naming constraints for well-known Kerberos + principal name and well-known Kerberos realm names. + + + + + + + + +Zhu Expires September 4, 2007 [Page 1] + +Internet-Draft Kerberos Naming March 2007 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Conventions Used in This Document . . . . . . . . . . . . . . . 3 + 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3.1. Well-known Kerberos Principal Names . . . . . . . . . . . . 3 + 3.2. Well-known Kerberos Realm Names . . . . . . . . . . . . . . 4 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 + 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 + 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 + Intellectual Property and Copyright Statements . . . . . . . . . . 7 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zhu Expires September 4, 2007 [Page 2] + +Internet-Draft Kerberos Naming March 2007 + + +1. Introduction + + Occasionally protocol designers need to designate a Kerberos + principal name or a Kerberos realm name to have special meanings, + other than identifying a particular instance. An example is that the + the anonymous principal name and the anonymous realm name are defined + for the Kerberos anonymity support [ANON]. This anonymity name pair + conveys no more meaning than that the client's identity is not + disclosed. In the case of the anonymity support, it is critical that + deployed Kerberos implementations that do not support anonymity MUST + fail the authentication if the anonymity name pair is used, therefore + no access is granted accidentally to a principal who's name happens + to match with that of the anonymous identity. + + However Kerberos as defined in [RFC4120] does not have such reserved + names. As such, protocol designers have resolved to use exceedingly- + unlikely-to-have-been-used names to avoid collision. Even if a + registry were setup to avoid collision for new implementations, there + is no guarantee for deployed implementations to prevent accidental + reuse of names that can lead to access being granted unexpectedly. + + The Kerberos realm name in [RFC4120] has a reserved name space + although no specific name is defined and the criticality of unknown + reserved realm names is not specified. + + This document is to remedy these by defining well-known Kerberos + names and the protocol behavior when a well-known name is used but + not supported. + + +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]. + + +3. Definitions + + In this section, well-known names are defined for both the Kerberos + principal name and the Kerberos realm name. + +3.1. Well-known Kerberos Principal Names + + A new name type KRB_NT_WELLKNOWN is defined for well-known principal + names. The Kerberos principal name is defined in Section 6.2 of + [RFC4120]. + + + + +Zhu Expires September 4, 2007 [Page 3] + +Internet-Draft Kerberos Naming March 2007 + + + KRB_NT_WELLKNOWN 11 + + A well-known principal name MUST have at least two or more + KerberosString components, and the first component must be the string + literal "WELLKNOWN". + + If a well-known principal name is used as the client principal name + or the server principal name but not supported, the Authentication + Service (AS) [RFC4120] and the application server MUST reject the + authentication attempt. Similarly, the Ticket Granting Service (TGS) + [RFC4120] MAY reject the authentication attempt if a well-known + principal name is used as the client principal name but not + supported, and SHOULD reject the authentication attempt is a well- + known principal name is used as the server principal name but not + supported. Unless otherwise specified, if a well-known principal + name is used but not supported in any other places of Kerberos + messages, authentication MUST fail. The error code is + KRB_AP_ERR_PRINCIPAL_UNKNOWN, and there is no accompanying error data + defined in this document for this error. + + KRB_AP_ERR_PRINCIPAL_UNKNOWN 82 + -- A well-known Kerberos principal name is used but not + -- supported. + +3.2. Well-known Kerberos Realm Names + + Section 6.1 of [RFC4120] defines the "other" style realm name, a new + realm type WELLKNOWN is defined as a name of type "other", with the + NAMETYPE part filled in with the string literal "WELLKNOWN". + + other: WELLKNOWN:realm-name + + This name type is designated for well-known Kerberos realms. + + The AS and the application server MUST reject the authentication + attempt if a well-known realm name is used as the client realm or the + server realm but not supported. The TGS [RFC4120] MAY reject the + authentication attempt if a well-known realm name is used as the + client realm but not supported, and SHOULD reject the authentication + attempt is a well-known realm name is used as the server realm but + not supported. Unless otherwise specified, if a well-known realm + name is used but not supported in any other places of Kerberos + messages, authentication MUST fail. The error code is + KRB_AP_ERR_REALM_UNKNOWN, and there is no accompanying error data + defined in this document for this error. + + KRB_AP_ERR_REALM_UNKNOWN 83 + -- A well-known Kerberos realm name is used but not + + + +Zhu Expires September 4, 2007 [Page 4] + +Internet-Draft Kerberos Naming March 2007 + + + -- supported. + + Unless otherwise specified, all principal names involving a well- + known realm name are reserved, and if a reserved principal name is + used but not supported, authentication MUST fail with the code + KRB_AP_ERR_PRINCIPAL_RESERVED. + + KRB_AP_ERR_PRINCIPAL_RESERVED 84 + -- A reserved Kerberos principal name is used but not + -- supported. + + There is no accompanying error data defined in this document for this + error. + + According to Section 3.3.3.2 of [RFC4120], the TGS MUST add the name + of the previous realm into the transited field of the returned + ticket. Typically well-known realms are defined to carry special + meanings, and they are not used to refer to intermediate realms in + the client's authentication path. Consequently, unless otherwise + specified, a well-known Kerberos realm name MUST NOT be present in + the transited field [RFC4120] of a ticket. Aside from the + hierarchical meaning of a null subfield, the DOMAIN-X500-COMPRESS + encoding for transited realms [RFC4120] treats realm names as + strings, although it is optimized for domain style and X.500 realm + names, hence the DOMAIN-X500-COMPRESS encoding can be used when the + client realm or the server realm is reserved or when a reserved realm + is in the transited field. However, if the client's realm is a well- + known realm, the abbreviation forms [RFC4120] that build on the + preceding name cannot be used at the start of the transited encoding. + The null-subfield form (e.g., encoding ending with ",") [RFC4120] + could not be used next to a well-known realm, including potentially + at the beginning and end where the client and server realm names, + respectively, are filled in. + + +4. Security Considerations + + If a well-known name is not supported, authentication MUST fail. + Otherwise, access can be granted unintentionally, resulting in a + security weakness. + + Care MUST be taken to avoid accidental reuse of names. + + +5. Acknowledgements + + The initial document was mostly based on the author's conversation + with Clifford Newman and Sam Hartman. + + + +Zhu Expires September 4, 2007 [Page 5] + +Internet-Draft Kerberos Naming March 2007 + + + Jeffery Hutzelman and Ken Raeburn provided helpful commments for + improvements based on early revisions of this document. + + +6. IANA Considerations + + This document provides the framework for defining well-known Kerberos + names and Kerberos realms. A new IANA registry should be created to + contain well-known Kerberos names and Kerberos realms that are + defined based on this document. The evaluation policy is + "Specification Required". + + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The + Kerberos Network Authentication Service (V5)", RFC 4120, + July 2005. + +7.2. Informative References + + [ANON] Zhu, L., Leach, P. and K. Jaganathan, "Kerberos Anonymity + Support", draft-ietf-krb-wg-anon, work in progress. + +Author's Address + + Larry Zhu + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + US + + Email: lzhu@microsoft.com + + + + + + + + + + + + + +Zhu Expires September 4, 2007 [Page 6] + +Internet-Draft Kerberos Naming March 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + 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, THE IETF TRUST 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 Expires September 4, 2007 [Page 7] + + diff --git a/doc/specifications/draft-ietf-krb-wg-pkinit-alg-agility-02.txt b/doc/specifications/draft-ietf-krb-wg-pkinit-alg-agility-02.txt new file mode 100644 index 00000000..0264c13e --- /dev/null +++ b/doc/specifications/draft-ietf-krb-wg-pkinit-alg-agility-02.txt @@ -0,0 +1,807 @@ + + +NETWORK WORKING GROUP L. Astrand +Internet-Draft Stockholm University +Updates: 4556 (if approved) L. Zhu +Intended status: Standards Track Microsoft Corporation +Expires: September 5, 2007 March 4, 2007 + + + PK-INIT Cryptographic Algorithm Agility + draft-ietf-krb-wg-pkinit-alg-agility-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 September 5, 2007. + +Copyright Notice + + Copyright (C) The IETF Trust (2007). + +Abstract + + The PK-INIT defined in RFC 4556 is examined and updated to remove + protocol structures tied to specific cryptographic algorithms. The + affinity to SHA as the check-sum algorithm in the authentication + request is analyzed. The PK-INIT key derivation function is made + negotiable, the digest algorithms for signing the pre-authentication + data and the client's X.509 certificates are made discoverable. + + + + +Astrand & Zhu Expires September 5, 2007 [Page 1] + +Internet-Draft PK-INIT Crypto Agility March 2007 + + + These changes provide protection preemptively against vulnerabilities + discovered in the future against any specific cryptographic + algorithm, and allow incremental deployment of newer algorithms. + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 + 3. paChecksum Agility . . . . . . . . . . . . . . . . . . . . . . 4 + 4. CMS Digest Algorithm Agility . . . . . . . . . . . . . . . . . 4 + 5. X.509 Certificate Signer Algorithm Agility . . . . . . . . . . 5 + 6. KDF agility . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 + 10.2. Informative References . . . . . . . . . . . . . . . . . 10 + Appendix A. PKINIT ASN.1 Module . . . . . . . . . . . . . . . . . 10 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 + Intellectual Property and Copyright Statements . . . . . . . . . . 14 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Astrand & Zhu Expires September 5, 2007 [Page 2] + +Internet-Draft PK-INIT Crypto Agility March 2007 + + +1. Introduction + + In August 2004, Xiaoyun Wang's research group reported MD4 [RFC1320] + collisions generated using hand calculation [WANG04] alongside + attacks on later hash function designs in the MD4, MD5 [RFC1321] and + SHA [RFC4634] family. Implementations based on Wang's algorithm can + find collisions in real time. These discoveries challenged the + security for protocols relying on the collision resistance properties + of these hashes, for example one can forge a digital signature when + SHA-1 [RFC4634] is the digest algorithm. A more far reaching side + effect of these recent events, however, is that it is now generally + considered flawed or distasteful at least if protocols are designed + to use only specific algorithms. + + The Internet Engineer Task Force (IETF) called for actions to update + existing protocols to provide crypto algorithm agility in order to + untie protocols with specific algorithms. The idea is that if the + protocol has crypto algorithm agility, and when a new vulnerability + specific to an algorithm is discovered, this algorithm can be + disabled via protocol negotiation quickly, thus we can avoid the wait + for the multi-year standardization and implementation efforts to + update the protocols. In additon, crypto agility allows deployment + of new crypto algorithms to be done incrementally, rather than + requring a "flag day" on which the change must be deployed everywhere + at the same time in order to maintain interoperability + + This document is to update PK-INIT [RFC4556] to provide crypto + algorithm agility. Several protocol structures used in the [RFC4556] + protocol are either tied to SHA-1, or require the algorithms not + negotiated but rather based on local policy. The following concerns + have been addressed: + + o The checksum algorithm in the authentication request is hardwired + to use SHA-1 [RFC4634]. + + o The acceptable digest algorithms for signing the authentication + data are not discoverable. + + o The key derivation function in Section 3.2.3 is hardwired to use + SHA-1. + + o The acceptable digest algorithms for signing the client X.509 + certificates are not discoverable. + + To accomplish these, new key derivation functions (KDFs) identifiable + by object identifiers are defined. The PKINIT client provides a list + of KDFs in the request and the KDC picks one in the response, thus a + mutually-supported KDF is negotiated. + + + +Astrand & Zhu Expires September 5, 2007 [Page 3] + +Internet-Draft PK-INIT Crypto Agility March 2007 + + + Furthermore, structures are defined to allow the client discover the + Cryptographic Message Syntax (CMS) [RFC3852] digest algorithms + supported by the KDC for signing the pre-authentication data and + signing the client X.509 certificate. + + +2. Requirements Notation + + 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]. + + +3. paChecksum Agility + + The paChecksum defined in Section 3.2.1 of [RFC4556] provides a + cryptographic bindings between the client's pre-authentication data + and the corresponding Kerberos request body. This also prevents the + KDC body from being tempered with. SHA-1 is the only allowed + checksum algorithm defined in [RFC4556]. This facility relies the + collision resistance properties of the SHA-1 checksum [RFC4634]. + + When the reply key delivery mechanism is based on public key + encryption as described in Section 3.2.3. of [RFC4556], the + asChecksum in the KDC reply provides the binding between the pre- + authentication and the ticket request and response messages, and + integrity protection for the unauthenticated clear text in these + messages. However, if the reply key delivery mechanism is based on + the Diffie-Hellman key agreement as described in Section 3.2.3.1 of + [RFC4556], the security provided by using SHA-1 in the paChecksum is + weak. In this case, the new KDF selected by the KDC as described in + Section 6 provides the cryptographic binding and integrity + protection. + + +4. CMS Digest Algorithm Agility + + When the KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error is returned + as described In section 3.2.2 of [RFC4556], implementations + comforming to this specification can OPTIONALLY send back a list of + supported CMS types signifying the digest algorithms supported by the + KDC, in the decreasing preference order. This is accomplished by + including a TD_CMS_DATA_DIGEST_ALGORITHMS typed data element in the + error data. + + TD_CMS_DATA_DIGEST_ALGORITHMS 111 + + The corresponding data for the TD_CMS_DATA_DIGEST_ALGORITHMS contains + + + +Astrand & Zhu Expires September 5, 2007 [Page 4] + +Internet-Draft PK-INIT Crypto Agility March 2007 + + + the ASN.1 Distinguished Encoding Rules (DER) [X680] [X690] encoded + TD-CMS-DIGEST-ALGORITHMS-DATA structure defined as follows: + + TD-CMS-DIGEST-ALGORITHMS-DATA ::= SEQUENCE OF + AlgorithmIdentifier + -- Contains the list of CMS algorithm [RFC3852] + -- identifiers that identify the digest algorithms + -- acceptable by the KDC for signing CMS data in + -- the order of decreasing preference. + + The algorithm identifiers in the TD-CMS-DIGEST-ALGORITHMS identifiy + digest algorithms supported by the KDC. + + This information sent by the KDC via TD_CMS_DATA_DIGEST_ALGORITHMS + can facilitate trouble-shooting when none of the digest algorithms + supported by the client is supported by the KDC. + + +5. X.509 Certificate Signer Algorithm Agility + + When the client's X.509 certificate is rejected and the + KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error is returned as + described in section 3.2.2 of [RFC4556], conforming implementations + can OPTIONALLY send a list of digest algorithms acceptable by the KDC + for use by the CA in signing the client's X.509 certificate, in the + decreasing preference order. This is accomplished by including a + TD_CERT_DIGEST_ALGORITHMS typed data element in the error data. The + corresponding data contains the ASN.1 DER encoding of the structure + TD-CERT-DIGEST-ALGORITHMS-DATA defined as follows: + + TD_CERT_DIGEST_ALGORITHMS 112 + + TD-CERT-DIGEST-ALGORITHMS-DATA ::= SEQUENCE { + allowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier, + -- Contains the list of CMS algorithm [RFC3852] + -- identifiers that identify the digest algorithms + -- that are used by the CA to sign the client's + -- X.509 certificate and acceptable by the KDC in + -- the process of validating the client's X.509 + -- certificate, in the order of decreasing + -- preference. + rejectedAlgorithm [1] AlgorithmIdentifier OPTIONAL, + -- This identifies the digest algorithm that was + -- used to sign the client's X.509 certificate and + -- has been rejected by the KDC in the process of + -- validating the client's X.509 certificate + -- [RFC3280]. + ... + + + +Astrand & Zhu Expires September 5, 2007 [Page 5] + +Internet-Draft PK-INIT Crypto Agility March 2007 + + + } + + The KDC fills in allowedAlgorithm field with the list of algorithm + [RFC3852] identifiers that identify digest algorithms that are used + by the CA to sign the client's X.509 certificate and acceptable by + the KDC in the process of validating the client's X.509 certificate, + in the order of decreasing preference. The rejectedAlgorithm field + identifies the signing algorithm for use in signing the client's + X.509 certificate that has been rejected by the KDC in the process of + validating the client's certificate [RFC3280]. + + +6. KDF agility + + Based on [RFC3766] and [X9.42], Section 3.2.3.1 of [RFC4556] defines + a Key Derivation Function (KDF) that derives a Kerberos protocol key + based on the secret value generated by the Diffie-Hellman key + exchange. This KDF requires the use of SHA-1 [RFC4634]. + + New KDFs defined in this document based on [SP80056A] can be used in + conjunction with any hash functions. A new KDF is identified by an + object identifier. The following KDF object identifiers are defined: + + id-pkinit-kdf OBJECT IDENTIFIER ::= { id-pkinit 6} + -- PKINIT KDFs + id-pkinit-kdf-ah-sha1 OBJECT IDENTIFIER ::= { id-pkinit-kdf 1} + -- SP800 56A ASN.1 structured hash based KDF using SHA-1 + id-pkinit-kdf-ah-sha256 OBJECT IDENTIFIER ::= { id-pkinit-kdf 2 } + -- SP800 56A ASN.1 structured hash based KDF using SHA-256 + id-pkinit-kdf-ah-sha512 OBJECT IDENTIFIER ::= { id-pkinit-kdf 3 } + -- SP800 56A ASN.1 structured hash based KDF using SHA-512 + + Where id-pkinit is defined in [RFC4556]. The id-pkinit-kdf-ah-sha1 + KDF is the ASN.1 structured hash based KDF (HKDF) [SP80056A] that + uses SHA-1 [RFC4634] as the hash function. Similarly id-pkinit-kdf- + ah-sha256 and id-pkinit-kdf-ah-sha512 are the ASN.1 structured HKDF + using SHA-256 [RFC4634] and SHA-512 [RFC4634] respectively. The + common input parameters for these KDFs are provided as follows: + + o The secret value is the shared secret value generated by the + Diffie-Hellman exchange. The Diffie-Hellman shared value is first + padded with leading zeros such that the size of the secret value + in octets is the same as that of the modulus, then represented as + a string of octets in big-endian order. + + o The key data length is K. K is the key-generation seed length in + bits [RFC3961] for the Authentication Service (AS) reply key. The + enctype of the AS reply key is selected according to [RFC4120]. + + + +Astrand & Zhu Expires September 5, 2007 [Page 6] + +Internet-Draft PK-INIT Crypto Agility March 2007 + + + o The algorithm identifier input parameter is the identifier of the + respective KDF. For example, this is id-pkinit-kdf-ah-sha1 if the + KDF is the [SP80056A] ASN.1 structured HKDF using SHA-1 as the + hash. + + o The initiator identifier is an OCTET STRING that contains the + ASN.1 DER encoding of the KRB5PrincipalName [RFC4556] that + identifies the client as specified in the AS-REQ [RFC4120] in the + request. + + o The recipient identifier is an OCTET STRING that contains the + ASN.1 DER encoding of the KRB5PrincipalName [RFC4556] that + identifies the TGS as specified in the AS-REQ [RFC4120] in the + request. + + o The supplemental private information is absent (not used). + + o The supplemental public information is an OCTET STRING that + contains the ASN.1 DER encoding of the structure PkinitSuppPubInfo + as defined later in this section. + + o The hash length is 128 for id-pkinit-kdf-ah-sha1, 256 for id- + pkinit-kdf-ah-sha256, and 512 for id-pkinit-kdf-ah-sha512. + + o The maximum hash input length is 2^64 in bits. + + The structure PkinitSuppPubInfo is defined as follows: + + PkinitSuppPubInfo ::= SEQUENCE { + enctype [0] Int32, + -- The enctype of the AS reply key. + as-REQ [1] OCTET STRING, + -- This contains the AS-REQ in the request. + pk-as-rep [2] OCTET STRING, + -- Contains the DER encoding of the type + -- PA-PK-AS-REP [RFC4556] in the KDC reply. + ticket [3] Ticket, + -- This is the ticket in the KDC reply. + ... + } + + The PkinitSuppPubInfo structure contains mutually-known public + information specific to the authentication exchange. The enctype + field is the enctype of the AS reply key as selected according to + [RFC4120]. The as-REQ field contains the DER encoding of the type + AS-REQ [RFC4120] in the request sent from the client to the KDC. + Note that the as-REQ field does not include the wrapping 4 octet + length field when TCP is used. The pk-as-rep field contains the DER + + + +Astrand & Zhu Expires September 5, 2007 [Page 7] + +Internet-Draft PK-INIT Crypto Agility March 2007 + + + encoding of the type PA-PK-AS-REP [RFC4556] in the KDC reply. The + ticket field is filled with the ticket in the KDC reply. The + PkinitSuppPubInfo provides a cryptographic bindings between the pre- + authentication data and the corresponding ticket request and + response, thus addresses the concerns described in Section 3. + + The above ASN.1 structured [SP80056A] HKDF produces a bit string of + length K in bits as the keying material, and then the AS reply key is + the output of random-to-key() [RFC3961] using that returned keying + material as the input. + + The KDF is negotiated between the client and the KDC. The client + sends an unordered set of supported KDFs in the request, and the KDC + picks one from the set in the reply. + + To acomplish this, the AuthPack structure in [RFC4556] is extended as + follows: + + AuthPack ::= SEQUENCE { + pkAuthenticator [0] PKAuthenticator, + clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, + supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier + OPTIONAL, + clientDHNonce [3] DHNonce OPTIONAL, + ..., + supportedKDFs [4] SEQUENCE OF KDFAlgorithmId OPTIONAL, + -- Contains an unordered set of KDFs supported by the + -- client. + ... + } + + KDFAlgorithmId ::= SEQUENCE { + kdf-id [0] OBJECT IDENTIFIER, + -- The object identifier of the KDF + ... + } + + The new field supportedKDFs contains an unordered set of KDFs + supported by the client. + + The KDFAlgorithmId structure contains an object identifier that + identifies a KDF. The algorithm of the KDF and its parameters are + defined by the corresponding specification of that KDF. + + The DHRepInfo structure in [RFC4556] is extended as follows: + + + + + + +Astrand & Zhu Expires September 5, 2007 [Page 8] + +Internet-Draft PK-INIT Crypto Agility March 2007 + + + DHRepInfo ::= SEQUENCE { + dhSignedData [0] IMPLICIT OCTET STRING, + serverDHNonce [1] DHNonce OPTIONAL, + ..., + kdf [2] KDFAlgorithmId OPTIONAL, + -- The KDF picked by the KDC. + ... + } + + The new field kdf in the extended DHRepInfo structure identifies the + KDF picked by the KDC. This kdf field MUST be filled by the + comforming KDC if the supportedKDFs field is present in the request, + and it MUST be one of the KDFs supported by the client as indicated + in the request. Which KDF is chosen is a matter of the local policy + on the KDC. + + If the supportedKDFs field is not present in the request, the kdf + field in the reply MUST be absent. + + If the client fills the supportedKDFs field in the request, but the + kdf field in the reply is not present, the client can deduce that the + KDC is not updated to conform with this specification. In that case, + it is a matter of local policy on the client whether to reject the + reply when the kdf field is absent in the reply. + + Implementations comforming to this specification MUST support id- + pkinit-kdf-ah-sha256. + + +7. Security Considerations + + This document describes negotiation of checksum types, key derivation + functions and other cryptographic functions. If negotiation is done + unauthenticated, care MUST be taken to accept only acceptable values. + + +8. Acknowledgements + + Jeffery Hutzelman reviewed the document and provided suggestions for + improvements. + + +9. IANA Considerations + + There is no action required for IANA. + + +10. References + + + +Astrand & Zhu Expires September 5, 2007 [Page 9] + +Internet-Draft PK-INIT Crypto Agility March 2007 + + +10.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet + X.509 Public Key Infrastructure Certificate and + Certificate Revocation List (CRL) Profile", RFC 3280, + April 2002. + + [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", + RFC 3852, July 2004. + + [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. + + [RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial + Authentication in Kerberos (PKINIT)", RFC 4556, June 2006. + + [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms + (SHA and HMAC-SHA)", RFC 4634, August 2006. + + [SP80056A] + Barker, E., Don, D., and M. Smid, "Recommendation for + Pair-Wise Key Establishment Schemes Using Discrete + Logarithm CryptographyMarch", March 2006. + + [X680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, + Information technology - Abstract Syntax Notation One + (ASN.1): Specification of basic notation. + + [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 + + [RFC1320] Rivest, R., "The MD4 Message-Digest Algorithm", RFC 1320, + April 1992. + + [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, + April 1992. + + [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For + Public Keys Used For Exchanging Symmetric Keys", BCP 86, + RFC 3766, April 2004. + + [X9.42] ANSI, "Public Key Cryptography for the Financial Services + Industry: Agreement of Symmetric Keys Using Discrete + Logarithm Cryptography", 2003. + + [WANG04] Wang, X., Lai, X., Fheg, D., Chen, H., and X. Yu, + "Cryptanalysis of Hash functions MD4 and RIPEMD", + August 2004. + + +Appendix A. PKINIT ASN.1 Module + + KerberosV5-PK-INIT-Agility-SPEC { + iso(1) identified-organization(3) dod(6) internet(1) + security(5) kerberosV5(2) modules(4) pkinit(5) agility (1) + } DEFINITIONS EXPLICIT TAGS ::= BEGIN + + IMPORTS + AlgorithmIdentifier, SubjectPublicKeyInfo + + + +Astrand & Zhu Expires September 5, 2007 [Page 10] + +Internet-Draft PK-INIT Crypto Agility March 2007 + + + FROM PKIX1Explicit88 { iso (1) + identified-organization (3) dod (6) internet (1) + security (5) mechanisms (5) pkix (7) id-mod (0) + id-pkix1-explicit (18) } + -- As defined in RFC 3280. + + Ticket, Int32, Realm, EncryptionKey, Checksum + FROM KerberosV5Spec2 { iso(1) identified-organization(3) + dod(6) internet(1) security(5) kerberosV5(2) + modules(4) krb5spec2(2) } + -- as defined in RFC 4120. + + PKAuthenticator, DHNonce + FROM KerberosV5-PK-INIT-SPEC { + iso(1) identified-organization(3) dod(6) internet(1) + security(5) kerberosV5(2) modules(4) pkinit(5) }; + -- as defined in RFC 4556. + + TD-CMS-DIGEST-ALGORITHMS-DATA ::= SEQUENCE OF + AlgorithmIdentifier + -- Contains the list of CMS algorithm [RFC3852] + -- identifiers that identify the digest algorithms + -- acceptable by the KDC for signing CMS data in + -- the order of decreasing preference. + + TD-CERT-DIGEST-ALGORITHMS-DATA ::= SEQUENCE { + allowedAlgorithms [0] SEQUENCE OF AlgorithmIdentifier, + -- Contains the list of CMS algorithm [RFC3852] + -- identifiers that identify the digest algorithms + -- that are used by the CA to sign the client's + -- X.509 certificate and acceptable by the KDC in + -- the process of validating the client's X.509 + -- certificate, in the order of decreasing + -- preference. + rejectedAlgorithm [1] AlgorithmIdentifier OPTIONAL, + -- This identifies the digest algorithm that was + -- used to sign the client's X.509 certificate and + -- has been rejected by the KDC in the process of + -- validating the client's X.509 certificate + -- [RFC3280]. + ... + } + + PkinitSuppPubInfo ::= SEQUENCE { + enctype [0] Int32, + -- The enctype of the AS reply key. + as-REQ [1] OCTET STRING, + -- This contains the AS-REQ in the request. + + + +Astrand & Zhu Expires September 5, 2007 [Page 11] + +Internet-Draft PK-INIT Crypto Agility March 2007 + + + pk-as-rep [2] OCTET STRING, + -- Contains the DER encoding of the type + -- PA-PK-AS-REP [RFC4556] in the KDC reply. + ticket [3] Ticket, + -- This is the ticket in the KDC reply. + ... + } + + AuthPack ::= SEQUENCE { + pkAuthenticator [0] PKAuthenticator, + clientPublicValue [1] SubjectPublicKeyInfo OPTIONAL, + supportedCMSTypes [2] SEQUENCE OF AlgorithmIdentifier + OPTIONAL, + clientDHNonce [3] DHNonce OPTIONAL, + ..., + supportedKDFs [4] SEQUENCE OF KDFAlgorithmId OPTIONAL, + -- Contains an unordered set of KDFs supported by the + -- client. + ... + } + + KDFAlgorithmId ::= SEQUENCE { + kdf-id [0] OBJECT IDENTIFIER, + -- The object identifier of the KDF + ... + } + + DHRepInfo ::= SEQUENCE { + dhSignedData [0] IMPLICIT OCTET STRING, + serverDHNonce [1] DHNonce OPTIONAL, + ..., + kdf [2] KDFAlgorithmId OPTIONAL, + -- The KDF picked by the KDC. + ... + } + END + + +Authors' Addresses + + Love Hornquist Astrand + Stockholm University + SE-106 91 + Stockholm + Sweden + + Email: ha@it.su.se + + + + +Astrand & Zhu Expires September 5, 2007 [Page 12] + +Internet-Draft PK-INIT Crypto Agility March 2007 + + + Larry Zhu + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + US + + Email: lzhu@microsoft.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Astrand & Zhu Expires September 5, 2007 [Page 13] + +Internet-Draft PK-INIT Crypto Agility March 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + 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, THE IETF TRUST 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). + + + + + +Astrand & Zhu Expires September 5, 2007 [Page 14] + + diff --git a/doc/specifications/draft-ietf-krb-wg-preauth-framework-05.txt b/doc/specifications/draft-ietf-krb-wg-preauth-framework-05.txt new file mode 100644 index 00000000..dc17ceb5 --- /dev/null +++ b/doc/specifications/draft-ietf-krb-wg-preauth-framework-05.txt @@ -0,0 +1,1938 @@ + + +Kerberos Working Group L. Zhu +Internet-Draft Microsoft Corporation +Updates: 4120 (if approved) S. Hartman +Intended status: Standards Track MIT +Expires: September 6, 2007 March 5, 2007 + + + A Generalized Framework for Kerberos Pre-Authentication + draft-ietf-krb-wg-preauth-framework-05 + +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 September 6, 2007. + +Copyright Notice + + Copyright (C) The IETF Trust (2007). + +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 September 6, 2007 [Page 1] + +Internet-Draft Kerberos Preauth Framework March 2007 + + + 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 these 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 + mechanisms, utilize a different key management system, or support a + new key agreement algorithm. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zhu & Hartman Expires September 6, 2007 [Page 2] + +Internet-Draft Kerberos Preauth Framework March 2007 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Conventions and Terminologies 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 . . . . . . . . . . . . . . . . 10 + 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 . . . . . . . . . . . . . . 16 + 6.3. Managing States for the KDC . . . . . . . . . . . . . . . 17 + 6.4. Pre-authentication Set . . . . . . . . . . . . . . . . . . 19 + 6.5. Definition of Kerberos FAST Padata . . . . . . . . . . . . 20 + 6.5.1. FAST and Encrypted Time Stamp . . . . . . . . . . . . 21 + 6.5.2. FAST Armors . . . . . . . . . . . . . . . . . . . . . 21 + 6.5.3. FAST Request . . . . . . . . . . . . . . . . . . . . . 22 + 6.5.4. FAST Response . . . . . . . . . . . . . . . . . . . . 26 + 6.5.5. Error Messages used with Kerberos FAST . . . . . . . . 28 + 6.6. Authentication Strength Indication . . . . . . . . . . . . 28 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 29 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 30 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 30 + Appendix A. ASN.1 module . . . . . . . . . . . . . . . . . . . . 30 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 + Intellectual Property and Copyright Statements . . . . . . . . . . 34 + + + + + + + + + + + + + + + +Zhu & Hartman Expires September 6, 2007 [Page 3] + +Internet-Draft Kerberos Preauth Framework March 2007 + + +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 appropriate. 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 that 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 FAST messages as defined in + Section 6.5. A pre-authentication type carried within FAST is called + a FAST factor. Creating a FAST factor is the easiest path to create + a new pre-authentication mechanism. FAST factors are significantly + easier to analyze from a security standpoint than other pre- + authentication mechanisms. + + Mechanism designers should design FAST factors, instead of new pre- + + + +Zhu & Hartman Expires September 6, 2007 [Page 4] + +Internet-Draft Kerberos Preauth Framework March 2007 + + + authentication mechanisms outside of FAST. + + 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 and Terminologies 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 KDCs in order to authenticate + the client principal. A conversation as defined here consists of all + messages that are necessary to complete the authentication between + the client and the KDC. It is the smallest logic unit for 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, 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 + single conversation. Each exchange accumulates state and hopefully + brings the client closer to a successful authentication. + + + + +Zhu & Hartman Expires September 6, 2007 [Page 5] + +Internet-Draft Kerberos Preauth Framework March 2007 + + + 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 + conversation is trivial. For more complex conversations, 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 conversation + + o Whether the reply key has been replaced in this conversation + + o Whether the contents of the KDC reply can be verified by the + client principal + + + 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 + + + +Zhu & Hartman Expires September 6, 2007 [Page 6] + +Internet-Draft Kerberos Preauth Framework March 2007 + + + 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 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 to encrypt or checksum some data 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 replaced after it is used. + + Initially the reply key has not been replaced. If a mechanism + implements the Replace Reply Key facility discussed in Section 4.3, + 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 conversation. + + + +Zhu & Hartman Expires September 6, 2007 [Page 7] + +Internet-Draft Kerberos Preauth Framework March 2007 + + + 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 that can be verified using a well- + known public key or providing a ticket for the client machine as a + service. + +3.2. Initial Pre-authentication Required Error + + Typically a client starts a conversation 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 + (defined in Section 6.3) for pre-authentication configurations that + use multi-round-trip mechanisms; see Section 3.4 for details of that + case. [[anchor3: Is it desirable to define a new error code for this? + Probably but we need to call out to the WG.]] + + 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 + 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 + + + +Zhu & Hartman Expires September 6, 2007 [Page 8] + +Internet-Draft Kerberos Preauth Framework March 2007 + + + 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 that 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 conforming to + this specification 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 or authentication set 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 + 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 + + + +Zhu & Hartman Expires September 6, 2007 [Page 9] + +Internet-Draft Kerberos Preauth Framework March 2007 + + + 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 an 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_MORE_PREAUTH_DATA_NEEDED 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 + response, encrypting it in the current pre-authentication reply key. + + +4. Pre-Authentication Facilities + + Pre-Authentication mechanisms can be thought of as providing various + + + +Zhu & Hartman Expires September 6, 2007 [Page 10] + +Internet-Draft Kerberos Preauth Framework March 2007 + + + 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. If the FAST factor approach is + used, it is likely that one or a small number of facilities can be + provided by a single mechanism without complicating the security + analysis. + + 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 + 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. + + + +Zhu & Hartman Expires September 6, 2007 [Page 11] + +Internet-Draft Kerberos Preauth Framework March 2007 + + + 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 [KRB-WG.SAM]. 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 + 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 considered as an inner level. As + + + +Zhu & Hartman Expires September 6, 2007 [Page 12] + +Internet-Draft Kerberos Preauth Framework March 2007 + + + with the outer level, one authentication set or mechanism is + typically chosen for client authentication, along with auxiliary + mechanisms such as KDC cookies, and other mechanisms are ignored. + [[anchor6: Containers like this need more thought. For example if + you are constructing an authentication set do you expect to use a + strengthen reply key mechanism in conjunction with something else, do + you include the something else in the hint of the strengthen + mechanism or as its own entry. It's easier to configure and express + the authentication set as its own entry. However if you do that' the + composition of the mechanisms looks in practice than it appears in + the authentication set.]] 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 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. [[anchor7: Why? I suspect there's an obvious + attack here but I need to work through it and add detail. In + particular, it seems that a checksum at the end should be + sufficient.]]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 + + + +Zhu & Hartman Expires September 6, 2007 [Page 13] + +Internet-Draft Kerberos Preauth Framework March 2007 + + + 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. + +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 needs information such as 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 (as defined in + Section 6.4). + + 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 + + + +Zhu & Hartman Expires September 6, 2007 [Page 14] + +Internet-Draft Kerberos Preauth Framework March 2007 + + + applicable to any FAST factor that provides 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 + 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. + + As discussed in Section 6.3, there is no guarantee that a client will + use the same KDCs for all messages in a conversation. The mechanism + specification needs to show why the mechanism is secure in this + situation. The hardest problem to deal with, especially for + challenge/response mechanisms is to make sure that the same response + cannot be replayed against two KDCs while allowing the client to talk + to any KDC. + + +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. + 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 + assuming that the string_to_key() function [RFC3961] uses all its + input evenly. + + + + +Zhu & Hartman Expires September 6, 2007 [Page 15] + +Internet-Draft Kerberos Preauth Framework March 2007 + + + 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(). + + KRB-FX-CF2() combines two protocol keys based on the pseudo-random() + function defined in [RFC3961]. + + Given two input keys, K1 and K2, where K1 and K2 can be of two + different enctypes, the output key of KRB-FX-CF2(), K3, is derived as + follows: + + KRB-FX-CF2(protocol key, protocol key, octet string, + octet string) -> (protocol key) + + PRF+(K1, pepper1) -> octet-string-1 + PRF+(K2, pepper2) -> octet-string-2 + KRB-FX-CF2(K1, K2, pepper1, pepper2) -> + random-to-key(octet-string-1 ^ octet-string-2) + + Where ^ denotes the exclusive-OR operation. PRF+() is defined as + follows: + + PRF+(protocol key, octet string) -> (octet string) + + PRF+(key, shared-info) -> pseudo-random( key, 1 || shared-info ) || + pseudo-random( key, 2 || shared-info ) || + pseudo-random( key, 3 || shared-info ) || ... + + Here the counter value 1, 2, 3 and so on are encoded as a one-octet + integer. The pseudo-random() operation is specified by the enctype + of the protocol key. PRF+() uses the counter to generate enough bits + as needed by the random-to-key() [RFC3961] function for the + encryption type specified for the resulting key; unneeded bits are + removed from the tail. + + Mechanism designers MUST specify the pepper values when combining two + keys using KRB-FX-CF2(). The pepper1 and pepper2 MUST be distinct so + that if the two keys being combined are the same, the resulting key + is not a trivial key. + +6.2. Protecting Requests/Responses + + Mechanism designers SHOULD protect clear text portions of pre- + authentication data. 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 [RFC4120] was to avoid encrypting more of the + + + +Zhu & Hartman Expires September 6, 2007 [Page 16] + +Internet-Draft Kerberos Preauth Framework March 2007 + + + 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. + + If there are more than one roundtrip for an authentication exchange, + mechanism designers need to allow either the client or the KDC to + provide a checksum of all the messages exchanged on the wire in the + conversation, and the checksum 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 that + is 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. + + Note that data used by FAST factors (defined in Section 6.5) are + encrypted in a protected channel, in most cases, therefore no un- + authenticated-text issue is associated with these mechanisms. + However mechanism designers MUST consider the case carefully when the + KDC authentication is not provided by Kerberos FAST. + +6.3. Managing States for the KDC + + [[anchor11: Kerberos is stateless today. We can either maintain that + and store all the state in a cookie or change that and require + clients go to the same KDC for future requests. Consider how this + interacts with proxies. The rest of this section assumes we maintain + the current model.]] Kerberos KDCs are stateless. There is no + requirement that clients will choose the same KDC for the second + request in a conversation. Proxies or other intermediate nodes may + also influence KDC selection. So, each request from a client to a + KDC must include sufficient information that the KDC can regenerate + any needed state. This is accomplished by giving the client a + potentially long opaque cookie in responses to include in future + requests in the same conversation. The KDC MAY respond that a + conversation is too old and needs to restart by responding with a + KDC_ERR_PREAUTH_EXPIRED error. + + + +Zhu & Hartman Expires September 6, 2007 [Page 17] + +Internet-Draft Kerberos Preauth Framework March 2007 + + + KDC_ERR_PREAUTH_EXPIRED TBA + + When a client receives 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 needs 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. This padata is sent by the KDC when the KDC + requires state for a future transaction. The client includes this + opaque token in the next message in the conversation. The token may + be relatively large; clients MUST be prepared for tokens somewhat + larger than the size of all messages in a conversation. + + PA_FX_COOKIE TBA + -- Stateless cookie that is not tied to a specific KDC. + + 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 content of the PA_FX_COOKIE padata is a local matter of the KDC. + However the KDC MUST construct the token in such a manner that a + malicious client cannot subvert the authentication process by + manipulating the token. The KDC implementation needs to consider + expiration of tokens, key rollover and other security issues in token + design. The content of the Cookie field is likely specific to the + pre-authentication mechanisms used to authenticate the client. In + order to compute the finished field in the KrbFastRespons structure + as defined in Section 6.5.4, all the previous messages in the + conversation MUST be included in the Cookie. If a client + authentication response can be replayed to multiple KDCs via the + PA_FX_COOKIE mechanism, an expiration in the Cookie is RECOMMENDED to + prevent the response being presented indefinitely. + + + +Zhu & Hartman Expires September 6, 2007 [Page 18] + +Internet-Draft Kerberos Preauth Framework March 2007 + + + 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 + +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: + + 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. [[anchor12: What if you + have a padata type as the first member of a set that requires a + challenge. For example SAM assumes that the KDC sends a challenge to + the client initially. That's not a pa-hint; that's a pa-value. How + do you convey that data with this?]] [[anchor13: The PA-SET appears + only in the first message from the KDC to the client? In particular, + the client should not be prepared for the future authentication + mechanisms to change as the conversation progresses. I think this is + correct; we should discuss and if the WG agrees the text should + reflect this.]] + + + + +Zhu & Hartman Expires September 6, 2007 [Page 19] + +Internet-Draft Kerberos Preauth Framework March 2007 + + + 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. + + [[anchor14: It's much easier to design UIs if you can determine ahead + of time what all the elements of your dialogue will need to be. If + we mandate that the pa-hints need to be sufficient that you can + determine what information you will require from a user ahead of time + we can simplify the UI for login. I propose that we make this + requirement. WG agreement required.]] + +6.5. Definition of Kerberos FAST Padata + + The cipher text exposure when using the encrypted timestamp pre- + authentication data is a security concern for Kerberos. Attackers + can launch 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. A pre-authentication + data element used within FAST is called a FAST factor. A FAST factor + captures the minimal work required for extending Kerberos to support + a new authentication scheme. + + A FAST factor MUST NOT be used outside of FAST unless its + specification explicitly allows so. The typed holes in FAST messages + can also be used as generic holes for other padata 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. + + FAST factors that are pre-authentication mechanisms MUST meet the + requirements in Section 5. + + 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 armoring TGT can be a cross-realm TGT. The rest of + + + +Zhu & Hartman Expires September 6, 2007 [Page 20] + +Internet-Draft Kerberos Preauth Framework March 2007 + + + this section describes the types of armors and the messages used by + FAST. + +6.5.1. FAST and Encrypted Time Stamp + + FAST provides new behavior for encrypted time stamp [RFC4120]. When + used as a FAST factor, this mechanism provides stronger security + guarantees. + + 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.4. 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 explanation why the security requirements are met. + +6.5.2. 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 armor types are currently defined : + + + FX_FAST_ARMOR_AP_REQUEST 1 + FX_FAST_ARMOR_KEY_ID 2 + + Conforming implementations MUST implement the + FX_FAST_ARMOR_AP_REQUEST armor type. + + + + + + +Zhu & Hartman Expires September 6, 2007 [Page 21] + +Internet-Draft Kerberos Preauth Framework March 2007 + + +6.5.2.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. The armor key is the subkey in the AP-REQ authenticator. + + The ticket in the AP-REQ MUST be for the TGT service of the target + KDC. Here are 3 ways in the decreasing preference order how an armor + TGT SHOULD be obtained: + + 1. If the client is authenticating from a host machine whose + Kerberos realm has a trust path to the client's realm, the host + machine obtains a TGT to the client's realm, and this ticket is + the armor ticket. + + 2. Otherwise, the client's host machine cannot obtain a host ticket + strictly based on RFC4120, but the KDC has a signing asymmetric + key that the client can verify its binding with the expected KDC, + the client then can use anonymous PKINIT to obtain a anonymous + TGT, and use that TGT to as the armor ticket. + + 3. Otherwise, the client uses anonymous PKINIT to get an anonymous + TGT without KDC authentication. Note that this mode of operation + is vulnerable to man-in-the-middle attacks at the time of + obtaining the initial anonymous TGT. + + Because the KDC does not know if the client is able to trust the + ticket it has, the KDC and client MUST initialize the pre- + authentication state to an unverified KDC. + +6.5.2.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. [[anchor19: Do we believe this has sufficient value to + specify or do we want to assume all armor comes from tickets?]] + +6.5.3. FAST Request + + A padata type PA_FX_FAST is defined for the Kerberos FAST pre- + authentication padata. The corresponding padata-value field + + + +Zhu & Hartman Expires September 6, 2007 [Page 22] + +Internet-Draft Kerberos Preauth Framework March 2007 + + + [RFC4120] contains the DER encoding of the ASN.1 type PA-FX-FAST- + REQUEST. + + PA_FX_FAST TBA + -- Padata type for Kerberos FAST + + 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, the checksum + -- type is the required checksum type for the enctype of + -- the armor key, and the key usage number is + -- KEY_USAGE_FAST_REA_CHKSUM. + enc-fast-req [3] EncryptedData, -- KrbFastReq -- + -- The encryption key is the armor key, and the key usage + -- number is KEY_USAGE_FAST_ENC. + ... + } + + KEY_USAGE_FAST_REA_CHKSUM TBA + KEY_USAGE_FAST_ENC 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 KEY_USAGE_FAST_ARMOR. + + KEY_USAGE_FAST_ARMOR TBA + + The armor key is identified as follows: + + o When a KrbFastAmoredReq is included in an AS request, the armor + field MUST be present in the initial AS-REQ in a conversation, + specifying the armor key being used. The armor field MUST be + absent in any subsequent AS-REQ of the same conversation. In + other words, the armor key is specified explicitly in the initial + AS-REQ in a conversation, and implicitly thereafter. + + + + +Zhu & Hartman Expires September 6, 2007 [Page 23] + +Internet-Draft Kerberos Preauth Framework March 2007 + + + o 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: + + KrbFastReq ::= SEQUENCE { + fast-options [0] FastOptions, + -- Additional options. + padata [1] SEQUENCE OF PA-DATA, + -- padata typed holes. + crealm [2] Realm OPTIONAL, + cname [3] PrincipalName OPTIONAL, + -- Contains the client realm and the client name. + -- If present, the client name and realm in the + -- AS_REQ KDC-REQ-BODY [RFC4120] MUST be ignored. + ... + } + + 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. KDCs conforming to this specification ignores + + + +Zhu & Hartman Expires September 6, 2007 [Page 24] + +Internet-Draft Kerberos Preauth Framework March 2007 + + + 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 messages exchanged between the + client and the KDC. 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. Hence this + option is set by the client if it wishes to conceal 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 contact the AS specified in the error + response in order to complete client referrals. The kdc-referrals + option is designed to minimize the number of messages that need to + be processed by the client. This option is useful when, for + example, the client may contact the KDC via a satellite link that + has high latency, or the client has limited computational + capabilities. 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. The + KDC can ignore kdc-referrals option when it does not understand it + or it does not allow this option 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 of [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 crealm field and the cname field identify the client principal in + the ticket request. If either the crealm field or the cname field is + present, the corresponding crealm or cname field in the KDC-REQ-BODY + [RFC4120] of an AS-REQ MUST be ignored. The client can fill in these + fields in the KrbFastReq structure and leaves the cname field and the + crealm field KDC-REQ-BODY absent, thus conceals its identity in the + AS-REQ. + + + +Zhu & Hartman Expires September 6, 2007 [Page 25] + +Internet-Draft Kerberos Preauth Framework March 2007 + + +6.5.4. 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. + + 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 KEY_USAGE_FAST_REP. + ... + } + KEY_USAGE_FAST_REP 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 KEY_USAGE_FAST_REP. + + The Kerberos client who does not receive a PA-FX-FAST-REPLY in the + KDC response MUST support a local policy that rejects the request. + Clients MAY also support policies that fall back to other mechanisms + or that do not use pre-authentication when FAST is unavailable. It + is important to consider the potential downgrade attacks when + deploying such a 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. + finished [2] KrbFastFinished 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. + ... + + + +Zhu & Hartman Expires September 6, 2007 [Page 26] + +Internet-Draft Kerberos Preauth Framework March 2007 + + + } + + 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 advancing the exchange + specific for the FAST factors. They can also be used as generic + typed-holes for protocol extensibility. + + The finished field contains a KrbFastFinished structure. It is + filled by the KDC in the final message in the conversation; 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. + + The KrbFastFinished structure contains the following information: + + KrbFastFinished ::= 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 + -- KEY_USAGE_FAST_FINISHED. + 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. + ... + } + KEY_USAGE_FAST_REP_KEY TBA + KEY_USAGE_FAST_FINISHED TBA + + The timestamp and usec fields represent the time on the KDC when the + reply ticket 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. + + + + +Zhu & Hartman Expires September 6, 2007 [Page 27] + +Internet-Draft Kerberos Preauth Framework March 2007 + + + The rep-key-package field, if present, contains the reply key + encrypted using the client key unless otherwise specified. The key + usage number is KEY_USAGE_FAST_REP_KEY. + + 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 identify the authenticated client. + + The checksum field contains a checksum of all the messages in the + conversation prior to the containing message (the containing message + is excluded). The checksum key is the ticket session key of the + reply ticket, the checksum type is the required checksum type of the + enctype of that key, and the key usage number is + KEY_USAGE_FAST_FINISHED. + +6.5.5. Error Messages used with Kerberos FAST + + If the Kerberos FAST padata was included in the request, unless + otherwise specified, the e-data field of the KRB-ERROR message + [RFC4120] contains the ASN.1 DER encoding of the type METHOD-DATA + [RFC4120], where a PA_FX_FAST padata element is included and it + contains the DER encoding of the type PA-FX-FAST-REPLY. If the + e-data field of the KRB-ERROR message contains the DER encoding of a + TYPED-DATA, a typed data element TD_FX_FAST SHOULD be included in the + e-data if the Kerberos FAST padata is included in the request, and + the corresponding data-value field [RFC4120] contains the ASN.1 DER + encoding of the type PA-FX-FAST-REPLY. In other words, the typed + data element type TD_FX_FAST is allocated to encapsulate the FAST + reply message in the error responses. If a PA-FX-FAST-REPLY is not + included in the error reply, it is a matter of the local policy on + the client to accept the information in the error message without + integrity protection. [[anchor21: Why do we want padata in arbitrary + error responses? What if the KDC cannot generate a fast reply + because for example no armor nor state cookie was included in a + request? Also, we need to confirm that the WG is OK with a pre- + authentication specification changing error returns for unrelated + errors.]] + + TD_FX_FAST TBA + -- Typed data element type for Kerberos FAST + +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 + + + +Zhu & Hartman Expires September 6, 2007 [Page 28] + +Internet-Draft Kerberos Preauth Framework March 2007 + + + 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. The evaluation policy is + "Specification Required". + + +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 + 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 clear text introduced by the encrypted timestamp + FAST factor. + + + + + +Zhu & Hartman Expires September 6, 2007 [Page 29] + +Internet-Draft Kerberos Preauth Framework March 2007 + + +9. Acknowledgements + + Several 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. + + [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. + + [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. + + [KRB-WG.SAM] + Hornstein, K., Renard, K., Neuman, C., and G. Zorn, + "Integrating Single-use Authentication Mechanisms with + Kerberos", draft-ietf-krb-wg-kerberos-sam-02.txt (work in + progress), October 2003. + + [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 { + + + +Zhu & Hartman Expires September 6, 2007 [Page 30] + +Internet-Draft Kerberos Preauth Framework March 2007 + + + 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. + ... + } + + 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, the checksum + -- type is the required checksum type for the enctype of + -- the armor key, and the key usage number is + -- KEY_USAGE_FAST_REA_CHKSUM. + enc-fast-req [3] EncryptedData, -- KrbFastReq -- + -- The encryption key is the armor key, and the key usage + -- number is KEY_USAGE_FAST_ENC. + ... + } + + KrbFastArmor ::= SEQUENCE { + armor-type [1] Int32, + -- Type of the armor. + armor-value [2] OCTET STRING, + -- Value of the armor. + ... + + + +Zhu & Hartman Expires September 6, 2007 [Page 31] + +Internet-Draft Kerberos Preauth Framework March 2007 + + + } + + KrbFastReq ::= SEQUENCE { + fast-options [0] FastOptions, + -- Additional options. + padata [1] SEQUENCE OF PA-DATA, + -- padata typed holes. + crealm [2] Realm OPTIONAL, + cname [3] PrincipalName OPTIONAL, + -- Contains the client realm and the client name. + -- If present, the client name and realm in the + -- AS_REQ KDC-REQ-BODY [RFC4120] MUST be ignored. + ... + } + + FastOptions ::= KerberosFlags + -- reserved(0), + -- anonymous(1), + -- kdc-referrals(16) + + 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 KEY_USAGE_FAST_REP. + ... + } + + KrbFastResponse ::= SEQUENCE { + padata [1] SEQUENCE OF PA-DATA, + -- padata typed holes. + finished [2] KrbFastFinished 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. + ... + } + + KrbFastFinished ::= SEQUENCE { + timestamp [1] KerberosTime, + usec [2] Microseconds, + -- timestamp and usec represent the time on the KDC when + -- the reply was generated. + + + +Zhu & Hartman Expires September 6, 2007 [Page 32] + +Internet-Draft Kerberos Preauth Framework March 2007 + + + 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 + -- KEY_USAGE_FAST_FINISHED. + 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 September 6, 2007 [Page 33] + +Internet-Draft Kerberos Preauth Framework March 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + 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, THE IETF TRUST 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 September 6, 2007 [Page 34] + + diff --git a/doc/specifications/draft-ietf-krb-wg-rfc1510ter-04.txt b/doc/specifications/draft-ietf-krb-wg-rfc1510ter-04.txt new file mode 100644 index 00000000..5e87195e --- /dev/null +++ b/doc/specifications/draft-ietf-krb-wg-rfc1510ter-04.txt @@ -0,0 +1,6385 @@ + + +INTERNET-DRAFT Tom Yu +draft-ietf-krb-wg-rfc1510ter-04.txt MIT +Expires: 06 September 2007 05 March 2007 + + 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 IETF Trust (2007). + +Abstract + + This document specifies version 5 of the Kerberos network + authentication protocol. It obsoletes RFC 4120, and in addition to + providing a detailed description of the protocol, it describes a + framework to allow for extensions to be made to the protocol without + creating interoperability problems. + + + + + + + + + + + + +Yu Expires: Sep 2007 [Page 1] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + +Table of Contents + + Status of This Memo .............................................. 1 + Copyright Notice ................................................. 1 + Abstract ......................................................... 1 + Table of Contents ................................................ 2 + 1. Introduction ................................................. 4 + 1.1. Kerberos Protocol Overview ................................. 4 + 1.2. Document Organization ...................................... 5 + 2. Compatibility Considerations ................................. 6 + 2.1. Extensibility .............................................. 6 + 2.2. Compatibility with RFC 1510 ................................ 6 + 2.3. Backwards Compatibility .................................... 6 + 2.4. Sending Extensible Messages ................................ 7 + 2.5. Criticality ................................................ 7 + 2.6. Authenticating Cleartext Portions of Messages .............. 8 + 2.7. Capability Negotiation ..................................... 9 + 2.8. Strings .................................................... 10 + 3. Use of ASN.1 in Kerberos ..................................... 10 + 3.1. Module Header .............................................. 11 + 3.2. Top-Level Type ............................................. 11 + 3.3. Previously Unused ASN.1 Notation (informative) ............. 12 + 3.4. New Types .................................................. 12 + 4. Basic Types .................................................. 13 + 4.1. Constrained Integer Types .................................. 13 + 4.2. KerberosTime ............................................... 14 + 4.3. KerberosString ............................................. 14 + 4.4. Language Tags .............................................. 15 + 4.5. KerberosFlags .............................................. 15 + 4.6. Typed Holes ................................................ 16 + 4.7. HostAddress and HostAddresses .............................. 16 + 5. Principals ................................................... 18 + 5.1. Name Types ................................................. 18 + 5.2. Principal Type Definition .................................. 19 + 5.3. Principal Name Reuse ....................................... 20 + 5.4. Best Common Practice Recommendations for the Processing + of Principal Names Consisting of Internationalized + Domain Names: .......................................... 20 + 5.5. Realm Names ................................................ 21 + 5.6. Best Common Practice Recommendations for the Processing + of Internationalized Domain-Style Realm Names: ......... 21 + 5.7. Printable Representations of Principal Names ............... 22 + 5.8. Ticket-Granting Service Principal .......................... 22 + 6. Types Relating to Encryption ................................. 23 + 6.1. Assigned Numbers for Encryption ............................ 23 + 6.2. Which Key to Use ........................................... 26 + 6.3. EncryptionKey .............................................. 27 + 6.4. EncryptedData .............................................. 27 + 6.5. Checksums .................................................. 28 + 7. Tickets ...................................................... 30 + 7.1. Timestamps ................................................. 31 + +Yu Expires: Sep 2007 [Page 2] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 7.2. Ticket Flags ............................................... 32 + 7.3. Transited Realms ........................................... 37 + 7.4. Authorization Data ......................................... 37 + 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.4. KDC-REP .................................................... 56 + 8.5. Reply Validation ........................................... 60 + 8.6. IP Transports .............................................. 60 + 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 ................................................... 72 + 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) ...............109 + C. Kerberos History (Informative) ...............................110 + D. Notational Differences from [RFC4120] ........................111 + Normative References .............................................111 + Informative References ...........................................112 + Author's Address .................................................113 + Full Copyright Statement .........................................113 + Intellectual Property ............................................113 + + + + + + + + + + + + +Yu Expires: Sep 2007 [Page 3] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + +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 in [RFC1510] and + [RFC4120], 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. + + 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 [RFC2119]. + +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 + +Yu Expires: Sep 2007 [Page 4] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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 + 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: Sep 2007 [Page 5] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + +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: Sep 2007 [Page 6] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + [RFC4120]. 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: Sep 2007 [Page 7] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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: Sep 2007 [Page 8] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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: Sep 2007 [Page 9] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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: Sep 2007 [Page 10] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + [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: Sep 2007 [Page 11] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + -- 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 + [RFC4120], 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: Sep 2007 [Page 12] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + +3.4. New Types + + This document defines a number of ASN.1 types which are new since + [RFC4120]. 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 [RFC4120] 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 + [RFC4120]. + + -- 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 [RFC4120], but this + document allows for 64-bit sequence numbers. + + +Yu Expires: Sep 2007 [Page 13] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + -- nonces + Nonce ::= UInt64 + + Likewise, nonces were constrained to 32 bits in [RFC4120], 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 [RFC4013]. 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: Sep 2007 [Page 14] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + -- 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 [RFC4646] 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 + +Yu Expires: Sep 2007 [Page 15] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + truncated. + +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. + + + + + + + + + + +Yu Expires: Sep 2007 [Page 16] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + + addr-type | meaning + __________|______________ + 2 | IPv4 + 3 | directional + 12 | DECnet + 20 | NetBIOS + 24 | IPv6 + + + +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 [RFC4291] 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). + + + + +Yu Expires: Sep 2007 [Page 17] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + +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 + 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: Sep 2007 [Page 18] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + -- 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 + -- reserved principal names [krb-wg-naming] + nt-wellknown NameType ::= 11 + + +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 + + +Yu Expires: Sep 2007 [Page 19] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + name-string + The "name-string" encodes a sequence of components that form a + 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 + +Yu Expires: Sep 2007 [Page 20] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + string preparation methods. + + 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) + + +Yu Expires: Sep 2007 [Page 21] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + - for each component (perform all steps): + + 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 [RFC4120], 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: Sep 2007 [Page 22] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + -- 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 [RFC3961]. + +6.1.1. EType + + EType is the integer type for assigned numbers for encryption + algorithms. Defined in [RFC3961]. + + + + + + + + + + + + +Yu Expires: Sep 2007 [Page 23] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + -- 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 [RFC3961]. + + + + + + + + + + + + + + + + +Yu Expires: Sep 2007 [Page 24] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + -- 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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Yu Expires: Sep 2007 [Page 25] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + -- 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 + + -- IAKERB + ku-iakerb-finished KeyUsage ::= 41 + + + +6.2. Which Key to Use + + + + + + + + + + + + + + + + + + + + + + +Yu Expires: Sep 2007 [Page 26] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + -- 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 + [RFC3961]. + + 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: Sep 2007 [Page 27] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + + -- "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: Sep 2007 [Page 28] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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 [RFC3961] + + 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: Sep 2007 [Page 29] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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: Sep 2007 [Page 30] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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: Sep 2007 [Page 31] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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 RFC4120 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: Sep 2007 [Page 32] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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 + + [ RFC4120 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 + + [ RFC4120 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: Sep 2007 [Page 33] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + +7.2.4. Renewable Tickets + + [ adapted RFC4120 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 + + [ RFC4120 2.4. ] + + +Yu Expires: Sep 2007 [Page 34] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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 + + [ RFC4120 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: Sep 2007 [Page 35] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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 + + [ RFC4120 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: Sep 2007 [Page 36] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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 + + [ RFC4120 2.7., plus new stuff ] + +7.4. Authorization Data + + [ RFC4120 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: Sep 2007 [Page 37] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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: Sep 2007 [Page 38] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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: Sep 2007 [Page 39] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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: Sep 2007 [Page 40] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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: Sep 2007 [Page 41] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + +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: Sep 2007 [Page 42] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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 + } + + + + + + + + + + + + +Yu Expires: Sep 2007 [Page 43] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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: Sep 2007 [Page 44] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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: Sep 2007 [Page 45] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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: Sep 2007 [Page 46] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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: + + + + + + + + + + + +Yu Expires: Sep 2007 [Page 47] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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, + ... + } + + 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: Sep 2007 [Page 48] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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 + +Yu Expires: Sep 2007 [Page 49] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + if the client does not know that the KDC supports the extensibility + 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 + +Yu Expires: Sep 2007 [Page 50] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + ciphertext given to a potential attacker, KDCs MAY send the same + response generated when the request was first handled. KDCs MUST + 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: Sep 2007 [Page 51] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + +8.3.2.4. Checking For Revoked or Invalid Tickets + + [ RFC4120 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 RFC4120... 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: Sep 2007 [Page 52] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + +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: Sep 2007 [Page 53] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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 RFC4120 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: Sep 2007 [Page 54] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + +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: Sep 2007 [Page 55] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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: Sep 2007 [Page 56] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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: Sep 2007 [Page 57] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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: Sep 2007 [Page 58] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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: Sep 2007 [Page 59] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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 + + [ RFC4120 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: Sep 2007 [Page 60] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + +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: Sep 2007 [Page 61] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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: Sep 2007 [Page 62] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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: Sep 2007 [Page 63] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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: Sep 2007 [Page 64] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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: Sep 2007 [Page 65] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + +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: Sep 2007 [Page 66] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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: Sep 2007 [Page 67] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + +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: Sep 2007 [Page 68] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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: Sep 2007 [Page 69] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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: Sep 2007 [Page 70] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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: Sep 2007 [Page 71] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + +12.2. Replays + +12.3. Principal Name Reuse + + See Section 5.3. + +12.4. Password Guessing + +12.5. Forward Secrecy + + [from RFC4120 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: Sep 2007 [Page 72] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + +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 RFC 4120. 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: Sep 2007 [Page 73] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + -- 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: Sep 2007 [Page 74] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + -- 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: Sep 2007 [Page 75] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + -- 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 + -- reserved principal names [krb-wg-naming] + nt-wellknown NameType ::= 11 + + + 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 } + + + + + + + + + + + + + +Yu Expires: Sep 2007 [Page 76] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + Realm { StrType } ::= KerberosString (StrType) + + -- IA5 only + RealmIA5 ::= Realm { KerberosStringIA5 } + + -- IA5 excluded + RealmExt ::= Realm { KerberosStringExt } + + -- Either + RealmEither ::= Realm { KerberosString } + + + + 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: Sep 2007 [Page 77] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + -- 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: Sep 2007 [Page 78] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + -- 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 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Yu Expires: Sep 2007 [Page 79] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + -- 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 + + -- IAKERB + ku-iakerb-finished KeyUsage ::= 41 + + + + + + + + + + + + + + + + + + + + + + + + + + +Yu Expires: Sep 2007 [Page 80] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + -- 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: Sep 2007 [Page 81] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + + -- "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: Sep 2007 [Page 82] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + -- 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: Sep 2007 [Page 83] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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: Sep 2007 [Page 84] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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: Sep 2007 [Page 85] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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: Sep 2007 [Page 86] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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 + + + + + + + + + + + + + +Yu Expires: Sep 2007 [Page 87] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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 } + } + + + 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: Sep 2007 [Page 88] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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: Sep 2007 [Page 89] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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: Sep 2007 [Page 90] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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: Sep 2007 [Page 91] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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: Sep 2007 [Page 92] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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: Sep 2007 [Page 93] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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: Sep 2007 [Page 94] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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: Sep 2007 [Page 95] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + -- 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: Sep 2007 [Page 96] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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: Sep 2007 [Page 97] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + -- 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: Sep 2007 [Page 98] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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, + ... + } + + + + + + +Yu Expires: Sep 2007 [Page 99] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + -- + -- *** Application messages + -- + + + 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 + } + + + + + + + +Yu Expires: Sep 2007 [Page 100] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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 + } + + + 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: Sep 2007 [Page 101] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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 + } + + + TGT-REQ ::= [APPLICATION 16] SEQUENCE { + pvno [0] INTEGER (5), + msg-type [1] INTEGER (16), + sname [2] PrincipalName OPTIONAL, + srealm [3] Realm OPTIONAL, + ... + } + + + + + +Yu Expires: Sep 2007 [Page 102] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + -- + -- *** Error messages + -- + + + ErrCode ::= Int32 + + KRB-ERROR ::= CHOICE { + rfc1510 KRB-ERROR-1510, + ext KRB-ERROR-EXT + } + + + 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 + } + + + + + + + + + + + + + + + + + + + + + + + + +Yu Expires: Sep 2007 [Page 103] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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 + } + + + td-dh-parameters TDType ::= int32 : 109 + -- iakerb + td-iakerb-finished TDType ::= int32 : 110 + -- pkinit-alg-agility + td-cms-data-digest-algorithms TDType ::= int32 : 111 + -- pkinit-alg-agility + td-cert-digest-algorithms TDType ::= int32 : 112 + + + + + + + + + + +Yu Expires: Sep 2007 [Page 104] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + -- + -- *** 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: Sep 2007 [Page 105] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + -- 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: Sep 2007 [Page 106] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + -- 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: Sep 2007 [Page 107] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + -- 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 + -- [krb-wg-naming] + krb-ap-err-wellknown-principal-name-unsupported ErrCode ::= 82 + -- [krb-wg-naming] + krb-ap-err-wellknown-realm-name-not-supported ErrCode ::= 83 + -- [krb-wg-naming] + krb-ap-err-reserved-principal-name-unknown ErrCode ::= 84 + -- IAKERB proxy could not find a KDC + krb-ap-err-iakerb-kdc-not-found ErrCode ::= 85 + -- KDC did not respond to IAKERB proxy + +Yu Expires: Sep 2007 [Page 108] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + krb-ap-err-iakerb-kdc-no-response ErrCode ::= 86 + + + END + + +B. Kerberos and Character Encodings (Informative) + + [adapted from RFC4120 5.2.1] + + 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 + +Yu Expires: Sep 2007 [Page 109] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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 + 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 RFC4120 "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. + +Yu Expires: Sep 2007 [Page 110] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + 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 [RFC4120] + + [ possible point for discussion ] + + [RFC4120] uses notational conventions slightly different from this + document. As a derivative of RFC 1510, the text of [RFC4120] 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. [RFC4120] 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 + + [RFC2119] + S. Bradner, "Key words for use in RFC's to Indicate Requirement + Levels", RFC 2119, March 1997. + + [RFC3490] + P. Faltstrom, P. Hoffman, A. Costello, "Internationalizing + Domain Names in Applications (IDNA)", RFC 3490, March 2003. + + [RFC3961] + K. Raeburn, "Encryption and Checksum Specifications for Kerberos + 5", RFC 3961, February 2005. + + [RFC4013] + Kurt D. Zeilenga, "SASLprep: Stringprep profile for user names + and passwords", RFC 4013, February 2005. + + [RFC4291] + R. Hinden and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, February 2006. + + [RFC4646] + A. Philllips and M. Davis, "Tags for Identifying Languages", + RFC 4646, January 2001. + + +Yu Expires: Sep 2007 [Page 111] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + [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. + + [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. + + + [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. + + [ISO8859-1] + "Information technology -- 8-bit single-byte coded graphic + character sets -- Part 1: Latin alphabet No. 1", + ISO/IEC 8859-1:1998. + + [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. + + +Yu Expires: Sep 2007 [Page 112] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + + [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 + 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. + + [RFC4120] + C. Neuman, T. Yu, S. Hartman, K. Raeburn, "The Kerberos Network + Authentication Service (V5)", RFC 4120, July 2005. + +Author's Address + + Tom Yu + 77 Massachusetts Ave + Cambridge, MA 02139 + USA + tlyu@mit.edu + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + 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, THE IETF TRUST 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. + + +Yu Expires: Sep 2007 [Page 113] + +Internet-Draft rfc1510ter-04 05 Mar 2007 + +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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Yu Expires: Sep 2007 [Page 114] + + -- 2.11.4.GIT