diff options
Diffstat (limited to 'crypto/heimdal/doc/standardisation/draft-trostle-win2k-cat-kerberos-set-passwd-00.txt')
| -rw-r--r-- | crypto/heimdal/doc/standardisation/draft-trostle-win2k-cat-kerberos-set-passwd-00.txt | 227 |
1 files changed, 0 insertions, 227 deletions
diff --git a/crypto/heimdal/doc/standardisation/draft-trostle-win2k-cat-kerberos-set-passwd-00.txt b/crypto/heimdal/doc/standardisation/draft-trostle-win2k-cat-kerberos-set-passwd-00.txt deleted file mode 100644 index b89108a53be9f..0000000000000 --- a/crypto/heimdal/doc/standardisation/draft-trostle-win2k-cat-kerberos-set-passwd-00.txt +++ /dev/null @@ -1,227 +0,0 @@ - -CAT Working Group Mike Swift -draft-trostle-win2k-cat-kerberos-set-passwd-00.txt Microsoft -February 2000 Jonathan Trostle -Category: Informational Cisco Systems - John Brezak - Microsoft - - Extending Change Password for Setting Kerberos Passwords - - -0. Status Of This Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of 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. - - 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 [1] change password protocol [2], 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 [2] 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. - -2. 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 big-endian order. - - message length field: contains the number of bytes in the message - including this field. - - protocol version number: contains the hex constant 0xff80 (big-endian - integer). - - 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 [1]) 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, it is not required that the initial flag be set in the - Kerberos service ticket. - - KRB-PRIV message (see [1]) 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 { - newpasswd[0] OCTET STRING, - targname[2] PrincipalName OPTIONAL, - targrealm[3] Realm OPTIONAL - } - - The server must verify the AP-REQ message, check whether the client - principal in the ticket is authorized to set/change the password - (either for that principal, or for the principal in the targname - field if present), and decrypt the new password. 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 newpasswd field contains the cleartext password, and the server - should apply any local policy checks including password policy checks. - 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). - -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 big-endian order. - - message length field: contains the number of bytes in the message - including this field. - - protocol version number: contains the hex constant 0x0001 (big-endian - integer). (The reply message has the same format as in [2]). - - 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 [2]: 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 - decode 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 / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - - result code (16 bits) (result codes 0-4 are from [2]): - The result code must have one of the following values (big- - endian integer): - 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 - 0xFFFF if the request fails for some other reason. - Although only a few non-zero result codes are specified here, - the client should accept any non-zero result code as indicating - failure. - result string - from [2]: - This field should contain information which the server thinks - might be useful to the user, such as feedback about policy - failures. The string must be encoded in UTF-8. It may be - omitted if the server does not wish to include it. If it is - present, the client should display the string to the user. - This field is analogous to the string which follows the numeric - code in SMTP, FTP, and similar protocols. - -3. References - - [1] J. Kohl, C. Neuman. The Kerberos Network Authentication - Service (V5). Request for Comments 1510. - - [2] M. Horowitz. Kerberos Change Password Protocol. - ftp://ds.internic.net/internet-drafts/ - draft-ietf-cat-kerb-chg-password-02.txt - -4. Expiration Date - - This draft expires in August 2000. - -5. 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 - mikesw@microsoft.com - - John Brezak - 1 Microsoft Way - Redmond, WA 98052 - jbrezak@microsoft.com |