idnits 2.17.1 draft-ietf-cat-kerberos-set-passwd-06.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 13 longer pages, the longest (page 1) being 63 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 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 253 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: '6' is mentioned on line 170, but not defined == Missing Reference: '7' is mentioned on line 171, but not defined == Missing Reference: '0' is mentioned on line 498, but not defined -- Looks like a reference, but probably isn't: 'APPLICATION 14' on line 98 == Missing Reference: '4' is mentioned on line 301, but not defined -- Looks like a reference, but probably isn't: 'APPLICATION 1' on line 112 -- Looks like a reference, but probably isn't: 'APPLICATION 3' on line 120 == Missing Reference: '5' is mentioned on line 194, but not defined == Missing Reference: '8' is mentioned on line 172, but not defined == Missing Reference: '9' is mentioned on line 173, but not defined == Missing Reference: '10' is mentioned on line 174, but not defined -- Looks like a reference, but probably isn't: 'APPLICATION 2' on line 135 -- Looks like a reference, but probably isn't: 'APPLICATION 15' on line 147 -- Looks like a reference, but probably isn't: 'APPLICATION 27' on line 153 -- Looks like a reference, but probably isn't: 'APPLICATION 30' on line 163 == Missing Reference: '11' is mentioned on line 175, but not defined == Missing Reference: '12' is mentioned on line 176, but not defined -- Looks like a reference, but probably isn't: 'APPLICATION 21' on line 181 -- Looks like a reference, but probably isn't: 'APPLICATION 28' on line 187 ** Obsolete normative reference: RFC 1510 (ref. '3') (Obsoleted by RFC 4120, RFC 6649) Summary: 8 errors (**), 0 flaws (~~), 13 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Jonathan Trostle 3 INTERNET-DRAFT Cisco Systems 4 Category: Standards Track Mike Swift 5 University of WA 6 John Brezak 7 Microsoft 8 Bill Gossman 9 Cisco Systems 11 Kerberos Set/Change Password: Version 2 12 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026 [6]. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet- Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This draft expires on December 31st, 2001. Please send comments to 36 the authors. 38 1. Abstract 40 This proposal specifies a Kerberos (RFC 1510 [3]) change/set password 41 protocol and a Kerberos change/set key protocol. The protocol 42 consists of a single request and reply message. The request message 43 includes both AP-REQ and KRB-PRIV submessages; the new password is 44 contained in the KRB-PRIV submessage which is encrypted in the 45 subsession key from the AP-REQ. The original Kerberos change password 46 protocol did not allow for an administrator to set a password for a 47 new user. This functionality is useful in some environments, and this 48 proposal allows password setting as well as password changing. The 49 protocol includes fields in the request message to indicate the 50 principal which is having its password set. We also extend the 51 set/change protocol to allow a client to send a sequence of keys to 52 the KDC instead of a cleartext password. If in the cleartext password 53 case, the cleartext password fails to satisfy password policy, the 54 server should use the result code KRB5_KPASSWD_POLICY_REJECT. 56 2. Conventions used in this document 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 60 document are to be interpreted as described in RFC2119 [7]. 62 3. Definitions from RFC 1510 64 We include some of the relevant ASN.1 definitions from RFC 1510 in 65 this section. 67 Realm ::= GeneralString 69 PrincipalName ::= SEQUENCE { 70 name-type[0] INTEGER, 71 name-string[1] SEQUENCE OF GeneralString 72 } 74 KerberosTime ::= GeneralizedTime 75 -- Specifying UTC time zone (Z) 77 HostAddress ::= SEQUENCE { 78 addr-type[0] INTEGER, 79 address[1] OCTET STRING 80 } 82 EncryptedData ::= SEQUENCE { 83 etype[0] INTEGER, -- EncryptionType 84 kvno[1] INTEGER OPTIONAL, 85 cipher[2] OCTET STRING -- ciphertext 86 } 88 EncryptionKey ::= SEQUENCE { 89 keytype[0] INTEGER, 90 keyvalue[1] OCTET STRING 91 } 93 Checksum ::= SEQUENCE { 94 cksumtype[0] INTEGER, 95 checksum[1] OCTET STRING 96 } 98 AP-REQ ::= [APPLICATION 14] SEQUENCE { 99 pvno [0] INTEGER, -- indicates Version 5 100 msg-type [1] INTEGER, -- indicates KRB_AP_REQ 101 ap-options[2] APOptions, 102 ticket[3] Ticket, 103 authenticator[4] EncryptedData 104 } 105 APOptions ::= BIT STRING { 107 reserved (0), 108 use-session-key (1), 109 mutual-required (2) 110 } 112 Ticket ::= [APPLICATION 1] SEQUENCE { 113 tkt-vno [0] INTEGER, -- indicates Version 5 114 realm [1] Realm, 115 sname [2] PrincipalName, 116 enc-part [3] EncryptedData 117 } 119 -- Encrypted part of ticket 120 EncTicketPart ::= [APPLICATION 3] SEQUENCE { 121 flags[0] TicketFlags, 122 key[1] EncryptionKey, 123 crealm[2] Realm, 124 cname[3] PrincipalName, 125 transited[4] TransitedEncoding, 126 authtime[5] KerberosTime, 127 starttime[6] KerberosTime OPTIONAL, 128 endtime[7] KerberosTime, 129 renew-till[8] KerberosTime OPTIONAL, 130 caddr[9] HostAddresses OPTIONAL, 131 authorization-data[10] AuthorizationData OPTIONAL 132 } 134 -- Unencrypted authenticator 135 Authenticator ::= [APPLICATION 2] SEQUENCE { 136 authenticator-vno[0] INTEGER, 137 crealm[1] Realm, 138 cname[2] PrincipalName, 139 cksum[3] Checksum OPTIONAL, 140 cusec[4] INTEGER, 141 ctime[5] KerberosTime, 142 subkey[6] EncryptionKey OPTIONAL, 143 seq-number[7] INTEGER OPTIONAL, 144 authorization-data[8] AuthorizationData OPTIONAL 145 } 147 AP-REP ::= [APPLICATION 15] SEQUENCE { 148 pvno [0] INTEGER, -- represents Kerberos V5 149 msg-type [1] INTEGER, -- represents KRB_AP_REP 150 enc-part [2] EncryptedData 151 } 153 EncAPRepPart ::= [APPLICATION 27] SEQUENCE { 154 ctime [0] KerberosTime, 155 cusec [1] INTEGER, 156 subkey [2] EncryptionKey OPTIONAL, 157 seq-number [3] INTEGER OPTIONAL 159 } 161 Here is the syntax of the KRB-ERROR message: 163 KRB-ERROR ::= [APPLICATION 30] SEQUENCE { 164 pvno[0] INTEGER, 165 msg-type[1] INTEGER, 166 ctime[2] KerberosTime OPTIONAL, 167 cusec[3] INTEGER OPTIONAL, 168 stime[4] KerberosTime, 169 susec[5] INTEGER, 170 error-code[6] INTEGER, 171 crealm[7] Realm OPTIONAL, 172 cname[8] PrincipalName OPTIONAL, 173 realm[9] Realm, -- Correct realm 174 sname[10] PrincipalName, -- Correct name 175 e-text[11] GeneralString OPTIONAL, 176 e-data[12] OCTET STRING OPTIONAL 177 } 179 The KRB-PRIV message is used to send the request and reply data: 181 KRB-PRIV ::= [APPLICATION 21] SEQUENCE { 182 pvno[0] INTEGER, 183 msg-type[1] INTEGER, 184 enc-part[3] EncryptedData 185 } 187 EncKrbPrivPart ::= [APPLICATION 28] SEQUENCE { 188 user-data[0] OCTET STRING, 189 timestamp[1] KerberosTime OPTIONAL, 190 usec[2] INTEGER OPTIONAL, 191 seq-number[3] INTEGER OPTIONAL, 192 s-address[4] HostAddress, 193 -- sender's addr 194 r-address[5] HostAddress OPTIONAL 195 -- recip's addr 196 } 198 4. The Protocol 200 The service SHOULD accept requests on UDP port 464 and TCP port 464 201 as well. Use of other ports can significantly increase the complexity 202 and size of IPSEC policy rulesets in organizations that have IPSEC 203 capable nodes. 205 The protocol consists of a single request message followed by a 206 single reply message. For UDP transport, each message must be fully 207 contained in a single UDP packet. 209 For TCP transport, there is a 4 octet header in network byte order 210 that precedes the message and specifies the length of the message. 211 This requirement is consistent with the TCP transport header in 212 1510bis. 214 Request Message 216 0 1 2 3 217 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 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | message length | protocol version number | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | AP-REQ length | AP-REQ data / 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 / KRB-PRIV message / 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 All 16 bit fields are in network byte order. 228 message length field: contains the number of bytes in the message 229 including this field. 231 protocol version number: contains the hex constant 0x0002 (network 232 byte order). 234 AP-REQ length: length of AP-REQ data, in bytes. If the length is 235 zero, then the last field contains a KRB-ERROR message instead of a 236 KRB-PRIV message. 238 AP-REQ data: (see [3]) For a change password/key request, the AP-REQ 239 message service ticket sname, srealm principal identifier is 240 kadmin/changepw@REALM where REALM is the realm of the change password 241 service. The same applies to a set password/key request except the 242 principal identifier is kadmin/setpw@REALM. The authenticator in the 243 AP-REQ MUST contain a subsession key (which will be used to encrypt 244 the KRB-PRIV user data field - see below). The KDC may have stronger 245 pseudorandom generating capability then the clients; thus, the client 246 SHOULD use the session key as an input (along with additional locally 247 pseudorandom generated bits) into the generation of the subsession 248 key. To enable setting of passwords/keys, it is not required that the 249 initial flag be set in the Kerberos service ticket. The initial flag 250 is required for change requests, but not for set requests. We have 251 the following definitions: 253 old passwd initial flag target principal can be 254 in request? required? distinct from 255 authenticating principal? 257 change password: yes yes no 259 set password: no policy (*) yes 261 set key: no policy (*) yes 263 change key: no yes no 264 policy (*): implementations SHOULD allow administrators to set the 265 initial flag required for set requests policy to either yes or no. 266 Clients MUST be able to retry set requests that fail due to error 7 267 (initial flag required) with an initial ticket. Clients SHOULD NOT 268 cache service tickets targetted at kadmin/changepw. 270 KRB-PRIV message (see [3]) This KRB-PRIV message must be encrypted 271 using the subsession key from the authenticator in the AP-REQ. The 272 authenticator MUST contain a subsession key. The timestamp and usec 273 fields of the KRB-PRIV message MUST be present, and the data values 274 MUST be copies of the same data values from the authenticator. The 275 recipient should ignore the sender address field in the KRB-PRIV 276 message. 278 The user-data component of the message contains the DER encoding of 279 the ChangePasswdData ASN.1 type described below: 281 ChangePasswdData ::= SEQUENCE { 282 passwds [0] PasswordSequence OPTIONAL, 283 keys [1] KeySequences OPTIONAL, 284 -- exactly one of the above two will be 285 -- present, else KRB5_KPASSWD_MALFORMED 286 -- error will be returned by the server. 287 targname[2] PrincipalName OPTIONAL, 288 -- only present in set password/key: the 289 -- principal which will have its password 290 -- or keys set. Not present in a set request 291 -- if the client principal from the ticket is 292 -- the principal having its passwords or keys 293 -- set. 294 targrealm[3] Realm OPTIONAL, 295 -- only present in set password/key: the realm 296 -- for the principal which will have its 297 -- password or keys set. Not present in a set 298 -- request if the client principal from the 299 -- ticket is the principal having its 300 -- passwords or keys set. 301 flags[4] RequestFlags OPTIONAL 302 -- 32 bit string 303 } 305 KeySequences ::= SEQUENCE (SIZE (1..MAX)) OF KeySequence 307 KeySequence ::= SEQUENCE { 308 key[0] EncryptionKey, 309 salt[1] OCTET STRING OPTIONAL, 310 -- depends on enc type, not currently used 311 salt-type[2] INTEGER OPTIONAL 312 -- depends on enc type, not currently used 313 } 315 PasswordSequence ::= SEQUENCE { 316 newpasswd[0] OCTET STRING, 317 oldpasswd[1] OCTET STRING OPTIONAL 318 -- oldpasswd always present for change 319 -- password but not present for set 320 -- password, set key, or change key 321 -- NOTE: the passwords are UTF8 strings. 322 } 324 RequestFlags ::= BIT STRING (SIZE (32..MAX)) 325 -- reserved(0) 326 -- request-srv-gen-keys(1) 327 -- only in change/set keys 328 -- if the client desires 329 -- server to contribute to 330 -- keys; 331 -- server will return keys 333 The server must verify the AP-REQ message, check whether the client 334 principal in the ticket is authorized to set/change the password/keys 335 (either for that principal, or for the principal in the targname 336 field if present), and decrypt the new password/keys. The server also 337 checks whether the initial flag is required for this request, 338 replying with status 0x0007 if it is not set and should be. An 339 authorization failure is cause to respond with status 0x0005. For 340 forward compatibility, the server should be prepared to ignore fields 341 after targrealm in the structure that it does not understand. 343 If the passwds field is present, it contains the new cleartext 344 password (with the old cleartext password for a change password 345 operation). Otherwise the keys field is present, and it contains a 346 sequence of encryption keys. 348 In the cleartext password case, if the old password is sent in the 349 request, the request MUST be a change password request. If the old 350 password is not present in the request, the request MUST be a set 351 password request. The server should apply policy checks to the old 352 and new password after verifying that the old password is valid. The 353 server can check validity by obtaining a key from the old password 354 with a keytype that is present in the KDC database for the user and 355 comparing the keys for equality. The server then generates the 356 appropriate keytypes from the password and stores them in the KDC 357 database. If all goes well, status 0x0000 is returned to the client 358 in the reply message (see below). For a change password operation, 359 the initial flag in the service ticket MUST be set. 361 In the key sequence case, the sequence of keys is sent to the change 362 or set password service (kadmin/changepw or kadmin/setpw 363 respectively). For a principal that can act as a server, its 364 preferred keytype should be sent as the first key in the sequence, 365 but the KDC is not required to honor this preference. Application 366 servers SHOULD use the key sequence option for changing/setting their 367 keys. The change/set password services should check that all keys are 368 in the proper format, returning the KRB5_KPASSWD_MALFORMED error 369 otherwise. 371 For change/set key, the request message may include the request flags 372 bit string with the request-srv-gen-keys bit set. In this case, the 373 client is requesting that the server add entropy to its keys in the 374 KeySequences field. When using this option, the client SHOULD attempt 375 to generate pseudorandom keys with as much entropy as possible in its 376 request. The server will return the final key sequence in a 377 KeySequences structure in the edata of the reply message. The server 378 does not store any of the new keys at this point. The client MUST 379 make a subsequent change/set key request without the request-srv- 380 gen-keys bit; if the server returns KRB5_KPASSWD_SUCCESS for this 381 second request, then the new keys have been written into the 382 database. A conformant server MUST support this option. 384 Reply Message 386 0 1 2 3 387 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 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | message length | protocol version number | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | AP-REP length | AP-REP data / 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 / KRB-PRIV message / 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 All 16 bit fields are in network byte order. 398 message length field: contains the number of bytes in the message 399 including this field. 401 protocol version number: contains the hex constant 0x0002 (network 402 byte order). (The reply message has the same format as in the 403 original Kerberos change password protocol). 405 AP-REP length: length of AP-REP data, in bytes. If the length is 406 zero, then the last field contains a KRB-ERROR message instead of a 407 KRB-PRIV message. An implementation should check this field to 408 determine whether a KRB-ERROR message or KRB-PRIV message has been 409 returned. 411 AP-REP data: the AP-REP is the response to the AP-REQ in the request 412 packet. The subkey MUST be present in the AP-REP message. 414 KRB-PRIV message: This KRB-PRIV message must be encrypted using the 415 subkey from the AP-REP message. The client should ignore the sender 416 address (the server's address) in the KRB-PRIV message. Reflection 417 attacks are prevented since the subkey is used to encrypt the user- 418 data field of the KRB-PRIV message. The timestamp and usec fields of 419 the KRB-PRIV message MUST be present, and the data values MUST be 420 copies of the same data values from the AP-REP message. 422 The server will respond with a KRB-PRIV message unless it cannot 423 validate the client AP-REQ or KRB-PRIV message, in which case it will 424 respond with a KRB-ERROR message. 426 The user-data component of the KRB-PRIV message, or e-data component 427 of the KRB-ERROR message, must consist of the following data. 429 0 1 2 3 430 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 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | result code | key version (only on success) | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | result string length | result string / 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | edata / 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 result code (16 bits) (result codes 0-4 are the same as in the 440 original Kerberos change password protocol): 442 The result code must have one of the following values (network 443 byte order): 445 KRB5_KPASSWD_SUCCESS 0 request succeeds (This 446 value is not allowed in a 447 KRB-ERROR message) 449 KRB5_KPASSWD_MALFORMED 1 request fails due to being 450 malformed 452 KRB5_KPASSWD_HARDERROR 2 request fails due to "hard" 453 error in processing the 454 request (for example, there 455 is a resource or other 456 problem causing the request 457 to fail) 459 KRB5_KPASSWD_AUTHERROR 3 request fails due to an 460 error in authentication 461 processing 463 KRB5_KPASSWD_SOFTERROR 4 request fails due to a soft 464 error in processing the 465 request 467 KRB5_KPASSWD_ACCESSDENIED 5 requestor not authorized 469 KRB5_KPASSWD_BAD_VERSION 6 protocol version unsupported 471 KRB5_KPASSWD_INITIALFLAG_NEEDED 7 initial flag required 472 KRB5_KPASSWD_POLICY_REJECT 8 new cleartext password fails 473 policy; the result string 474 should include a text 475 message to be presented to 476 the user. 478 KRB5_KPASSWD_WRONG_SRV 9 policy failure: the client 479 sent change/set key and 480 should have sent change/set 481 passwd, or vice-versa. 483 KRB5_KPASSWD_BAD_PRINCIPAL 10 target principal does not 484 exist (only in response to 485 a set password or set key 486 request). 488 KRB5_KPASSWD_ETYPE_NOSUPP 11 the request contains a key sequence 489 containing at least one etype that 490 is not supported by the KDC. The 491 response edata contains an ASN.1 492 DER encoded PKERB-ETYPE-INFO type 493 that specifies the etypes that the 494 KDC supports: 496 KERB-ETYPE-INFO-ENTRY :: = SEQUENCE 497 { 498 encryption-type[0] INTEGER, 499 salt[1] OCTET STRING 500 OPTIONAL -- not sent, client 501 -- may ignore if 502 -- sent 503 } 505 PKERB-ETYPE-INFO ::= SEQUENCE OF 506 KERB-ETYPE-INFO-ENTRY 508 The client should retry the request 509 using only etypes (keytypes) that 510 are contained within the 511 PKERB-ETYPE-INFO structure in the 512 previous response. 514 KRB5_KPASSWD_ETYPE_SRVGENKEYS 12 See the following paragraph. 516 The KRB5_KPASSWD_ETYPE_SRVGENKEYS result code is returned when 517 the request has the request-srv-gen-keys flag set and the 518 server is returning the KeySequences structure defined above in 519 the edata field of the reply. The server returns one key sequence 520 structure of the same keytype for each key sequence structure in 521 the client request, unless it does not support one of the 522 keytypes (or etypes). In that case, it returns error 523 KRB5_KPASSWD_ETYPE_NOSUPP as discussed above. The server MUST 524 add keylength number of bits of entropy to each key, where 525 keylength is the number of actual key bits in the key (minus 526 any parity or non-entropy contributing bits). The assumption 527 here is that the client may have added insufficient entropy 528 to the request keys. The server SHOULD use the client key from 529 each KeySequence structure as input into the final keyvalue for 530 the returned key. The client MUST make another request after 531 receiving a reply with this status, since no keys have been 532 written into the database. 534 0xFFFF is returned if the request fails for some other reason. 535 The client must interpret any non-zero result code as a failure. 537 key version (16 bits - optional): 538 Present if and only if the result 539 code is KRB5_KPASSWD_SUCCESS. This contains the key version of 540 the new key(s). 542 result string length (16 bits): 543 Gives the length of the following result string field, in bytes. 544 If the result string is not present, the length is zero. 546 result string (optional): 547 This field is a UTF-8 encoded string which can be displayed 548 to the user. Specific reasons for a password set/change policy 549 failure is one possible use for this string. 551 edata (optional): 552 Used to convey additional information as defined by the 553 result code. 555 5. Acknowledgements 557 The authors thank Ken Raeburn, Tom Yu, Martin Rex, Sam Hartman, Tony 558 Andrea, Nicolas Williams, and other participants from the IETF 559 Kerberos Working Group for their input to the document. 561 6. Security Considerations 563 Password policies should be enforced to make sure that users do not 564 pick passwords (for change password/key) that are vulnerable to brute 565 force password guessing attacks. 567 7. References 569 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 570 9, RFC 2026, October 1996. 572 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 573 Levels", BCP 14, RFC 2119, March 1997 575 [3] J. Kohl, C. Neuman. The Kerberos Network Authentication 576 Service (V5), Request for Comments 1510. 578 8. Expiration Date 580 This draft expires on December 31st, 2001. 582 9. Authors' Addresses 584 Jonathan Trostle 585 Cisco Systems 586 170 W. Tasman Dr. 587 San Jose, CA 95134 588 Email: jtrostle@cisco.com 590 Mike Swift 591 University of Washington 592 Seattle, WA 593 Email: mikesw@cs.washington.edu 595 John Brezak 596 Microsoft 597 1 Microsoft Way 598 Redmond, WA 98052 599 Email: jbrezak@microsoft.com 601 Bill Gossman 602 Cisco Systems 603 500 108th Ave. NE, Suite 500 604 Bellevue, WA 98004 605 Email: bgossman@cisco.com 607 10. Full Copyright Statement 609 Copyright (C) The Internet Society (2001). All Rights Reserved. 611 This document and translations of it may be copied and furnished to 612 others, and derivative works that comment on or otherwise explain it 613 or assist in its implmentation may be prepared, copied, published and 614 distributed, in whole or in part, without restriction of any kind, 615 provided that the above copyright notice and this paragraph are 616 included on all such copies and derivative works. However, this 617 document itself may not be modified in any way, such as by removing 618 the copyright notice or references to the Internet Society or other 619 Internet organizations, except as needed for the purpose of 620 developing Internet standards in which case the procedures for 621 copyrights defined in the Internet Standards process must be 622 followed, or as required to translate it into languages other than 623 English. 625 The limited permissions granted above are perpetual and will not be 626 revoked by the Internet Society or its successors or assigns. 628 This document and the information contained herein is provided on an 629 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 630 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 631 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 632 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 633 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."