1 2CAT Working Group Mike Swift 3draft-trostle-win2k-cat-kerberos-set-passwd-00.txt Microsoft 4February 2000 Jonathan Trostle 5Category: Informational Cisco Systems 6 John Brezak 7 Microsoft 8 9 Extending Change Password for Setting Kerberos Passwords 10 11 120. Status Of This Memo 13 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 16 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. 21 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." 27 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 30 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 33 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 38 391. Abstract 40 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. 49 502. The Protocol 51 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. 56 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 60 requirement is consistent with the TCP transport header in 1510bis. 61 62Request Message 63 64 0 1 2 3 65 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 66 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 67 | message length | protocol version number | 68 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 69 | AP_REQ length | AP_REQ data / 70 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 71 / KRB-PRIV message / 72 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 73 74 All 16 bit fields are in big-endian order. 75 76 message length field: contains the number of bytes in the message 77 including this field. 78 79 protocol version number: contains the hex constant 0xff80 (big-endian 80 integer). 81 82 AP-REQ length: length of AP-REQ data, in bytes. If the length is zero, 83 then the last field contains a KRB-ERROR message instead of a KRB-PRIV 84 message. 85 86 AP-REQ data: (see [1]) The AP-REQ message must be for the service 87 principal kadmin/changepw@REALM, where REALM is the REALM of the user 88 who wishes to change/set his password. The ticket in the AP-REQ must 89 must include a subkey in the Authenticator. To enable setting of 90 passwords, it is not required that the initial flag be set in the 91 Kerberos service ticket. 92 93 KRB-PRIV message (see [1]) This KRB-PRIV message must be generated 94 using the subkey from the authenticator in the AP-REQ data. 95 96 The user-data component of the message consists of the following ASN.1 97 structure encoded as an OCTET STRING: 98 99 ChangePasswdData ::= SEQUENCE { 100 newpasswd[0] OCTET STRING, 101 targname[2] PrincipalName OPTIONAL, 102 targrealm[3] Realm OPTIONAL 103 } 104 105 The server must verify the AP-REQ message, check whether the client 106 principal in the ticket is authorized to set/change the password 107 (either for that principal, or for the principal in the targname 108 field if present), and decrypt the new password. The server also 109 checks whether the initial flag is required for this request, 110 replying with status 0x0007 if it is not set and should be. An 111 authorization failure is cause to respond with status 0x0005. For 112 forward compatibility, the server should be prepared to ignore fields 113 after targrealm in the structure that it does not understand. 114 115 The newpasswd field contains the cleartext password, and the server 116 should apply any local policy checks including password policy checks. 117 The server then generates the appropriate keytypes from the password 118 119 and stores them in the KDC database. If all goes well, status 0x0000 120 is returned to the client in the reply message (see below). 121 122Reply Message 123 124 0 1 2 3 125 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 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | message length | protocol version number | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | AP_REP length | AP-REP data / 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 / KRB-PRIV message / 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 134 135 All 16 bit fields are in big-endian order. 136 137 message length field: contains the number of bytes in the message 138 including this field. 139 140 protocol version number: contains the hex constant 0x0001 (big-endian 141 integer). (The reply message has the same format as in [2]). 142 143 AP-REP length: length of AP-REP data, in bytes. If the length is zero, 144 then the last field contains a KRB-ERROR message instead of a KRB-PRIV 145 message. 146 147 AP-REP data: the AP-REP is the response to the AP-REQ in the request 148 packet. 149 150 KRB-PRIV from [2]: This KRB-PRIV message must be generated using the 151 subkey in the authenticator in the AP-REQ data. 152 153 The server will respond with a KRB-PRIV message unless it cannot 154 decode the client AP-REQ or KRB-PRIV message, in which case it will 155 respond with a KRB-ERROR message. NOTE: Unlike change password version 156 1, the KRB-ERROR message will be sent back without any encapsulation. 157 158 The user-data component of the KRB-PRIV message, or e-data component 159 of the KRB-ERROR message, must consist of the following data. 160 161 0 1 2 3 162 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 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | result code | result string / 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 167 result code (16 bits) (result codes 0-4 are from [2]): 168 The result code must have one of the following values (big- 169 endian integer): 170 KRB5_KPASSWD_SUCCESS 0 request succeeds (This value is not 171 allowed in a KRB-ERROR message) 172 KRB5_KPASSWD_MALFORMED 1 request fails due to being malformed 173 KRB5_KPASSWD_HARDERROR 2 request fails due to "hard" error in 174 processing the request (for example, 175 there is a resource or other problem 176 causing the request to fail) 177 178 KRB5_KPASSWD_AUTHERROR 3 request fails due to an error in 179 authentication processing 180 KRB5_KPASSWD_SOFTERROR 4 request fails due to a "soft" error 181 in processing the request 182 KRB5_KPASSWD_ACCESSDENIED 5 requestor not authorized 183 KRB5_KPASSWD_BAD_VERSION 6 protocol version unsupported 184 KRB5_KPASSWD_INITIAL_FLAG_NEEDED 7 initial flag required 185 0xFFFF if the request fails for some other reason. 186 Although only a few non-zero result codes are specified here, 187 the client should accept any non-zero result code as indicating 188 failure. 189 result string - from [2]: 190 This field should contain information which the server thinks 191 might be useful to the user, such as feedback about policy 192 failures. The string must be encoded in UTF-8. It may be 193 omitted if the server does not wish to include it. If it is 194 present, the client should display the string to the user. 195 This field is analogous to the string which follows the numeric 196 code in SMTP, FTP, and similar protocols. 197 1983. References 199 200 [1] J. Kohl, C. Neuman. The Kerberos Network Authentication 201 Service (V5). Request for Comments 1510. 202 203 [2] M. Horowitz. Kerberos Change Password Protocol. 204 ftp://ds.internic.net/internet-drafts/ 205 draft-ietf-cat-kerb-chg-password-02.txt 206 2074. Expiration Date 208 209 This draft expires in August 2000. 210 2115. Authors' Addresses 212 213 Jonathan Trostle 214 Cisco Systems 215 170 W. Tasman Dr. 216 San Jose, CA 95134 217 Email: jtrostle@cisco.com 218 219 Mike Swift 220 1 Microsoft Way 221 Redmond, WA 98052 222 mikesw@microsoft.com 223 224 John Brezak 225 1 Microsoft Way 226 Redmond, WA 98052 227 jbrezak@microsoft.com 228