diff options
Diffstat (limited to 'doc/rfc/rfc3244.txt')
| -rw-r--r-- | doc/rfc/rfc3244.txt | 395 |
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc3244.txt b/doc/rfc/rfc3244.txt new file mode 100644 index 0000000..0ba07ba --- /dev/null +++ b/doc/rfc/rfc3244.txt @@ -0,0 +1,395 @@ + + + + + + +Network Working Group M. Swift +Request for Comments: 3244 University of Washington +Category: Informational J. Trostle + Cisco Systems + J. Brezak + Microsoft + February 2002 + + + Microsoft Windows 2000 Kerberos Change Password + and Set Password Protocols + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + This memo specifies Microsoft's Windows 2000 Kerberos change password + and set password protocols. The Windows 2000 Kerberos change + password protocol interoperates with the original Kerberos change + password protocol. Change password is a request reply protocol that + includes a KRB_PRIV message that contains the new password for the + user. + +1. Introduction + + Microsoft's Windows 2000 Kerberos change password protocol + interoperates with the original Kerberos change password protocol. + Change password is a request reply protocol that includes a KRB_PRIV + message that contains the new password for the user. The original + change password protocol does not allow an administrator to set a + password for a new user. This functionality is useful in some + environments, and this proposal extends the change password protocol + 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. + + + + + + +Swift, et al. Informational [Page 1] + +RFC 3244 Microsoft Windows 2000 Kerberos Change & Set February 2002 + + +2. The Protocol + + The service accepts 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 + that precedes the message and specifies the length of the message. + + 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 authenticator in the AP- + REQ must include a subsession key. (NOTE: The subsession key must be + pseudo-randomly generated and must never be reused for multiple + authenticators.) 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 user-data field in the KRB-PRIV + message is encrypted using the subkey from the authenticator in the + AP-REQ data. The usec and seq-number fields of the KRB_PRIV message + are present and have the same value as the seq-number field in the + + + + + +Swift, et al. Informational [Page 2] + +RFC 3244 Microsoft Windows 2000 Kerberos Change & Set February 2002 + + + authenticator from the AP_REQ message (the seq-number in the + authenticator will be present). The server ignores the optional + r-address field in the KRB_PRIV message, if it is present. + + 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[1] PrincipalName OPTIONAL, + targrealm[2] 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 + will 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. + + + + + + +Swift, et al. Informational [Page 3] + +RFC 3244 Microsoft Windows 2000 Kerberos Change & Set February 2002 + + + protocol version number: contains the hex constant 0x0001 (big-endian + integer). (The reply message has the same format as the original + change password protocol.) + + 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 message: This KRB-PRIV message must be encrypted with the + subsession key from 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, consists 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 the original change + password protocol): + + 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) + + + +Swift, et al. Informational [Page 4] + +RFC 3244 Microsoft Windows 2000 Kerberos Change & Set February 2002 + + + 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 is returned 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: + + This field contains information which might be useful to the user, + such as feedback about policy failures. The string is encoded in + UTF-8. It may be omitted if the server does not wish to include + it. If it is present, the client will display the string to the + user. + +3. Security Considerations + + Password policies should be enforced to make sure that users do not + pick passwords (for change password) that are vulnerable to brute + force password guessing attacks. An administrator who is authorized + to set other principal's passwords is highly trusted and must also + carefully protect his/her own credentials. + +4. References + + [1] Kohl, J. and C. Neuman, "The Kerberos Network Authentication + Service (V5)", RFC 1510, September 1993. + + + + + + + + + + + + + +Swift, et al. Informational [Page 5] + +RFC 3244 Microsoft Windows 2000 Kerberos Change & Set February 2002 + + +5. Authors' Addresses + + Mike Swift + University of Washington + Seattle, WA + + EMail: mikesw@cs.washington.edu + + + Jonathan Trostle + Cisco Systems + 170 W. Tasman Dr. + San Jose, CA 95134 + + EMail: john3725@world.std.com + + + John Brezak + Microsoft + 1 Microsoft Way + Redmond, WA 98052 + + EMail: jbrezak@microsoft.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Swift, et al. Informational [Page 6] + +RFC 3244 Microsoft Windows 2000 Kerberos Change & Set February 2002 + + +6. Full Copyright Statement + + Copyright (C) The Internet Society (2002). 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 + 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. + + + + + + + + + + + + + + + + + + + +Swift, et al. Informational [Page 7] + |