idnits 2.17.1 draft-ietf-cat-kerberos-set-passwd-03.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 2) being 60 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 32 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([3], [4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 105 has weird spacing: '... passwd init...' -- 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 299 looks like a reference -- Missing reference section? '3' on line 305 looks like a reference -- Missing reference section? '4' on line 308 looks like a reference -- Missing reference section? '2' on line 302 looks like a reference -- Missing reference section? '0' on line 275 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 7 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-03.txt Microsoft 3 April 2000 Jonathan Trostle 4 Cisco Systems 5 John Brezak 6 Microsoft 7 Bill Gossman 8 Cybersafe 10 Kerberos Set/Change Password: Version 2 12 0. Status Of This Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026 [1]. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet- 25 Drafts as reference material or to cite them other than as 26 "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Comments and suggestions on this document are encouraged. Comments 35 on this document should be sent to the CAT working group discussion 36 list: 37 ietf-cat-wg@stanford.edu 39 1. Abstract 41 The Kerberos (RFC 1510 [3]) change password protocol (Horowitz [4]), 42 does not allow for an administrator to set a password for a new user. 43 This functionality is useful in some environments, and this proposal 44 extends [4] to allow password setting. The changes are: adding new 45 fields to the request message to indicate the principal which is 46 having its password set, not requiring the initial flag in the service 47 ticket, using a new protocol version number, and adding three new 48 result codes. We also extend the set/change protocol to allow a 49 client to send a sequence of keys to the KDC instead of a cleartext 50 password. If in the cleartext password case, the cleartext password 51 fails to satisfy password policy, the server should use the result 52 code KRB5_KPASSWD_POLICY_REJECT. 54 2. Conventions used in this document 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 58 this document are to be interpreted as described in RFC-2119 [2]. 60 3. The Protocol 62 The service must accept requests on UDP port 464 and TCP port 464 as 63 well. The protocol consists of a single request message followed by 64 a single reply message. For UDP transport, each message must be fully 65 contained in a single UDP packet. 67 For TCP transport, there is a 4 octet header in network byte order 68 precedes the message and specifies the length of the message. This 69 requirement is consistent with the TCP transport header in 1510bis. 71 Request Message 73 0 1 2 3 74 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 75 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 76 | message length | protocol version number | 77 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 78 | AP_REQ length | AP-REQ data / 79 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 80 / KRB-PRIV message / 81 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 83 All 16 bit fields are in network byte order. 85 message length field: contains the number of bytes in the message 86 including this field. 88 protocol version number: contains the hex constant 0x0002 (network 89 byte order). 91 AP-REQ length: length of AP-REQ data, in bytes. If the length is zero, 92 then the last field contains a KRB-ERROR message instead of a KRB-PRIV 93 message. 95 AP-REQ data: (see [3]) For a change password/key request, the AP-REQ 96 message service ticket sname, srealm principal identifier is 97 kadmin/changepw@REALM where REALM is the realm of the change password 98 service. The same applies to a set password/key request except the 99 principal identifier is kadmin/setpw@REALM. The ticket in the AP-REQ 100 must include a subkey in the Authenticator. To enable setting of 101 passwords/keys, it is not required that the initial flag be set in the 102 Kerberos service ticket. The initial flag is required for change requests, 103 but not for set requests. We have the following definitions: 105 old passwd initial flag target principal can be 106 in request? required? distinct from 107 authenticating principal? 109 change password: yes yes no 111 set password: no policy (*) yes 113 set key: no policy (*) yes 115 change key: no yes no 116 policy (*): implementations SHOULD allow administrators to set the 117 initial flag required for set requests policy to either yes or no. 118 Clients MUST be able to retry set requests that fail due to error 7 119 (initial flag required) with an initial ticket. Clients SHOULD NOT 120 cache service tickets targetted at kadmin/changepw. 122 KRB-PRIV message (see [3]) This KRB-PRIV message must be generated 123 using the subkey from the authenticator in the AP-REQ data. 125 The user-data component of the message consists of the following ASN.1 126 structure encoded as an OCTET STRING: 128 ChangePasswdData :: = SEQUENCE { 129 newpasswdorkeys[0] NewPasswdOrKeys, 130 targname[1] PrincipalName OPTIONAL, 131 -- only present in set password/key: the principal 132 -- which will have its password or keys set. Not 133 -- present in a set request if the client principal 134 -- from the ticket is the principal having its 135 -- passwords or keys set. 136 targrealm[2] Realm OPTIONAL, 137 -- only present in set password/key: the realm for 138 -- the principal which will have its password or 139 -- keys set. Not present in a set request if the 140 -- client principal from the ticket is the principal 141 -- having its passwords or keys set. 142 } 144 NewPasswdOrKeys :: = CHOICE { 145 passwords[0] PasswordSequence, -- change/set passwd 146 keyseq[1] KeySequences -- change/set key 147 } 149 KeySequences :: = SEQUENCE OF KeySequence 151 KeySequence :: = SEQUENCE { 152 key[0] EncryptionKey, 153 salt[1] OCTET STRING OPTIONAL, 154 salt-type[2] INTEGER OPTIONAL 155 } 157 PasswordSequence :: = SEQUENCE { 158 newpasswd[0] OCTET STRING, 159 oldpasswd[1] OCTET STRING OPTIONAL 160 -- oldpasswd always present for change password 161 -- but not present for set password, set key, or 162 -- change key 163 } 165 The server must verify the AP-REQ message, check whether the client 166 principal in the ticket is authorized to set or change the password 167 (either for that principal, or for the principal in the targname 168 field if present), and decrypt the new password/keys. The server 169 also checks whether the initial flag is required for this request, 170 replying with status 0x0007 if it is not set and should be. An 171 authorization failure is cause to respond with status 0x0005. For 172 forward compatibility, the server should be prepared to ignore fields 173 after targrealm in the structure that it does not understand. 175 The newpasswdorkeys field contains either the new cleartext password 176 (with the old cleartext password for a change password operation), 177 or a sequence of encryption keys with their respective salts. 179 In the cleartext password case, if the old password is sent in the 180 request, the request MUST be a change password request. If the old 181 password is not present in the request, the request MUST be a set 182 password request. The server should apply policy checks to the old 183 and new password after verifying that the old password is valid. 184 The server can check validity by obtaining a key from the old 185 password with a keytype that is present in the KDC database for the 186 user and comparing the keys for equality. The server then generates 187 the appropriate keytypes from the password and stores them in the KDC 188 database. If all goes well, status 0x0000 is returned to the client 189 in the reply message (see below). For a change password operation, 190 the initial flag in the service ticket MUST be set. 192 In the key sequence case, the sequence of keys is sent to the change 193 or set password service (kadmin/changepw or kadmin/setpw respectively). 194 For a principal that can act as a server, its preferred keytype should 195 be sent as the first key in the sequence, but the KDC is not required 196 to honor this preference. Application servers should use the key 197 sequence option for changing/setting their keys. The change/set password 198 services should check that all keys are in the proper format, returning 199 the KRB5_KPASSWD_MALFORMED error otherwise. 201 Reply Message 203 0 1 2 3 204 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 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | message length | protocol version number | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | AP_REP length | AP-REP data / 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 / KRB-PRIV message / 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 All 16 bit fields are in network byte order. 215 message length field: contains the number of bytes in the message 216 including this field. 218 protocol version number: contains the hex constant 0x0002 (network 219 byte order). (The reply message has the same format as in [4]). 221 AP-REP length: length of AP-REP data, in bytes. If the length is zero, 222 then the last field contains a KRB-ERROR message instead of a KRB-PRIV 223 message. 225 AP-REP data: the AP-REP is the response to the AP-REQ in the request 226 packet. 228 KRB-PRIV from [4]: This KRB-PRIV message must be generated using the 229 subkey in the authenticator in the AP-REQ data. 231 The server will respond with a KRB-PRIV message unless it cannot 232 validate the client AP-REQ or KRB-PRIV message, in which case it will 233 respond with a KRB-ERROR message. NOTE: Unlike change password version 234 1, the KRB-ERROR message will be sent back without any encapsulation. 236 The user-data component of the KRB-PRIV message, or e-data component 237 of the KRB-ERROR message, must consist of the following data. 239 0 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | result code | result string / 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | edata / 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 result code (16 bits) (result codes 0-4 are from [4]): 248 The result code must have one of the following values (network 249 byte order): 250 KRB5_KPASSWD_SUCCESS 0 request succeeds (This value is not 251 allowed in a KRB-ERROR message) 252 KRB5_KPASSWD_MALFORMED 1 request fails due to being malformed 253 KRB5_KPASSWD_HARDERROR 2 request fails due to "hard" error in 254 processing the request (for example, 255 there is a resource or other problem 256 causing the request to fail) 257 KRB5_KPASSWD_AUTHERROR 3 request fails due to an error in 258 authentication processing 259 KRB5_KPASSWD_SOFTERROR 4 request fails due to a soft error 260 in processing the request 261 KRB5_KPASSWD_ACCESSDENIED 5 requestor not authorized 262 KRB5_KPASSWD_BAD_VERSION 6 protocol version unsupported 263 KRB5_KPASSWD_INITIAL_FLAG_NEEDED 7 initial flag required 264 KRB5_KPASSWD_POLICY_REJECT 8 new cleartext password fails policy; 265 the result string should include a text message to be presented 266 to the user. 267 KRB5_KPASSWD_BAD_PRINCIPAL 9 target principal does not exist 268 (only in response to a set password request). 269 KRB5_KPASSWD_ETYPE_NOSUPP 10 the request contains a key sequence 270 containing at least one etype that is not supported by the KDC. 271 The response edata contains an ASN.1 encoded PKERB-ETYPE-INFO 272 type that specifies the etypes that the KDC supports: 274 KERB-ETYPE-INFO-ENTRY :: = SEQUENCE { 275 encryption-type[0] INTEGER, 276 salt[1] OCTET STRING OPTIONAL -- not sent 277 } 279 PKERB-ETYPE-INFO ::= SEQUENCE OF KERB-ETYPE-INFO-ENTRY 281 The client should retry the request using only etypes (keytypes) 282 that are contained within the PKERB-ETYPE-INFO structure in the 283 previous response. 284 0xFFFF if the request fails for some other reason. 285 The client must interpret any non-zero result code as a failure. 286 result string - from [4]: 287 This field is a UTF-8 encoded string which should be displayed 288 to the user by the client. Specific reasons for a password 289 set/change policy failure is one use for this string. 290 edata: used to convey additional information as defined by the 291 result code. 293 4. Acknowledgements 295 The authors thank Tony Andrea for his input to the document. 297 5. References 299 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 300 9, RFC 2026, October 1996. 302 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 303 Levels", BCP 14, RFC 2119, March 1997 305 [3] J. Kohl, C. Neuman. The Kerberos Network Authentication 306 Service (V5), Request for Comments 1510. 308 [4] M. Horowitz. Kerberos Change Password Protocol, 309 ftp://ds.internic.net/internet-drafts/ 310 draft-ietf-cat-kerb-chg-password-02.txt 312 6. Expiration Date 314 This draft expires in October 2000. 316 7. Authors' Addresses 318 Jonathan Trostle 319 Cisco Systems 320 170 W. Tasman Dr. 321 San Jose, CA 95134 322 Email: jtrostle@cisco.com 324 Mike Swift 325 1 Microsoft Way 326 Redmond, WA 98052 327 Email: mikesw@microsoft.com 329 John Brezak 330 1 Microsoft Way 331 Redmond, WA 98052 332 Email: jbrezak@microsoft.com 334 Bill Gossman 335 Cybersafe Corporation 336 1605 NW Sammamish Rd. 337 Issaquah, WA 98027-5378 338 Email: bill.gossman@cybersafe.com