idnits 2.17.1 draft-ietf-cat-kerberos-set-passwd-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 227 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 11 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 100: '... targname[2] PrincipalName OPTIONAL,...' RFC 2119 keyword, line 101: '... targrealm[3] Realm OPTIONAL...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 198 looks like a reference -- Missing reference section? '2' on line 201 looks like a reference -- Missing reference section? '0' on line 99 looks like a reference -- Missing reference section? '3' on line 101 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Mike Swift 2 draft-ietf-cat-kerberos-set-passwd-00.txt Microsoft 3 expires March, 2000 Jonathan Trostle 4 Cisco Systems 5 John Brezak 6 Microsoft 8 Extending Change Password for Setting Kerberos Passwords 10 0. Status Of This Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as 24 "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Comments and suggestions on this document are encouraged. Comments 33 on this document should be sent to the CAT working group discussion 34 list: 35 ietf-cat-wg@stanford.edu 37 This document expires in March, 2000. 39 1. Abstract 41 The Kerberos [1] change password protocol [2], does not allow for 42 an administrator to set a password for a new user. This functionality 43 is useful in some environments, and this proposal extends [2] to 44 allow password setting. The changes are: adding new fields to the 45 request message to indicate the principal which is having its 46 password set, not requiring the initial flag in the service ticket, 47 using a new protocol version number, and adding three new result 48 codes. 50 2. The Protocol 52 The service must accept requests on UDP port 464 and TCP port 464 as 53 well. The protocol consists of a single request message followed by 54 a single reply message. For UDP transport, each message must be fully 55 contained in a single UDP packet. 57 For TCP transport, there is a 4 octet header in network byte order 58 precedes the message and specifies the length of the message. This 59 requirement is consistent with the TCP transport header in 1510bis. 61 Request Message 63 0 1 2 3 64 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 65 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 66 | message length | protocol version number | 67 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 68 | AP_REQ length | AP-REQ data / 69 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 70 / KRB-PRIV message / 71 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 73 All 16 bit fields are in big-endian order. 75 message length field: contains the number of bytes in the message 76 including this field. 78 protocol version number: contains the hex constant 0xff80 (big-endian 79 integer). 81 AP-REQ length: length of AP-REP data, in bytes. If the length is zero, 82 then the last field contains a KRB-ERROR message instead of a KRB-PRIV 83 message. 85 AP-REQ data: (see [1]) The AP-REQ message must be for the service 86 principal kadmin/changepw@REALM, where REALM is the REALM of the user 87 who wishes to change/set his password. The ticket in the AP-REQ must 88 must include a subkey in the Authenticator. 90 KRB-PRIV message (see [1]) This KRB-PRIV message must be generated 91 using the subkey from the authenticator in the AP-REQ data. The 92 initial flag of the service ticket is ignored by the server unless 93 policy dictates otherwise, in which case the request will be rejected 94 with result code 0x0007 if the initial flag is not set and is required 95 for this particular request. The user-data component of the message 96 consists of the following ASN.1 structure encoded as an OCTET STRING: 98 ChangePasswdData ::= SEQUENCE { 99 newpasswd[0] OCTET STRING, 100 targname[2] PrincipalName OPTIONAL, 101 targrealm[3] Realm OPTIONAL 102 } 104 The server must verify the AP-REQ message, check whether the client 105 principal in the ticket is authorized to set/change the password 106 (either for that principal, or for the principal in the targname 107 field if present), and decrypt the new password. The server also 108 checks whether the initial flag is required for this request, 109 replying with status 0x0007 if it is not set and should be. An 110 authorization failure is cause to respond with status 0x0005. For 111 forward compatibility, the server should be prepared to ignore fields 112 after targrealm in the structure that it does not understand. 114 The newpasswd field contains the cleartext password, and the server 115 should apply any local policy checks including password policy checks. 116 The server then generates the appropriate keytypes from the password 117 and stores them in the KDC database. If all goes well, status 0x0000 118 is returned to the client in the reply message (see below). 120 Reply Message 122 0 1 2 3 123 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 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | message length | protocol version number | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | AP_REP length | AP-REP data / 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 / KRB-PRIV or KRB-ERROR message / 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 All 16 bit fields are in big-endian order. 134 message length field: contains the number of bytes in the message 135 including this field. 137 protocol version number: contains the hex constant 0x0001 (big-endian 138 integer). (The reply message has the same format as in [2]). 140 AP-REP length: length of AP-REP data, in bytes. If the length is zero, 141 then the last field contains a KRB-ERROR message instead of a KRB-PRIV 142 message. 144 AP-REP data: the AP-REP is the response to the AP-REQ in the request 145 packet. 147 KRB-PRIV or KRB-ERROR message: - from [2]: if the AP-REP length is 148 zero, then this field contains a KRB-ERROR message. Otherwise, it 149 contains a KRB-PRIV message. This KRB-PRIV message must be generated 150 using the subkey in the authenticator in the AP-REQ data. 152 The server will respond with a KRB-PRIV message unless it cannot 153 decode the client AP-REQ or KRB-PRIV message, in which case it will 154 respond with a KRB-ERROR message. 156 The user-data component of the KRB-PRIV message, or e-data component 157 of the KRB-ERROR message, must consist of the following data. 159 0 1 2 3 160 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 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | result code | result string / 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 result code (16 bits) (result codes 0-4 are from [2]): 166 The result code must have one of the following values (big- 167 endian integer): 168 KRB5_KPASSWD_SUCCESS 0 request succeeds (This value is not 169 allowed in a KRB-ERROR message) 171 KRB5_KPASSWD_MALFORMED 1 request fails due to being malformed 172 KRB5_KPASSWD_HARDERROR 2 request fails due to "hard" error in 173 processing the request (for example, 174 there is a resource or other problem 175 causing the request to fail) 176 KRB5_KPASSWD_AUTHERROR 3 request fails due to an error in 177 authentication processing 178 KRB5_KPASSWD_SOFTERROR 4 request fails due to a "soft" error 179 in processing the request 180 KRB5_KPASSWD_ACCESSDENIED 5 requestor not authorized 181 KRB5_KPASSWD_BAD_VERSION 6 protocol version unsupported 182 KRB5_KPASSWD_INITIAL_FLAG_NEEDED 7 initial flag required 183 0xFFFF if the request fails for some other reason. 184 Although only a few non-zero result codes are specified here, 185 the client should accept any non-zero result code as indicating 186 failure. 187 result string - from [2]: 188 This field should contain information which the server thinks 189 might be useful to the user, such as feedback about policy 190 failures. The string must be encoded in UTF-8. It may be 191 omitted if the server does not wish to include it. If it is 192 present, the client should display the string to the user. 193 This field is analogous to the string which follows the numeric 194 code in SMTP, FTP, and similar protocols. 196 3. Bibliography 198 [1] J. Kohl, C. Neuman. The Kerberos Network Authentication 199 Service (V5). Request for Comments 1510. 201 [2] M. Horowitz. Kerberos Change Password Protocol. 202 ftp://ds.internic.net/internet-drafts/ 203 draft-ietf-cat-kerb-chg-password-02.txt 205 4. Expiration Date 207 This draft expires on March 31, 2000. 209 5. Authors' Addresses 211 Jonathan Trostle 212 Cisco Systems 213 170 W. Tasman Dr. 214 San Jose, CA 95134 216 Email: jtrostle@cisco.com, jtrostle@world.std.com 218 Mike Swift 219 1 Microsoft Way 220 Redmond, WA 98052 221 mikesw@microsoft.com 223 John Brezak 224 1 Microsoft Way 225 Redmond, WA 98052 226 jbrezak@microsoft.com