1 2 3 4 5Network Working Group M. Horowitz 6<draft-ietf-cat-kerb-chg-password-02.txt> Stonecast, Inc. 7Internet-Draft August, 1998 8 9 Kerberos Change Password Protocol 10 11Status of this Memo 12 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 17 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as ``work in progress.'' 22 23 To learn the current status of any Internet-Draft, please check the 24 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 25 Directories on ftp.ietf.org (US East Coast), nic.nordu.net 26 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 27 Rim). 28 29 Distribution of this memo is unlimited. Please send comments to the 30 <cat-ietf@mit.edu> mailing list. 31 32Abstract 33 34 The Kerberos V5 protocol [RFC1510] does not describe any mechanism 35 for users to change their own passwords. In order to promote 36 interoperability between workstations, personal computers, terminal 37 servers, routers, and KDC's from multiple vendors, a common password 38 changing protocol is required. 39 40 41 42Overview 43 44 When a user wishes to change his own password, or is required to by 45 local policy, a simple request of a password changing service is 46 necessary. This service must be implemented on at least one host for 47 each Kerberos realm, probably on one of the kdc's for that realm. 48 The service must accept requests on UDP port 464 (kpasswd), and may 49 accept requests on TCP port 464 as well. 50 51 The protocol itself consists of a single request message followed by 52 a single reply message. For UDP transport, each message must be 53 fully contained in a single UDP packet. 54 55 56 57 58 59 60 61 62Horowitz [Page 1] 63 64Internet Draft Kerberos Change Password Protocol August, 1998 65 66 67Request Message 68 69 0 1 2 3 70 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 71 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 72 | message length | protocol version number | 73 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 74 | AP_REQ length | AP-REQ data / 75 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 76 / KRB-PRIV message / 77 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 78 79 message length (16 bits) 80 Contains the length of the message, including this field, in bytes 81 (big-endian integer) 82 protocol version number (16 bits) 83 Contains the hex constant 0x0001 (big-endian integer) 84 AP-REQ length (16 bits) 85 length (big-endian integer) of AP-REQ data, in bytes. 86 AP-REQ data, as described in RFC1510 (variable length) 87 This AP-REQ must be for the service principal 88 kadmin/changepw@REALM, where REALM is the REALM of the user who 89 wishes to change his password. The Ticket in the AP-REQ must be 90 derived from an AS request (thus having the INITIAL flag set), and 91 must include a subkey in the Authenticator. 92 KRB-PRIV message, as described in RFC1510 (variable length) 93 This KRB-PRIV message must be generated using the subkey in the 94 Authenticator in the AP-REQ data. The user-data component of the 95 message must consist of the user's new password. 96 97 The server must verify the AP-REQ message, decrypt the new password, 98 perform any local policy checks (such as password quality, history, 99 authorization, etc.) required, then set the password to the new value 100 specified. 101 102 The principal whose password is to be changed is the principal which 103 authenticated to the password changing service. This protocol does 104 not address administrators who want to change passwords of principal 105 besides their own. 106 107 108Reply Message 109 110 0 1 2 3 111 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 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 | message length | protocol version number | 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | AP_REP length | AP-REP data / 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 / KRB-PRIV or KRB-ERROR message / 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 120 message length (16 bits) 121 122 123 124Horowitz [Page 2] 125 126Internet Draft Kerberos Change Password Protocol August, 1998 127 128 129 Contains the length of the message, including this field, in bytes 130 (big-endian integer), 131 protocol version number (16 bits) 132 Contains the hex constant 0x0001 (big-endian integer) 133 AP-REP length (16 bits) 134 length of AP-REP data, in bytes. If the the length is zero, then 135 the last field will contain a KRB-ERROR message instead of a KRB- 136 PRIV message. 137 AP-REP data, as described in RFC1510 (variable length) 138 The AP-REP corresponding to the AP-REQ in the request packet. 139 KRB-PRIV or KRB-ERROR message, as described in RFC1510 (variable 140 length) 141 If the AP-REP length is zero, then this field contains a KRB-ERROR 142 message. Otherwise, it contains a KRB-PRIV message. This KRB- 143 PRIV message must be generated using the subkey in the 144 Authenticator in the AP-REQ data. 145 146 The user-data component of the KRB-PRIV message, or e-data 147 component of the KRB-ERROR message, must consist of the following 148 data: 149 150 0 1 2 3 151 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 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | result code | result string / 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 156 result code (16 bits) 157 The result code must have one of the following values (big- 158 endian integer): 159 0x0000 if the request succeeds. (This value is not permitted 160 in a KRB-ERROR message.) 161 0x0001 if the request fails due to being malformed 162 0x0002 if the request fails due to a "hard" error processing 163 the request (for example, there is a resource or other 164 problem causing the request to fail) 165 0x0003 if the request fails due to an error in authentication 166 processing 167 0x0004 if the request fails due to a "soft" error processing 168 the request (for example, some policy or other similar 169 consideration is causing the request to be rejected). 170 0xFFFF if the request fails for some other reason. 171 Although only a few non-zero result codes are specified here, 172 the client should accept any non-zero result code as indicating 173 failure. 174 result string (variable length) 175 This field should contain information which the server thinks 176 might be useful to the user, such as feedback about policy 177 failures. The string must be encoded in UTF-8. It may be 178 omitted if the server does not wish to include it. If it is 179 present, the client should display the string to the user. 180 This field is analogous to the string which follows the numeric 181 code in SMTP, FTP, and similar protocols. 182 183 184 185 186Horowitz [Page 3] 187 188Internet Draft Kerberos Change Password Protocol August, 1998 189 190 191Dropped and Modified Messages 192 193 An attacker (or simply a lossy network) could cause either the 194 request or reply to be dropped, or modified by substituting a KRB- 195 ERROR message in the reply. 196 197 If a request is dropped, no modification of the password/key database 198 will take place. If a reply is dropped, the server will (assuming a 199 valid request) make the password change. However, the client cannot 200 distinguish between these two cases. 201 202 In this situation, the client should construct a new authenticator, 203 re-encrypt the request, and retransmit. If the original request was 204 lost, the server will treat this as a valid request, and the password 205 will be changed normally. If the reply was lost, then the server 206 should take care to notice that the request was a duplicate of the 207 prior request, because the "new" password is the current password, 208 and the password change time is within some implementation-defined 209 replay time window. The server should then return a success reply 210 (an AP-REP message with result code == 0x0000) without actually 211 changing the password or any other information (such as modification 212 timestamps). 213 214 If a success reply was replaced with an error reply, then the 215 application performing the request would return an error to the user. 216 In this state, the user's password has been changed, but the user 217 believes that it has not. If the user attempts to change the 218 password again, this will probably fail, because the user cannot 219 successfully provide the old password to get an INITIAL ticket to 220 make the request. This situation requires administrative 221 intervention as if a password was lost. This situation is, 222 unfortunately, impossible to prevent. 223 224 225Security Considerations 226 227 This document deals with changing passwords for Kerberos. Because 228 Kerberos is used for authentication and key distribution, it is 229 important that this protocol use the highest level of security 230 services available to a particular installation. Mutual 231 authentication is performed, so that the server knows the request is 232 valid, and the client knows that the request has been received and 233 processed by the server. 234 235 There are also security issues relating to dropped or modified 236 messages which are addressed explicitly. 237 238 239References 240 241 [RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network 242 Authentication Service (V5)", RFC 1510, September 1993. 243 244 245 246 247 248Horowitz [Page 4] 249 250Internet Draft Kerberos Change Password Protocol August, 1998 251 252 253Author's Address 254 255 Marc Horowitz 256 Stonecast, Inc. 257 108 Stow Road 258 Harvard, MA 01451 259 260 Phone: +1 978 456 9103 261 Email: marc@stonecast.net 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310Horowitz [Page 5] 311 312