idnits 2.17.1 draft-ietf-cat-kerberos-set-passwd-02.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 2 longer pages, the longest (page 3) being 61 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 19 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 103 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 278 looks like a reference -- Missing reference section? '3' on line 284 looks like a reference -- Missing reference section? '4' on line 287 looks like a reference -- Missing reference section? '2' on line 281 looks like a reference -- Missing reference section? '0' on line 258 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-02.txt Microsoft 3 March 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]) The AP-REQ message must be for the service 96 principal kadmin/changepw@REALM, where REALM is the REALM of the user 97 who wishes to change/set his password. The ticket in the AP-REQ must 98 must include a subkey in the Authenticator. To enable setting of 99 passwords/keys, it is not required that the initial flag be set in the 100 Kerberos service ticket. The initial flag is required for change requests, 101 but not for set password requests. We have the following definitions: 103 old passwd initial flag target principal can be 104 in request? required? distinct from 105 authenticating principal? 107 change password: yes yes no 109 set password: no no yes 111 set key: no policy yes 112 determined 113 KRB-PRIV message (see [3]) This KRB-PRIV message must be generated 114 using the subkey from the authenticator in the AP-REQ data. 116 The user-data component of the message consists of the following ASN.1 117 structure encoded as an OCTET STRING: 119 ChangePasswdData :: = SEQUENCE { 120 newpasswdorkeys[0] NewPasswdOrKeys, 121 targname[1] PrincipalName OPTIONAL, 122 -- only present in set password: the principal 123 -- which will have its password set 124 targrealm[2] Realm OPTIONAL, 125 -- only present in set password: the realm for 126 -- the principal which will have its password set 128 } 130 NewPasswdOrKeys :: = CHOICE { 131 passwords[0] PasswordSequence, 132 keyseq[1] KeySequences 133 } 135 KeySequences :: = SEQUENCE OF KeySequence 137 KeySequence :: = SEQUENCE { 138 key[0] EncryptionKey, 139 salt[1] OCTET STRING OPTIONAL, 140 salt-type[2] INTEGER OPTIONAL 141 } 143 PasswordSequence :: = SEQUENCE { 144 newpasswd[0] OCTET STRING, 145 oldpasswd[1] OCTET STRING OPTIONAL 146 -- oldpasswd always present for change password 147 -- but not present for set password 148 } 150 The server must verify the AP-REQ message, check whether the client 151 principal in the ticket is authorized to set or change the password 152 (either for that principal, or for the principal in the targname 153 field if present), and decrypt the new password/keys. The server 154 also checks whether the initial flag is required for this request, 155 replying with status 0x0007 if it is not set and should be. An 156 authorization failure is cause to respond with status 0x0005. For 157 forward compatibility, the server should be prepared to ignore fields 158 after targrealm in the structure that it does not understand. 160 The newpasswdorkeys field contains either the new cleartext password 161 (with the old cleartext password for a change password operation), 162 or a sequence of encryption keys with their respective salts. 164 In the cleartext password case, if the old password is sent in the 165 request, the request is defined to be a change password request. If 166 the old password is not present in the request, the request is a set 167 password request. The server should apply policy checks to the old 168 and new password after verifying that the old password is valid. 169 The server can check validity by obtaining a key from the old 170 password with a keytype that is present in the KDC database for the 171 user and comparing the keys for equality. The server then generates 172 the appropriate keytypes from the password and stores them in the KDC 173 database. If all goes well, status 0x0000 is returned to the client 174 in the reply message (see below). For a change password operation, 175 the initial flag in the service ticket MUST be set. 177 In the key sequence case, the sequence of keys is sent to the set 178 password service. For a principal that can act as a server, its 179 preferred keytype should be sent as the first key in the sequence, 180 but the KDC is not required to honor this preference. Application 181 servers should use the key sequence option for changing/setting their 182 keys. The set password service should check that all keys are in the 183 proper format, returning the KRB5_KPASSWD_MALFORMED error otherwise. 185 Reply Message 187 0 1 2 3 188 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 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | message length | protocol version number | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | AP_REP length | AP-REP data / 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 / KRB-PRIV message / 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 All 16 bit fields are in network byte order. 199 message length field: contains the number of bytes in the message 200 including this field. 202 protocol version number: contains the hex constant 0x0002 (network 203 byte order). (The reply message has the same format as in [4]). 205 AP-REP length: length of AP-REP data, in bytes. If the length is zero, 206 then the last field contains a KRB-ERROR message instead of a KRB-PRIV 207 message. 209 AP-REP data: the AP-REP is the response to the AP-REQ in the request 210 packet. 212 KRB-PRIV from [4]: This KRB-PRIV message must be generated using the 213 subkey in the authenticator in the AP-REQ data. 215 The server will respond with a KRB-PRIV message unless it cannot 216 validate the client AP-REQ or KRB-PRIV message, in which case it will 217 respond with a KRB-ERROR message. NOTE: Unlike change password version 218 1, the KRB-ERROR message will be sent back without any encapsulation. 220 The user-data component of the KRB-PRIV message, or e-data component 221 of the KRB-ERROR message, must consist of the following data. 223 0 1 2 3 224 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 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | result code | result string / 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | edata / 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 result code (16 bits) (result codes 0-4 are from [4]): 231 The result code must have one of the following values (network 232 byte order): 233 KRB5_KPASSWD_SUCCESS 0 request succeeds (This value is not 234 allowed in a KRB-ERROR message) 235 KRB5_KPASSWD_MALFORMED 1 request fails due to being malformed 236 KRB5_KPASSWD_HARDERROR 2 request fails due to "hard" error in 237 processing the request (for example, 238 there is a resource or other problem 239 causing the request to fail) 240 KRB5_KPASSWD_AUTHERROR 3 request fails due to an error in 241 authentication processing 242 KRB5_KPASSWD_SOFTERROR 4 request fails due to a soft error 243 in processing the request 244 KRB5_KPASSWD_ACCESSDENIED 5 requestor not authorized 245 KRB5_KPASSWD_BAD_VERSION 6 protocol version unsupported 246 KRB5_KPASSWD_INITIAL_FLAG_NEEDED 7 initial flag required 247 KRB5_KPASSWD_POLICY_REJECT 8 new cleartext password fails policy; 248 the result string should include a text message to be presented 249 to the user. 250 KRB5_KPASSWD_BAD_PRINCIPAL 9 target principal does not exist 251 (only in response to a set password request). 252 KRB5_KPASSWD_ETYPE_NOSUPP 10 the request contains a key sequence 253 containing at least one etype that is not supported by the KDC. 254 The response edata contains an ASN.1 encoded PKERB-ETYPE-INFO 255 type that specifies the etypes that the KDC supports: 257 KERB-ETYPE-INFO-ENTRY :: = SEQUENCE { 258 encryption-type[0] INTEGER, 259 salt[1] OCTET STRING OPTIONAL -- not sent 260 } 262 PKERB-ETYPE-INFO ::= SEQUENCE OF KERB-ETYPE-INFO-ENTRY 264 The client should retry the request using only etypes (keytypes) 265 that are contained within the PKERB-ETYPE-INFO structure in the 266 previous response. 267 0xFFFF if the request fails for some other reason. 268 The client must interpret any non-zero result code as a failure. 269 result string - from [4]: 270 This field is a UTF-8 encoded string which should be displayed 271 to the user by the client. Specific reasons for a password 272 set/change policy failure is one use for this string. 273 edata: used to convey additional information as defined by the 274 result code. 276 4. References 278 [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 279 9, RFC 2026, October 1996. 281 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 282 Levels", BCP 14, RFC 2119, March 1997 284 [3] J. Kohl, C. Neuman. The Kerberos Network Authentication 285 Service (V5), Request for Comments 1510. 287 [4] M. Horowitz. Kerberos Change Password Protocol, 288 ftp://ds.internic.net/internet-drafts/ 289 draft-ietf-cat-kerb-chg-password-02.txt 291 5. Expiration Date 293 This draft expires in September 2000. 295 6. Authors' Addresses 297 Jonathan Trostle 298 Cisco Systems 299 170 W. Tasman Dr. 300 San Jose, CA 95134 301 Email: jtrostle@cisco.com 303 Mike Swift 304 1 Microsoft Way 305 Redmond, WA 98052 306 Email: mikesw@microsoft.com 308 John Brezak 309 1 Microsoft Way 310 Redmond, WA 98052 311 Email: jbrezak@microsoft.com 313 Bill Gossman 314 Cybersafe Corporation 315 1605 NW Sammamish Rd. 316 Issaquah, WA 98027-5378 317 Email: bill.gossman@cybersafe.com