Kerberos Working Group Jonathan Trostle INTERNET-DRAFT Cisco Systems Category: Standards Track Mike Swift University of WA John Brezak Microsoft Bill Gossman Cisco Systems Nicolas Williams Sun Microsystems Kerberos Set/Change Password: Version 2 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [RFC2026]. 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 draft expires on December 31st, 2001. Please send comments to the authors. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This proposal specifies an extensible protocol for setting keys and changing the passwords of Kerberos [RFC1510] principals. The protocol support a single operation per-session when run over UDP, or Trostle et. al. [Page 1] DRAFT Kerberos Set/Change Password v2 Expires November 2003 multiple operations per-session when run over TCP. Clients can change their own principal's password or keys or they can change other principals', provided that they are properly authorized to do so. Additional related features include the ability to determine the known aliases of Kerberos principals. This feature will facilitate the implementation of aliasing of target principal names in KDC requests by allowing principals to know which names are aliases of their canonical principal names. Principal aliasing is needed to properly support the use of aliases and short-form names by users without requiring that clients canonicalize principal names, possibly using insecure name services in the process. This protocol uses IETF language tags [RFC3066] to negotiate proper localization of help messages intended for users. UTF-8 is used throughout for strings, suitably constrained, where necessary, by the minor version of Kerberos V in use by clients and servers. 1. Introduction Kerberos lacks a single, standard protocol for changing passwords and keys. While several vendor-specific protocols exist for changing Kerberos passwords/keys, none are properly internationalized. This document defines a protocol that is somewhat backward-compatible with the "kpasswd" protocol, version 1 [KPASSWDv1] and a derivative defined in [RFC3244] that uses more or less the same protocol framing. This new protocol is designed to be extensible and properly internationalized. 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. Table of Contents 1. Introduction 2. Conventions used in this document 3. Table of Contents 4. The Protocol 4.1 Transports 4.2 Protocol Framing 4.2.1 The protocol over UDP 4.2.2 The protocol over TCP 4.3 Protocol version negotiation 4.3.1 Protocol major version negotiation 4.3.2 Protocol minor version negotiation 4.4 Use of Kerberos V 4.4.1 Use of KRB-ERROR Trostle et. al. [Page 2] DRAFT Kerberos Set/Change Password v2 Expires November 2003 4.5 Use of ASN.1 4.6 Protocol internationalization 4.6.1 Normalization forms for UTF-8 strings 4.6.2 Language negotiation 4.7 Protocol Extensibility 4.8 Protocol Subsets 5 Protocol Operations 5.1 PDUs 6 ASN1 Module 7 Descriptions of each protocol requests and responses 7.1 Null Request 7.2 Change Password 7.3 Set Keys Requests 7.5 The Get Policy Request 7.6 The Get Aliases Request 7.7 The Get Supported Enctypes Request 8 IANA Considerations 9 Security Considerations 10 Description of TLV Encoding of Sample Subsets of the Protocol 10.1 TLV encoding of the Null request and response 10.2 TLV encoding of Error-Response 10.3 TLV encoding of the change password requests and responses 10.4 TLV encoding of Change Keys requests and responses 11 Acknowledgements 12 References 13 Expiration Date 14 Authors' Addresses 15 Notes to the RFC Editor 4. The Protocol The structure of the protocol is quite similar to that of typical RPC protocols. Each operation has a structure for each client request and a structure for each server response. Each transaction consists of a single operation; the abstract syntax for the protocol implies the use, on the wire, of an operation identifier associated with an opaque blob representing the request of response. The protocol data is wrapped in a KRB-PRIV and framed in a header that is backwards compatible with version 1 of this protocol. 4.1 Transports The service SHOULD accept requests on UDP port 464 and TCP port 464. This is the same port used by version 1 [KPASSWDv1] of this protocol, but version 2 is a completely different protocol sharing with version 1 only the outer framing. 4.2 Protocol Framing For compatibility with the original Kerberos password changing protocol developed at MIT, the first 4 bytes of the message consist of a 2-byte network byte order message length, followed by a 2 byte network byte order protocol version number, followed by a 2 byte Trostle et. al. [Page 3] DRAFT Kerberos Set/Change Password v2 Expires November 2003 network byte order length for an optional AP-REQ, AP-REP or KRB-ERROR, followed by the same, if present, followed by a KRB-PRIV (optional in TCP) containing the actual protocol message encoded in DER [X690]. In the case of TCP there is an additional 4 byte network byte order length prepended to the frame described above. The protocol version number MUST be set to 2 for this protocol. Bytes on the wire description of the framing: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | message length | protocol version number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AP-REQ length (0 if absent) | AP-REQ data (if present) / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / KRB-PRIV message / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The same framing applies equally to requests and responses, but responses use AP-REP and/or KRB-ERROR instead of AP-REQ: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | message length | protocol version number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AP-REP length (0 if absent) | AP-REP data (if present) / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / KRB-PRIV message / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | message length | protocol version number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | KRB-ERROR length (0 if absent)| KRB-ERROR data (if present) / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ For the UDP case the AP-REQ/AP-REP/KRB-ERROR MUST always be included. Note that this framing is used by version 1 [KPASSWDv1] and version 0xff80 [RFC3244], though the latter does not use the framing when responding with KRB-ERROR messages. Servers MAY respond to version 0xff80 requests with an un-framed KRB-ERROR and e-data set as per-RFC3244 [RFC3244], otherwise clients and server MUST always use this framing. See section 4.3. Trostle et. al. [Page 4] DRAFT Kerberos Set/Change Password v2 Expires November 2003 4.2.1 The protocol over UDP In the UDP case there is a single message from the client and a single response from the server with no state kept between requests, and each request MUST include a Kerberos AP-REQ and a KRB-PRIV and each response MUST carry an AP-REP, or KRB-ERROR and a KDB-PRIV. Both the client and server MUST destroy the authentication context after each operation. UDP clients MUST not request the use of sequence numbers, otherwise it cannot generate the KRB-PRIV prior to receiving the AP-REP. Clients MAY refuse to operate version 2 of the protocol over UDP; it is RECOMMENDED that servers reject version 2 UDP requests. 4.2.2 The protocol over TCP When used with the TCP transport, there is a 4 octet header in network byte order that precedes the message and specifies the length of the message. 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. Subsequent messages MAY involve Kerberos V AP exchanges, but generally the client SHOULD NOT initiate a new AP exchange except when it desires to authenticate as a different principal, when its current authentication context is about to expire or when the server responds with an error indicating that the client must re-initialize the authentication context (possibly due to the previous context expiring). The server MUST NOT process any requests that do not contain an AP-REQ unless a non-expired authentication context is currently established with the client on the same TCP connection. Servers MAY close open sessions at any time. 4.3 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. 4.3.1 Protocol major version negotiation Version 2 clients that also support other versions, such as [KPASSWDv1] or [rfc3244] SHOULD attempt to use version 2 of the protocol first and then try other versions if the server responds with either a message framed as described in section 4.2 but with a protocol version number other than 2 (in the case of [KPASSWDv1], or a KRB-ERRROR with an error code of KRB5_KPASSWD_BAD_VERSION in the e-data field [RFC3244]. Trostle et. al. [Page 5] DRAFT Kerberos Set/Change Password v2 Expires November 2003 Note that some version 1 servers return a KRB-ERROR indicating that versions other than 1 of the change password protocol are not supported rather than an AP-REP and a KRB-PRIV containing the error data. Therefore change password protocol negotiation is subject to downgrade attacks where version 2 clients support version 1 of this protocol. Also note that some [RFC3244] implementations do not return any responses to requests for protocol versions other than 0xff80, and in the TCP case close the TCP connection. Version 2 servers MAY support other versions of the Kerberos password change protocol. Version 2 servers SHOULD 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 4.2, using an AP-REP and KRB-PRIV if the client's AP-REQ can be accepted, or a KRB-ERROR (framed) otherwise and using a ProtocolErrorCode value of unsupported-major-version. 4.3.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 and registered with the IANA. Version 2 clients and servers MUST support all protocol minor versions between 0 to the highest version supported by the client and server. That is, a client or server that supports minor version 4 MUST also support minor versions 0, 1, 2 and 3. 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 session (currently this only applies to TCP sessions). See section 4.7 for further description of the protocol's extensibility and its relation to protocol minor versions and the negotiation thereof. 4.4 Use of Kerberos V This protocol makes use of messages defined in [RFC1510] and [clarifications]. Specifically, AP-REQ, AP-REP, KRB-ERROR and KRB-PRIV. Because of the proposed extensions to Kerberos V which will require a new ASN.1 module, and because of the ways that the Trostle et. al. [Page 6] DRAFT Kerberos Set/Change Password v2 Expires November 2003 Kerberos V ASN.1 types will change, this protocol cannot safely import any types from the Kerberos V module, therefore the Kerberos PDUs are encoded as OCTET STRINGs herein. All operations are to be performed by the server on behalf of the client principal. The client SHOULD use "kadmin/changepw" as the server principal name for this protocol. The server MUST have a principal name of "kadmin/changepw" and MAY have a principal name of "kadmin/setpw." The client MUST request mutual authentication and the client MUST NOT request the use of sequence numbers when using the protocol over UDP, but it MUST request the use of sequence numbers when running over TCP. The server MUST reject requests that operate on the same principal as the client's if the client's principal is not in the same realm as the server's principal name or if the client's ticket is not INITIAL. The server MAY reject all requests from clients operating on principals not in the client's realm. The server MAY reject all requests operating on principals other than the client's. 4.4.1 Use of KRB-ERROR When an error arises during the AP exchange for which [clarifications] does not provide an appropriate error code then the server MUST use KRB_ERR_GENERIC as the error, a localized (if possible [er, is that ok, pre-extensions? probably not]) error string for the e-text field of KRB-ERROR and the encoding of an Error-Response PDU (see section 6) as e-data. 4.5 Use of ASN.1 This protocol's messages are defined in ASN.1, using only features from [X680]. All ASN.1 types defined herein are to be encoded in DER [X690]. A complete ASN.1 module is given in section 6. The ASN.1 tagging environment for this module is EXPLICIT. The DER encoding of the ASN.1 PDUs are exchanged wrapped in a KRB-PRIV as described above. 4.6 Protocol internationalization Protocol requests have an optional field indicationg the languages spoken by the client user; the client SHOULD send its list of spoken languages to the server (once per-TCP session), but if future extensions to the Kerberos protocol should add similar functionality then the client SHOULD NOT use this field when using the extended Kerberos protocol. All strings in the protocol are UTF-8 strings. The server SHOULD localize all strings intended for users to a language in common with the languages spoken by the client user. Trostle et. al. [Page 7] DRAFT Kerberos Set/Change Password v2 Expires November 2003 For TCP sessions servers MUST cache the optional language tag lists from prior requests for use with requests that exclude the language tag list. Clients MAY expect such server behaviour and send the language tag lists only when they change or even just once per-TCP session. Clients SHOULD send the server the language tag list at least once, with or before any actual operation. Kerberos principal and realm names used in this protocol MUST be constrained as per the specification of the version of Kerberos V used by the client. 4.6.1 Normalization forms for UTF-8 strings No normalization form is required for string types other than for PrincipalName and Realm, which two types are constrained by the specification of the version of Kerberos V used by the client, and the password fields in the change password operation, which MUST be normalized according to [k5stringprep]. 4.6.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. When the server has a message catalog for one of the client's spoken languages the server SHOULD localize any text strings intended for users to read. 4.7 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 [X680]. 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 4.3.2 for the minor version negotiation. Trostle et. al. [Page 8] DRAFT Kerberos Set/Change Password v2 Expires November 2003 Message extensions are to be closely tied to protocol minor numbers. Clients MAY use any protocol minor version that they support in initial requests, and MUST use the protocol minor version indicated in the server's initial reply in any subsequent requests in the same session (this only applies in the TCP case). Clients MAY cache the minor version number supported by any given server for a reasonably short and finite amount of time - 24 hours is the maximum RECOMMENDED time for caching server minor version information. Servers SHOULD ignore protocol extensions and minor versions that they do not understand in initial requests, except for extensions to the "Op-req" type, which MUST result in an error; servers MAY respond with an error (ProtocolErrorCode value of unsupported-minor-version) to clients that use minor versions unsupported by the server in their initial requests. Servers MUST select the highest minor version in common with their clients for use in replies. Servers MAY support a subset of the operations defined in this protocol but MUST support all the PDUs. 4.8 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. Clients and servers MAY implement subsets of the overall protocol. The structure of this protocol and the properties of the tag-length-value (TLV) DER encoding of ASN.1 make it possible to describe the encoding of individual operations' messages very simply. In the interest of facilitating ease of implementation for trivial subsets of this protocol, without the need for ASN.1 compilers, section 10 describes examples of TLV layouts of some individual protocol operations (but the DER encodings of tags, lengths and UNIVERSAL values is not described). 5 Protocol Operations The protocol as defined herein supports the following operations relating to the management of Kerberos principal's passwords or keys: - change password - set key - get password policy name and/or description of principal - list aliases of a principal - list enctypes supported by realm These operations are needed to support Kerberos V interoperability Trostle et. al. [Page 9] DRAFT Kerberos Set/Change Password v2 Expires November 2003 between clients and KDCs of different implementation origins. 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 "keytabs" 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 directories or other Kerberos administration protocols. However, it is conceivable that such operations could be added to this protocol at a later point. Operations can be added to the protocol only via future IETF RFCs. The individual operations are described in section 7. 5.1 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 4.4.1) when AP exchanges fail, otherwise it MUST be sent wrapped in a KRB-PRIV. The PDUs are described in section 6. 6 ASN1 Module DEFINITIONS EXPLICIT TAGS ::= BEGIN -- Unsafe: IMPORT AP-REQ, AP-REP, KRB-ERROR, KRB-PRIV, PrincipalName, -- Realm, KerberosString, FROM KerberosV5Spec2 -- From [clarifications] PrincipalName ::= SEQUENCE { name-type [0] Int32, name-string [1] SEQUENCE OF UTF8String } Realm ::= UTF8String -- NOTE WELL: Principal and realm names MUST be constrained by the -- specification of the version of Kerberos V used by the -- client. -- -- [Perhaps PrincipalName should be a SEQUENCE of an optional name type -- and a UTF8String, for simplicity.] -- From [clarifications] Int32 ::= INTEGER (-2147483648..2147483647) UInt32 ::= INTEGER (0..4294967295) Trostle et. al. [Page 10] DRAFT Kerberos Set/Change Password v2 Expires November 2003 -- Based on EncryptionKey type from [clarifications] Key ::= SEQUENCE { enc-type [0] Int32, -- from Kerberos key [1] OCTET STRING, ... } Etype ::= Int32 -- as in [clarifications] -- Perhaps we should use an extensible CHOICE of Int32? Language-Tag ::= UTF8String -- Constrained by [RFC3066] -- Use LangTaggedText instead of UTF8String for *-text fields and remove -- "language" field? -- -- LangTaggedText should be used as e-text for KRB-ERROR, at least in -- extensions, perhaps in [clarifications] LangTaggedText ::= SEQUENCE { language [0] Language-Tag OPTIONAL, text [1] UTF8String, ... } Request ::= [APPLICATION 0] SEQUENCE { pvno-major [0] INTEGER DEFAULT 2, pvno-minor [1] INTEGER DEFAULT 0, languages [2] SEQUENCE OF Language-Tag OPTIONAL, targ-name [3] PrincipalName OPTIONAL, targ-realm [4] Realm OPTIONAL, -- If targ-name/realm are missing then the request -- applies to the principal of the client operation [5] Op-req, ... } Response ::= [APPLICATION 1] SEQUENCE { pvno-major [0] INTEGER DEFAULT 2, pvno-minor [1] INTEGER DEFAULT 0, language [2] Language-Tag DEFAULT "i-default", result [3] Op-rep OPTIONAL, ... } Error-Response ::= [APPLICATION 2] SEQUENCE { pvno-major [0] INTEGER DEFAULT 2, pvno-minor [1] INTEGER DEFAULT 0, language [2] Language-Tag DEFAULT "i-default", error-code [3] ProtocolErrorCode, help-text [4] UTF8String OPTIONAL, op-error [5] Op-error OPTIONAL, ... } Trostle et. al. [Page 11] DRAFT Kerberos Set/Change Password v2 Expires November 2003 Op-req ::= CHOICE { null [0] Req-null, change-pw [1] Req-change-pw, set-keys [2] Req-set-keys, get-pw-policy [3] Req-get-pw-policy, get-princ-aliases [4] Req-get-princ-aliases, get-supported-etypes [5] Req-get-supported-etypes, ... } Op-rep ::= CHOICE { null [0] Rep-null, change-pw [1] Rep-change-pw, set-keys [2] Rep-set-keys, get-pw-policy [3] Rep-get-pw-policy, get-princ-aliases [4] Rep-get-princ-aliases, get-supported-etypes [5] Rep-get-supported-etypes, ... } Op-error ::= CHOICE { null [0] Err-null, change-pw [1] Err-change-pw, set-keys [2] Err-set-keys, get-pw-policy [3] Err-get-pw-policy, get-princ-aliases [4] Err-get-princ-aliases, get-supported-etypes [5] Err-get-supported-etypes, ... } ProtocolErrorCode ::= ENUM { -- Remember, ASN.1 enums are zero-based generic-error, unsupported-major-version, unsupported-minor-version, unsupported-operation, authorization-failed, initial-ticket-required, target-principal-unknown, ... } -- -- Requests and responses -- -- NULL request, much like ONC RPC's NULL procedure Req-null ::= NULL Rep-null ::= NULL Err-null ::= NULL Trostle et. al. [Page 12] DRAFT Kerberos Set/Change Password v2 Expires November 2003 -- Change password Req-change-pw ::= SEQUENCE { old-pw [0] UTF8String, new-pw [1] UTF8String OPTIONAL, etypes [2] SEQUENCE (1..) OF Etype OPTIONAL, ... } Rep-change-pw ::= SEQUENCE { info-text [0] UTF8String OPTIONAL, new-pw [1] UTF8String OPTIONAL, -- generated by the server if present -- (and requested by the client) etypes [2] SEQUENCE (1..) OF Etype OPTIONAL, ... } Err-change-pw ::= SEQUENCE { help-text [0] UTF8String OPTIONAL, code [1] ENUM { generic, wont-generate-new-pw, old-pw-incorrect, new-pw-rejected-generic, pw-change-too-soon, ... }, suggested-new-pw [2] UTF8String OPTIONAL, ... } -- Change/Set keys Req-set-keys ::= SEQUENCE { etypes [0] SEQUENCE (1..) OF Etype, entropy [1] OCTET STRING OPTIONAL, -- The client can provide entropy for -- the server's use while generating -- keys. ... } Rep-set-keys ::= SEQUENCE { info-text [0] UTF8String OPTIONAL, kvno [1] UInt32, keys [2] SEQUENCE (1..) OF Key, -- The server always makes the keys. aliases [3] SEQUENCE OF SEQUENCE { name [0] PrincipalName, realm [1] Realm OPTIONAL, ... } OPTIONAL, Trostle et. al. [Page 13] DRAFT Kerberos Set/Change Password v2 Expires November 2003 ... } Err-set-keys ::= SEQUENCE { help-text [0] UTF8String OPTIONAL, -- Reason for rejection enctypes [1] SEQUENCE of Etype OPTIONAL, -- supported enctypes code [2] ENUM { etype-no-support, ... } } -- Get password policy Req-get-pw-policy ::= NULL Rep-get-pw-policy ::= SEQUENCE { help-text [0] UTF8String OPTIONAL, policy-name [1] UTF8String OPTIONAL, description [2] UTF8String OPTIONAL, ... } Err-get-pw-policy ::= NULL -- Get principal aliases Req-get-princ-aliases ::= NULL Rep-get-princ-aliases ::= SEQUENCE { help-text [0] UTF8String OPTIONAL, aliases [1] SEQUENCE OF SEQUENCE { name [0] PrincipalName, realm [1] Realm OPTIONAL, ... } OPTIONAL, ... } Err-get-princ-aliases ::= NULL -- Get list of enctypes supported by KDC for new keys Req-get-supported-etypes ::= NULL Rep-get-supported-etypes ::= SEQUENCE OF Etype Err-get-supported-etypes ::= NULL END 7 Descriptions of each protocol requests and responses This section describes the semantics of each operation request and response defined in the ASN.1 module in section 6. Trostle et. al. [Page 14] DRAFT Kerberos Set/Change Password v2 Expires November 2003 Requests and responses consist of an outer structure ("Request," "Response" and "Error-Response") containing fields common to all requests/responses, and an inner structure for fields that are specific to each operation's requests/responses. Specifically, the outer Request structure has a field for passing a client's spoken (read) languages to the server. It also has two optional fields for identifying the operation's target principal's name and realm (if not sent then the server MUST use the client principal name and realm from the AP exchange as the target). The Response and Error PDU' outer structures include a field indicating the language that the server has chosen for localization of text intended to be displayed to users. All three PDUs, "Request," "Response," and "Error-Response" include a protocol version number and the two responses include an optional field through which the server can indicate which language, from the client's list, the server can "speak." 7.1 Null Request The null request is intended for use with TCP; its purpose is similar to RPC null procedures and is akin to a "ping" operation. 7.2 Change Password The change password request has two fields: old-pw (old password - required) and new-pw (new password - optional). The server MUST validate the old password and MUST check the quality of the new password, if sent, according to the password policy associated with the client's principal before accepting the request. If the client does not specify a new password the server MUST either generate one and return it in the response or reject the request with wont-generate-new-pw as the Err-change-pw message's error code. If the server rejects a client's proposed new password it SHOULD include a description of the password quality policy in effect for the target principal and/or an explanation of what was wrong with the proposed password in the help-text field of the Err-change-pw message. Additionally, servers MAY include a randomly generated, but preferably user-friendly password in the suggested-new-pw field of Err-change-pw messages when the client's proposed new password violates the target principal's password quality policy; of course, any such suggested new password MUST pass the target principal's password quality policy. Clients MAY specify key enctypes to set with new passwords, but generally SHOULD NOT do so. If a client requests specific enctypes then the server MUST NOT create keys from the new password of any enctype other than those requested by the client. Servers MAY indicate the enctypes of the keys created with new Trostle et. al. [Page 15] DRAFT Kerberos Set/Change Password v2 Expires November 2003 passwords, but SHOULD NOT do so unless the client requested specific enctypes - in which case the server MUST include the new key enctypes in the change password response. 7.3 Set Keys Requests The set keys request consists of a sequence of key enctypes and an optional OCTET STRING of client-provided entropy. The server generates keys of the requested enctypes and returns them. The server MAY utilize some, all or none of the client-provided entropy, if any, to generate the keys, but the server SHOULD input some entropy in the process. The server SHOULD also include a list of the target principal's aliases, if there are any. 7.5 The Get Policy Request It is common for sites to set policies with respect to password quality. It is beyond the scope of this document to describe such policies. However, it is reasonable for password policies to have names and as such for this protocol to associate named password quality policies with principals. It may also be reasonable for users to learn of their password quality policies. The protocol therefore provides an operation for retrieving the name and/or description of the password policy that applies to the target principal name. Management of password quality policies' actual content is beyond the scope of this protocol. 7.6 The Get Aliases Request This request allows a client to obtain a list of aliases associated with a principal so that the client can properly configure the principal's "keytab." Principal aliases are principal names for which the KDC will issue tickets (with the alias being either the client or target principal name of such tickets) using the same key as the "canonical" principal name, but without canonicalizing the aliased names in KDC exchanges. 7.7 The Get Supported Enctypes Request This request allows a client to learn of the target principal's realm's supported enctypes. 8 IANA Considerations ... Trostle et. al. [Page 16] DRAFT Kerberos Set/Change Password v2 Expires November 2003 9 Security Considerations Implementors and site administrators should note that the redundancy of UTF-8 encodings varies by Unicode codepoint used. Password quality policies should, therefore, take this into account when estimating the amount of redundancy and entropy in a proposed new password. [?? It's late at night - I think this is correct.] 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 [RFC1510]). [More text needed] 10 Description of TLV Encoding of Sample Subsets of the Protocol This section provides example descriptions of the TLV DER encodings of some requests and responses. This section is not intended to be authoritative and implementors are encouraged to base their implementations on the ASN.1 syntax given in section 6. These TLV descriptions are given here in the interest of promoting implementation of this protocol even by implementors who do not have access to ASN.1 development tools. Tags are described as T() where is a letter denoting the tag type (u for UNIVERSAL, a for APPLICATION, c for CONTEXT and p for PRIVATE) and a number or universal type name. Lengths and values are described as L{}, where is a description of the encoding of the value, except for scalar UNIVERSAL types, where shall be '<' description of value '>'. Optional fields are enclosed in square brackets ('[' and ']'). Repetition is denoted by ellipsis ("..."). Extensibility is denoted by "[...]". Comments are introduced by "--" as in ASN.1 10.1 TLV encoding of the Null request and response -- Null Request -- Outer application tag T(a0)L{T(uSEQUENCE)L{ -- "preamble" -- pvno-major == 2 so it is left out Trostle et. al. [Page 17] DRAFT Kerberos Set/Change Password v2 Expires November 2003 -- pvno-minor == 0 so it is left out -- optional languages list [T(c2)L{ T(uSEQUENCE)L{ T(uUTF8String)L{} ... } }] -- optional targ-name [T(c3)L{ Tc(uSEQUENCE)L{ -- name-type T(c0)L{T(uINTEGER)L{}} -- name-string T(c1)L{ T(uSEQUENCE)L{ [T(uUTF8String)L{}] ... } } } }] -- optional targ-realm [T(c4)L{T(uUTF8String)L{}}] -- end of preamble -- operation choice tag T(c5)L{ -- null CHOICE (this tag indicates the CHOICE taken; replace this -- TLV with the TLV for any operation to get the Request encoding -- of that operation) T(c0)L{ -- Req-null (this is the encoding of the value of the CHOICE -- taken); NULL has no LV part. T(uNULL) } } -- extensions [...] }} -- Null Response -- Outer application tag T(a1)L{T(uSEQUENCE)L{ -- "preamble" -- pvno-major == 2 so it is left out -- pvno-minor == 0 so it is left out -- optional language [T(c1)L{T(uUTF8String)L{}}] -- end preamble -- operation choice tag T(c2)L{ -- null CHOICE Trostle et. al. [Page 18] DRAFT Kerberos Set/Change Password v2 Expires November 2003 T(c0)L{ T(uNULL) } } }} 10.2 TLV encoding of Error-Response -- Error Response -- Outer application tag T(a1)L{T(uSEQUENCE)L{ -- "preamble" -- pvno-major == 2 so it is left out -- pvno-minor == 0 so it is left out -- optional language [T(c2)L{T(uUTF8String)L{}}] -- end preamble -- error code T(c3)L{T(uENUM)L{)L{} } -- extensions [...] }} 10.3 TLV encoding of the change password requests and responses -- Req-change-pw -- choice tag T(c1)L{ T(uSEQUENCE)L{ -- old password T(c0)L{T(uUTF8String)L{}} -- new password (optional; if missing server must generate it) [T(c1)L{T(uUTF8String)L{}}] -- extensions [...] } } -- Rep-change-pw -- choice tag T(c1)L{ T(uSEQUENCE)L{ -- optional informational text [T(c0)L{T(uUTF8String)L{}}] -- new password (optional; see section 6) [T(c1)L{T(uUTF8String)L{}}] -- extensions Trostle et. al. [Page 19] DRAFT Kerberos Set/Change Password v2 Expires November 2003 [...] } } -- Err-change-pw -- choice tag T(c1)L{ T(uSEQUENCE)L{ -- optional help text [T(c0)L{T(uUTF8String)L{}}] -- error code T(c1)L{T(uENUM)L{}}] -- extensions [...] } } 10.4 TLV encoding of Change Keys requests and responses -- Req-set-keys -- choice tag T(c1)L{ T(uSEQUENCE)L{ -- new key enctypes T(c0)L{T(uSEQUENCE)L{ T(uINTEGER)L{}, ... }} -- optional entropy [T(c1)L{T(uOCTET STRING)L{}}] -- extensions [...] } } -- Rep-set-keys -- choice tag T(c1)L{ T(uSEQUENCE)L{ -- optional informational text [T(c0)L{T(uUTF8String)L{}}] -- new kvno T(c1)L{T(uINTEGER)L{}} -- new keys T(c2)L{T(uSEQUENCE)L{ -- first key T(uSEQUENCE)L{ T(uINTEGER)L{} T(uOCTET STRING)L{} -- extensions to Key [...] } -- additional keys, if any Trostle et. al. [Page 20] DRAFT Kerberos Set/Change Password v2 Expires November 2003 ... }} -- optional aliases [T(c3)L{T(uSEQUENCE)L{ -- first alias T(uSEQUENCE)L{ -- principal name T(uSEQUENCE)L{ T(uUTF8String)L{}, -- components 2..N, if any ... } T(uUTF8String)L{} -- extensions [...] } -- additional aliases, if any ... }}] -- extensions [...] } } -- Err-set-keys -- choice tag T(c1)L{ T(uSEQUENCE)L{ -- optional help text [T(c0)L{T(uUTF8String)L{}}] -- KDC supported enctypes [T(c1)L{T(uSEQUENCE)L{ T(uINTEGER)L{}, ... }}] -- error code T(c2)L{T(uENUM)L{}}] -- extensions [...] } } 11 Acknowledgements The authors would like to thank Sam Hartman, Paul W. Nelson and Marcus Watts for their assistance. The authors thank Ken Raeburn, Tom Yu, Martin Rex, Sam Hartman, Tony Andrea, Paul W. Nelson, Marcus Watts and other participants from the IETF Kerberos Working Group for their input to the document. 12 References Trostle et. al. [Page 21] DRAFT Kerberos Set/Change Password v2 Expires November 2003 12.1 Normative References [RFC2026] S. Bradner, RFC2026: "The Internet Standard Process - Revision 3," October 1996, Obsoletes - RFC 1602, Status: Best Current Practice. [RFC2119] S. Bradner, RFC2119 (BCP14): "Key words for use in RFCs to Indicate Requirement Levels," March 1997, Status: Best Current Practice. [X680] Abstract Syntax Notation One (ASN.1): Specification of Basic Notation, ITU-T Recommendation X.680 (1997) | ISO/IEC International Standard 8824-1:1998. http://www.itu.int/ITU-T/studygroups/com17/languages/X680_0702.pdf [X690] ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER), ITU-T Recommendation X.690 (1997)| ISO/IEC International Standard 8825-1:1998. http://www.itu.int/ITU-T/studygroups/com17/languages/X690_0702.pdf [RFC1510] J. Kohl and B. C. Neuman, RFC1510: "The Kerberos Network Authentication Service (v5)," September 1993, Status: Proposed Standard. [clarifications] RFC-Editor: To be replaced by RFC number for draft-ietf-krb-wg- kerberos-clarifications. [k5stringprep] RFC-Editor: To be replaced by RFC number for draft-ietf-krb-wg- utf8-profile. [RFC3066] H. Alvestrand, RFC3066 (BCP47): "Tags for the Identification of Languages," January 2001, Obsoletes RFC1766, Status: Best Current Practice. [KPASSWDv1] (Reference needed!) 12.1 Informative References [RFC3244] M. Swift, J. Trostle, J. Brezak, RFC3244: "Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols," February 2002, Status: Informational. Trostle et. al. [Page 22] DRAFT Kerberos Set/Change Password v2 Expires November 2003 13 Authors' Addresses Jonathan Trostle Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134 Email: jtrostle@cisco.com Mike Swift University of Washington Seattle, WA Email: mikesw@cs.washington.edu John Brezak Microsoft 1 Microsoft Way Redmond, WA 98052 Email: jbrezak@microsoft.com Bill Gossman Cisco Systems 500 108th Ave. NE, Suite 500 Bellevue, WA 98004 Email: bgossman@cisco.com Nicolas Williams Sun Microsystems 5300 Riata Trace Ct Austin, TX 78727 Email: nicolas.williams@sun.com 14 Notes to the RFC Editor This document has two KRB WG drafts as normative references and cannot progress until those drafts progress, but no other draft depends on this one. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than Trostle et. al. [Page 23] DRAFT Kerberos Set/Change Password v2 Expires November 2003 English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.