diff options
Diffstat (limited to 'third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-set-passwd-00.txt')
| -rw-r--r-- | third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-set-passwd-00.txt | 1352 |
1 files changed, 1352 insertions, 0 deletions
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-set-passwd-00.txt b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-set-passwd-00.txt new file mode 100644 index 00000000000..da5dd0daca2 --- /dev/null +++ b/third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-set-passwd-00.txt @@ -0,0 +1,1352 @@ + +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 + <draft-ietf-krb-wg-kerberos-set-passwd-00.txt> + + + + +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(<tag>) where <tag> 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{<value>}, where <value> is a + description of the encoding of the value, except for scalar UNIVERSAL + types, where <value> 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{<language tag>} + ... + } + }] + -- optional targ-name + [T(c3)L{ + Tc(uSEQUENCE)L{ + -- name-type + T(c0)L{T(uINTEGER)L{<name-type>}} + -- name-string + T(c1)L{ + T(uSEQUENCE)L{ + [T(uUTF8String)L{<component name>}] + ... + } + } + } + }] + -- optional targ-realm + [T(c4)L{T(uUTF8String)L{<realm name>}}] + -- 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{<language tag>}}] + -- 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{<language tag>}}] + -- end preamble + -- error code + T(c3)L{T(uENUM)L{<error code}} + T(c4)L{T(uUTF8String)L{<error text}} + -- optional CHOICE + T(c5)L{ + -- CHOICE TLV goes here + T(c<choice taken>)L{<value of CHOICE taken>} + } + -- 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{<password string>}} + -- new password (optional; if missing server must generate it) + [T(c1)L{T(uUTF8String)L{<password string>}}] + -- extensions + [...] + } + } + + -- Rep-change-pw + -- choice tag + T(c1)L{ + T(uSEQUENCE)L{ + -- optional informational text + [T(c0)L{T(uUTF8String)L{<text>}}] + -- new password (optional; see section 6) + [T(c1)L{T(uUTF8String)L{<new password>}}] + -- 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{<text>}}] + -- error code + T(c1)L{T(uENUM)L{<error code>}}] + -- 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{<etype integer>}, + ... + }} + -- optional entropy + [T(c1)L{T(uOCTET STRING)L{<entropy>}}] + -- extensions + [...] + } + } + + -- Rep-set-keys + -- choice tag + T(c1)L{ + T(uSEQUENCE)L{ + -- optional informational text + [T(c0)L{T(uUTF8String)L{<text>}}] + -- new kvno + T(c1)L{T(uINTEGER)L{<new kvno>}} + -- new keys + T(c2)L{T(uSEQUENCE)L{ + -- first key + T(uSEQUENCE)L{ + T(uINTEGER)L{<etype>} + T(uOCTET STRING)L{<key>} + -- 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{<component1>}, + -- components 2..N, if any + ... + } + T(uUTF8String)L{<realm name>} + -- 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{<text>}}] + -- KDC supported enctypes + [T(c1)L{T(uSEQUENCE)L{ + T(uINTEGER)L{<etype integer>}, + ... + }}] + -- error code + T(c2)L{T(uENUM)L{<error code>}}] + -- 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. |