diff options
Diffstat (limited to 'third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-02.txt')
| -rw-r--r-- | third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-02.txt | 325 |
1 files changed, 325 insertions, 0 deletions
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-02.txt b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-02.txt new file mode 100644 index 00000000000..6f7dae0dea7 --- /dev/null +++ b/third_party/heimdal/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-02.txt @@ -0,0 +1,325 @@ + +INTERNET-DRAFT Mike Swift +draft-ietf-cat-kerberos-set-passwd-02.txt Microsoft +March 2000 Jonathan Trostle + Cisco Systems + John Brezak + Microsoft + Bill Gossman + Cybersafe + + Kerberos Set/Change Password: Version 2 + + +0. Status Of This Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026 [1]. + + 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. + + Comments and suggestions on this document are encouraged. Comments + on this document should be sent to the CAT working group discussion + list: + ietf-cat-wg@stanford.edu + +1. Abstract + + The Kerberos (RFC 1510 [3]) change password protocol (Horowitz [4]), + does not allow for an administrator to set a password for a new user. + This functionality is useful in some environments, and this proposal + extends [4] to allow password setting. The changes are: adding new + fields to the request message to indicate the principal which is + having its password set, not requiring the initial flag in the service + ticket, using a new protocol version number, and adding three new + result codes. We also extend the set/change protocol to allow a + client to send a sequence of keys to the KDC instead of a cleartext + password. If in the cleartext password case, the cleartext password + fails to satisfy password policy, the server should use the result + code KRB5_KPASSWD_POLICY_REJECT. + +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 RFC-2119 [2]. + +3. The Protocol + + The service must accept requests on UDP port 464 and TCP port 464 as + well. The protocol consists of a single request message followed by + a single reply message. For UDP transport, each message must be fully + contained in a single UDP packet. + + For TCP transport, there is a 4 octet header in network byte order + precedes the message and specifies the length of the message. This + requirement is consistent with the TCP transport header in 1510bis. + +Request 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AP_REQ length | AP-REQ data / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / KRB-PRIV message / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + All 16 bit fields are in network byte order. + + message length field: contains the number of bytes in the message + including this field. + + protocol version number: contains the hex constant 0x0002 (network + byte order). + + AP-REQ length: length of AP-REQ data, in bytes. If the length is zero, + then the last field contains a KRB-ERROR message instead of a KRB-PRIV + message. + + AP-REQ data: (see [3]) The AP-REQ message must be for the service + principal kadmin/changepw@REALM, where REALM is the REALM of the user + who wishes to change/set his password. The ticket in the AP-REQ must + must include a subkey in the Authenticator. To enable setting of + passwords/keys, it is not required that the initial flag be set in the + Kerberos service ticket. The initial flag is required for change requests, + but not for set password requests. We have the following definitions: + + old passwd initial flag target principal can be + in request? required? distinct from + authenticating principal? + + change password: yes yes no + + set password: no no yes + + set key: no policy yes + determined + + KRB-PRIV message (see [3]) This KRB-PRIV message must be generated + using the subkey from the authenticator in the AP-REQ data. + + The user-data component of the message consists of the following ASN.1 + structure encoded as an OCTET STRING: + + ChangePasswdData :: = SEQUENCE { + newpasswdorkeys[0] NewPasswdOrKeys, + targname[1] PrincipalName OPTIONAL, + -- only present in set password: the principal + -- which will have its password set + targrealm[2] Realm OPTIONAL, + -- only present in set password: the realm for + -- the principal which will have its password set + + } + + NewPasswdOrKeys :: = CHOICE { + passwords[0] PasswordSequence, + keyseq[1] KeySequences + } + + KeySequences :: = SEQUENCE OF KeySequence + + KeySequence :: = SEQUENCE { + key[0] EncryptionKey, + salt[1] OCTET STRING OPTIONAL, + salt-type[2] INTEGER OPTIONAL + } + + PasswordSequence :: = SEQUENCE { + newpasswd[0] OCTET STRING, + oldpasswd[1] OCTET STRING OPTIONAL + -- oldpasswd always present for change password + -- but not present for set password + } + + The server must verify the AP-REQ message, check whether the client + principal in the ticket is authorized to set or change the password + (either for that principal, or for the principal in the targname + field if present), and decrypt the new password/keys. The server + also checks whether the initial flag is required for this request, + replying with status 0x0007 if it is not set and should be. An + authorization failure is cause to respond with status 0x0005. For + forward compatibility, the server should be prepared to ignore fields + after targrealm in the structure that it does not understand. + + The newpasswdorkeys field contains either the new cleartext password + (with the old cleartext password for a change password operation), + or a sequence of encryption keys with their respective salts. + + In the cleartext password case, if the old password is sent in the + request, the request is defined to be a change password request. If + the old password is not present in the request, the request is a set + password request. The server should apply policy checks to the old + and new password after verifying that the old password is valid. + The server can check validity by obtaining a key from the old + password with a keytype that is present in the KDC database for the + user and comparing the keys for equality. The server then generates + the appropriate keytypes from the password and stores them in the KDC + + database. If all goes well, status 0x0000 is returned to the client + in the reply message (see below). For a change password operation, + the initial flag in the service ticket MUST be set. + + In the key sequence case, the sequence of keys is sent to the set + password service. For a principal that can act as a server, its + preferred keytype should be sent as the first key in the sequence, + but the KDC is not required to honor this preference. Application + servers should use the key sequence option for changing/setting their + keys. The set password service should check that all keys are in the + proper format, returning the KRB5_KPASSWD_MALFORMED error otherwise. + +Reply 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | AP_REP length | AP-REP data / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + / KRB-PRIV message / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + All 16 bit fields are in network byte order. + + message length field: contains the number of bytes in the message + including this field. + + protocol version number: contains the hex constant 0x0002 (network + byte order). (The reply message has the same format as in [4]). + + AP-REP length: length of AP-REP data, in bytes. If the length is zero, + then the last field contains a KRB-ERROR message instead of a KRB-PRIV + message. + + AP-REP data: the AP-REP is the response to the AP-REQ in the request + packet. + + KRB-PRIV from [4]: This KRB-PRIV message must be generated using the + subkey in the authenticator in the AP-REQ data. + + The server will respond with a KRB-PRIV message unless it cannot + validate the client AP-REQ or KRB-PRIV message, in which case it will + respond with a KRB-ERROR message. NOTE: Unlike change password version + 1, the KRB-ERROR message will be sent back without any encapsulation. + + The user-data component of the KRB-PRIV message, or e-data component + of the KRB-ERROR message, must consist of the following data. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | result code | result string / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | edata / + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + result code (16 bits) (result codes 0-4 are from [4]): + The result code must have one of the following values (network + byte order): + KRB5_KPASSWD_SUCCESS 0 request succeeds (This value is not + allowed in a KRB-ERROR message) + KRB5_KPASSWD_MALFORMED 1 request fails due to being malformed + KRB5_KPASSWD_HARDERROR 2 request fails due to "hard" error in + processing the request (for example, + there is a resource or other problem + causing the request to fail) + KRB5_KPASSWD_AUTHERROR 3 request fails due to an error in + authentication processing + KRB5_KPASSWD_SOFTERROR 4 request fails due to a soft error + in processing the request + KRB5_KPASSWD_ACCESSDENIED 5 requestor not authorized + KRB5_KPASSWD_BAD_VERSION 6 protocol version unsupported + KRB5_KPASSWD_INITIAL_FLAG_NEEDED 7 initial flag required + KRB5_KPASSWD_POLICY_REJECT 8 new cleartext password fails policy; + the result string should include a text message to be presented + to the user. + KRB5_KPASSWD_BAD_PRINCIPAL 9 target principal does not exist + (only in response to a set password request). + KRB5_KPASSWD_ETYPE_NOSUPP 10 the request contains a key sequence + containing at least one etype that is not supported by the KDC. + The response edata contains an ASN.1 encoded PKERB-ETYPE-INFO + type that specifies the etypes that the KDC supports: + + KERB-ETYPE-INFO-ENTRY :: = SEQUENCE { + encryption-type[0] INTEGER, + salt[1] OCTET STRING OPTIONAL -- not sent + } + + PKERB-ETYPE-INFO ::= SEQUENCE OF KERB-ETYPE-INFO-ENTRY + + The client should retry the request using only etypes (keytypes) + that are contained within the PKERB-ETYPE-INFO structure in the + previous response. + 0xFFFF if the request fails for some other reason. + The client must interpret any non-zero result code as a failure. + result string - from [4]: + This field is a UTF-8 encoded string which should be displayed + to the user by the client. Specific reasons for a password + set/change policy failure is one use for this string. + edata: used to convey additional information as defined by the + result code. + +4. References + + [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP + 9, RFC 2026, October 1996. + + [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997 + + [3] J. Kohl, C. Neuman. The Kerberos Network Authentication + Service (V5), Request for Comments 1510. + + [4] M. Horowitz. Kerberos Change Password Protocol, + ftp://ds.internic.net/internet-drafts/ + draft-ietf-cat-kerb-chg-password-02.txt + +5. Expiration Date + + This draft expires in September 2000. + +6. Authors' Addresses + + Jonathan Trostle + Cisco Systems + 170 W. Tasman Dr. + San Jose, CA 95134 + Email: jtrostle@cisco.com + + Mike Swift + 1 Microsoft Way + Redmond, WA 98052 + Email: mikesw@microsoft.com + + John Brezak + 1 Microsoft Way + Redmond, WA 98052 + Email: jbrezak@microsoft.com + + Bill Gossman + Cybersafe Corporation + 1605 NW Sammamish Rd. + Issaquah, WA 98027-5378 + Email: bill.gossman@cybersafe.com + |