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