diff options
Diffstat (limited to 'crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-03.txt')
| -rw-r--r-- | crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-03.txt | 345 |
1 files changed, 0 insertions, 345 deletions
diff --git a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-03.txt b/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-03.txt deleted file mode 100644 index 0319f8b..0000000 --- a/crypto/heimdal/doc/standardisation/draft-ietf-cat-kerberos-set-passwd-03.txt +++ /dev/null @@ -1,345 +0,0 @@ - -INTERNET-DRAFT Mike Swift -draft-ietf-cat-kerberos-set-passwd-03.txt Microsoft -April 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]) For a change password/key request, the AP-REQ - message service ticket sname, srealm principal identifier is - kadmin/changepw@REALM where REALM is the realm of the change password - service. The same applies to a set password/key request except the - principal identifier is kadmin/setpw@REALM. The ticket in the AP-REQ - 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 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 policy (*) yes - - set key: no policy (*) yes - - change key: no yes no - - policy (*): implementations SHOULD allow administrators to set the - initial flag required for set requests policy to either yes or no. - Clients MUST be able to retry set requests that fail due to error 7 - (initial flag required) with an initial ticket. Clients SHOULD NOT - cache service tickets targetted at kadmin/changepw. - - 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/key: the principal - -- which will have its password or keys set. Not - -- present in a set request if the client principal - -- from the ticket is the principal having its - -- passwords or keys set. - targrealm[2] Realm OPTIONAL, - -- only present in set password/key: the realm for - -- the principal which will have its password or - -- keys set. Not present in a set request if the - -- client principal from the ticket is the principal - -- having its passwords or keys set. - } - - NewPasswdOrKeys :: = CHOICE { - passwords[0] PasswordSequence, -- change/set passwd - keyseq[1] KeySequences -- change/set key - } - - 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, set key, or - -- change key - } - - 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 MUST be a change password request. If the old - password is not present in the request, the request MUST be 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 change - or set password service (kadmin/changepw or kadmin/setpw respectively). - 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 change/set password - services 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. Acknowledgements - - The authors thank Tony Andrea for his input to the document. - -5. 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 - -6. Expiration Date - - This draft expires in October 2000. - -7. 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 - |
