idnits 2.17.1 draft-ietf-cat-kerberos-set-passwd-04.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 3 longer pages, the longest (page 4) 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 64 instances of too long lines in the document, the longest one being 6 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 372 looks like a reference -- Missing reference section? '3' on line 378 looks like a reference -- Missing reference section? '4' on line 381 looks like a reference -- Missing reference section? '2' on line 375 looks like a reference -- Missing reference section? '0' on line 315 looks like a reference Summary: 7 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-04.txt University of WA 3 March 2001 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: ietf-cat-wg@stanford.edu. 38 This draft expires on September 30th, 2001. 40 1. Abstract 42 The Kerberos (RFC 1510 [3]) change password protocol (Horowitz [4]), 43 does not allow for an administrator to set a password for a new user. 44 This functionality is useful in some environments, and this proposal 45 extends [4] to allow password setting. The changes are: adding new 46 fields to the request message to indicate the principal which is 47 having its password set, not requiring the initial flag in the service 48 ticket, using a new protocol version number, and adding three new 49 result codes. We also extend the set/change protocol to allow a 50 client to send a sequence of keys to the KDC instead of a cleartext 51 password. If in the cleartext password case, the cleartext password 52 fails to satisfy password policy, the server should use the result 53 code KRB5_KPASSWD_POLICY_REJECT. 55 2. Conventions used in this document 57 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 58 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 59 this document are to be interpreted as described in RFC-2119 [2]. 61 3. The Protocol 63 The service MUST accept requests on UDP port 464 and TCP port 464 as 64 well. The protocol consists of a single request message followed by 65 a single reply message. For UDP transport, each message must be fully 66 contained in a single UDP packet. 68 For TCP transport, there is a 4 octet header in network byte order 69 precedes the message and specifies the length of the message. This 70 requirement is consistent with the TCP transport header in 1510bis. 72 Request Message 74 0 1 2 3 75 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 76 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 77 | message length | protocol version number | 78 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 79 | AP_REQ length | AP-REQ data / 80 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 81 / KRB-PRIV message / 82 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 84 All 16 bit fields are in network byte order. 86 message length field: contains the number of bytes in the message 87 including this field. 89 protocol version number: contains the hex constant 0x0002 (network 90 byte order). 92 AP-REQ length: length of AP-REQ data, in bytes. If the length is zero, 93 then the last field contains a KRB-ERROR message instead of a KRB-PRIV 94 message. 96 AP-REQ data: (see [3]) For a change password/key request, the AP-REQ 97 message service ticket sname, srealm principal identifier is 98 kadmin/changepw@REALM where REALM is the realm of the change password 99 service. The same applies to a set password/key request except the 100 principal identifier is kadmin/setpw@REALM. 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 117 policy (*): implementations SHOULD allow administrators to set the 118 initial flag required for set requests policy to either yes or no. 119 Clients MUST be able to retry set requests that fail due to error 7 120 (initial flag required) with an initial ticket. Clients SHOULD NOT 121 cache service tickets targetted at kadmin/changepw. 123 KRB-PRIV message (see [3]) This KRB-PRIV message must be encrypted 124 using the session key from the ticket in the AP-REQ. 126 The user-data component of the message consists of the following ASN.1 127 encoded structure: 129 ChangePasswdData :: = SEQUENCE { 130 newpasswdorkeys[0] NewPasswdOrKeys, 131 targname[1] PrincipalName OPTIONAL, 132 -- only present in set password/key: the principal 133 -- which will have its password or keys set. Not 134 -- present in a set request if the client principal 135 -- from the ticket is the principal having its 136 -- passwords or keys set. 137 targrealm[2] Realm OPTIONAL, 138 -- only present in set password/key: the realm for 139 -- the principal which will have its password or 140 -- keys set. Not present in a set request if the 141 -- client principal from the ticket is the principal 142 -- having its passwords or keys set. 143 flags[3] RequestFlags OPTIONAL 144 -- 32 bit string 145 } 147 NewPasswdOrKeys :: = CHOICE { 148 passwords[0] PasswordSequence, -- change/set passwd 149 keyseq[1] KeySequences -- change/set key 150 } 152 KeySequences :: = SEQUENCE OF KeySequence 154 KeySequence :: = SEQUENCE { 155 key[0] EncryptionKey, 156 salt[1] OCTET STRING OPTIONAL, 157 salt-type[2] INTEGER OPTIONAL 158 } 159 PasswordSequence :: = SEQUENCE { 160 newpasswd[0] OCTET STRING, 161 oldpasswd[1] OCTET STRING OPTIONAL 162 -- oldpasswd always present for change password 163 -- but not present for set password, set key, or 164 -- change key 165 } 167 RequestFlags :: = BIT STRING { 168 reserved(0), 169 request-srv-gen-keys(1) -- only in change/set keys 170 -- if the client desires 171 -- server to contribute to keys; 172 -- server will return keys 173 } 175 The server must verify the AP-REQ message, check whether the client 176 principal in the ticket is authorized to set or change the password 177 (either for that principal, or for the principal in the targname 178 field if present), and decrypt the new password/keys. The server 179 also checks whether the initial flag is required for this request, 180 replying with status 0x0007 if it is not set and should be. An 181 authorization failure is cause to respond with status 0x0005. For 182 forward compatibility, the server should be prepared to ignore fields 183 after targrealm in the structure that it does not understand. 185 The newpasswdorkeys field contains either the new cleartext password 186 (with the old cleartext password for a change password operation), 187 or a sequence of encryption keys with their respective salts. 189 In the cleartext password case, if the old password is sent in the 190 request, the request MUST be a change password request. If the old 191 password is not present in the request, the request MUST be a set 192 password request. The server should apply policy checks to the old 193 and new password after verifying that the old password is valid. 194 The server can check validity by obtaining a key from the old 195 password with a keytype that is present in the KDC database for the 196 user and comparing the keys for equality. The server then generates 197 the appropriate keytypes from the password and stores them in the KDC 198 database. If all goes well, status 0x0000 is returned to the client 199 in the reply message (see below). For a change password operation, 200 the initial flag in the service ticket MUST be set. 202 In the key sequence case, the sequence of keys is sent to the change 203 or set password service (kadmin/changepw or kadmin/setpw respectively). 204 For a principal that can act as a server, its preferred keytype should 205 be sent as the first key in the sequence, but the KDC is not required 206 to honor this preference. Application servers should use the key 207 sequence option for changing/setting their keys. The change/set password 208 services should check that all keys are in the proper format, returning 209 the KRB5_KPASSWD_MALFORMED error otherwise. 211 For change/set key, the request message may include the request flags bit 212 string with the request-srv-gen-keys bit set. In this case, the client 213 is requesting that the server add entropy to its keys in the KeySequences 214 field. When using this option, the client SHOULD attempt to generate 215 pseudorandom keys with as much entropy as possible in its request. The 216 server will return the final key sequence in a KeySequences structure in 217 the edata of the reply message. The server does not store any of the 218 new keys at this point. The client MUST make a subsequent change/set 219 key request without the request-srv-gen-keys bit; if the server returns 220 KRB5_KPASSWD_SUCCESS for this second request, then the new keys have 221 been written into the database. A conformant server MUST support this 222 option. 224 Reply Message 226 0 1 2 3 227 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 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | message length | protocol version number | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | AP_REP length | AP-REP data / 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 / KRB-PRIV message / 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 All 16 bit fields are in network byte order. 238 message length field: contains the number of bytes in the message 239 including this field. 241 protocol version number: contains the hex constant 0x0002 (network 242 byte order). (The reply message has the same format as in [4]). 244 AP-REP length: length of AP-REP data, in bytes. If the length is zero, 245 then the last field contains a KRB-ERROR message instead of a KRB-PRIV 246 message. An implementation should check this field to determine 247 whether a KRB-ERROR message or KRB-PRIV message has been returned. 249 AP-REP data: the AP-REP is the response to the AP-REQ in the request 250 packet. 252 KRB-PRIV from [4]: This KRB-PRIV message must be encrypted using the 253 session key from the ticket in the AP-REQ. 255 The server will respond with a KRB-PRIV message unless it cannot 256 validate the client AP-REQ or KRB-PRIV message, in which case it will 257 respond with a KRB-ERROR message. 259 The user-data component of the KRB-PRIV message, or e-data component 260 of the KRB-ERROR message, must consist of the following data. 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | result code | minor status | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | key version (only on success) | edata / 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 result code (16 bits) (result codes 0-4 are from [4]): 271 The result code must have one of the following values (network 272 byte order): 274 KRB5_KPASSWD_SUCCESS 0 request succeeds (This value is 275 not allowed in a KRB-ERROR 276 message) 277 KRB5_KPASSWD_MALFORMED 1 request fails due to being 278 malformed 280 KRB5_KPASSWD_HARDERROR 2 request fails due to "hard" 281 error in processing the request 282 (for example, there is a resource 283 or other problem causing the 284 request to fail) 286 KRB5_KPASSWD_AUTHERROR 3 request fails due to an error in 287 authentication processing 289 KRB5_KPASSWD_SOFTERROR 4 request fails due to a soft 290 error in processing the request 292 KRB5_KPASSWD_ACCESSDENIED 5 requestor not authorized 294 KRB5_KPASSWD_BAD_VERSION 6 protocol version unsupported 296 KRB5_KPASSWD_INITIALFLAG_NEEDED 7 initial flag required 298 KRB5_KPASSWD_POLICY_REJECT 8 new cleartext password fails 299 policy; the result string should 300 include a text message to be 301 presented to the user. 303 KRB5_KPASSWD_BAD_PRINCIPAL 9 target principal does not exist 304 (only in response to a set 305 password or set key request). 307 KRB5_KPASSWD_ETYPE_NOSUPP 10 the request contains a key sequence 308 containing at least one etype that is 309 not supported by the KDC. The response 310 edata contains an ASN.1 encoded 311 PKERB-ETYPE-INFO type that specifies 312 the etypes that the KDC supports: 314 KERB-ETYPE-INFO-ENTRY :: = SEQUENCE { 315 encryption-type[0] INTEGER, 316 salt[1] OCTET STRING 317 OPTIONAL -- not sent, client 318 -- ignores if sent 319 } 321 PKERB-ETYPE-INFO ::= SEQUENCE OF 322 KERB-ETYPE-INFO-ENTRY 324 The client should retry the request 325 using only etypes (keytypes) that are 326 contained within the PKERB-ETYPE-INFO 327 structure in the previous response. 329 KRB5_KPASSWD_ETYPE_SRVGENKEYS 11 the request has the request- 330 srv-gen-keys flag set and the 331 server is returning the 332 KeySequence structure defined 333 above in the edata field of the 334 reply. The server returns one key 335 sequence structure of the same 336 keytype for each key sequence 337 structure in the client request, 338 unless it does not support one of 339 the keytypes (or etypes). In that 340 case, it returns error 341 KRB5_KPASSWD_ETYPE_NOSUPP as 342 discussed above. The server MUST 343 add keylength number of bits of 344 entropy to each key. The assumption 345 here is that the client may have 346 added insufficient entropy to the 347 request keys. The server SHOULD use 348 the client key from each 349 KeySequence structure as input 350 into the final keyvalue for the 351 returned key. 353 0xFFFF is returned if the request fails for some other reason. 354 The client must interpret any non-zero result code as a failure. 355 minor status (16 bits): 356 This field contains a minor status code. It can be used to index 357 into a catalog of strings and the indexed string can then be 358 displayed to the user. Additional information on a password 359 set/change policy failure is one use for this string. 360 key version (16 bits - optional): present if and only if the result 361 code is KRB5_KPASSWD_SUCCESS. This contains the key version of 362 the new key(s). 363 edata: used to convey additional information as defined by the 364 result code. 366 4. Acknowledgements 368 The authors thank Tony Andrea for his input to the document. 370 5. References 372 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 373 9, RFC 2026, October 1996. 375 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 376 Levels", BCP 14, RFC 2119, March 1997 378 [3] J. Kohl, C. Neuman. The Kerberos Network Authentication 379 Service (V5), Request for Comments 1510. 381 [4] M. Horowitz. Kerberos Change Password Protocol, 382 ftp://ds.internic.net/internet-drafts/ 383 draft-ietf-cat-kerb-chg-password-02.txt 385 6. Expiration Date 387 This draft expires on September 30th, 2001. 389 7. Authors' Addresses 391 Jonathan Trostle 392 Cisco Systems 393 170 W. Tasman Dr. 394 San Jose, CA 95134 395 Email: jtrostle@cisco.com 397 Mike Swift 398 University of Washington 399 Seattle, WA 400 Email: mikesw@cs.washington.edu 402 John Brezak 403 1 Microsoft Way 404 Redmond, WA 98052 405 Email: jbrezak@microsoft.com 407 Bill Gossman 408 Cybersafe Corporation 409 1605 NW Sammamish Rd. 410 Issaquah, WA 98027-5378 411 Email: bill.gossman@cybersafe.com