1
2
3
4
5
6
7Network Working Group                                   Jonathan Trostle
8INTERNET-DRAFT                                             Cisco Systems
9Category: Standards Track                                     Mike Swift
10                                                        University of WA
11                                                             John Brezak
12                                                               Microsoft
13                                                            Bill Gossman
14                                                           Cisco Systems
15
16
17                Kerberos Set/Change Password: Version 2
18              <draft-ietf-cat-kerberos-set-passwd-06.txt>
19
20
21
22
23Status of this Memo
24
25   This document is an Internet-Draft and is in full conformance with
26   all provisions of Section 10 of RFC2026 [6].
27
28   Internet-Drafts are working documents of the Internet Engineering
29   Task Force (IETF), its areas, and its working groups.  Note that
30   other groups may also distribute working documents as Internet-
31   Drafts.
32
33   Internet-Drafts are draft documents valid for a maximum of six months
34   and may be updated, replaced, or obsoleted by other documents at any
35   time.  It is inappropriate to use Internet- Drafts as reference
36   material or to cite them other than as "work in progress."
37
38   The list of current Internet-Drafts can be accessed at
39   http://www.ietf.org/ietf/1id-abstracts.txt
40
41   The list of Internet-Draft Shadow Directories can be accessed at
42   http://www.ietf.org/shadow.html.
43
44   This draft expires on December 31st, 2001. Please send comments to
45   the authors.
46
471. Abstract
48
49   This proposal specifies a Kerberos (RFC 1510 [3]) change/set password
50   protocol and a Kerberos change/set key protocol. The protocol
51   consists of a single request and reply message. The request message
52   includes both AP-REQ and KRB-PRIV submessages; the new password is
53   contained in the KRB-PRIV submessage which is encrypted in the
54   subsession key from the AP-REQ. The original Kerberos change password
55   protocol did not allow for an administrator to set a password for a
56   new user. This functionality is useful in some environments, and this
57   proposal allows password setting as well as password changing. The
58   protocol includes fields in the request message to indicate the
59   principal which is having its password set. We also extend the
60   set/change protocol to allow a client to send a sequence of keys to
61
62
63
64Trostle, Swift, Brezak, Gossman                                 [Page 1]
65
66INTERNET DRAFT                 June 2001           Expires December 2001
67
68
69   the KDC instead of a cleartext password. If in the cleartext password
70   case, the cleartext password fails to satisfy password policy, the
71   server should use the result code KRB5_KPASSWD_POLICY_REJECT.
72
732. Conventions used in this document
74
75   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
76   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
77   document are to be interpreted as described in RFC2119 [7].
78
793. Definitions from RFC 1510
80
81   We include some of the relevant ASN.1 definitions from RFC 1510 in
82   this section.
83
84      Realm ::=           GeneralString
85
86      PrincipalName ::=   SEQUENCE {
87                          name-type[0]     INTEGER,
88                          name-string[1]   SEQUENCE OF GeneralString
89      }
90
91      KerberosTime ::=    GeneralizedTime
92                          -- Specifying UTC time zone (Z)
93
94      HostAddress ::=     SEQUENCE  {
95                          addr-type[0]             INTEGER,
96                          address[1]               OCTET STRING
97      }
98
99      EncryptedData ::=   SEQUENCE {
100                        etype[0]     INTEGER, -- EncryptionType
101                        kvno[1]      INTEGER OPTIONAL,
102                        cipher[2]    OCTET STRING -- ciphertext
103      }
104
105      EncryptionKey ::=   SEQUENCE {
106                          keytype[0]    INTEGER,
107                          keyvalue[1]   OCTET STRING
108      }
109
110      Checksum ::=        SEQUENCE {
111                          cksumtype[0]   INTEGER,
112                          checksum[1]    OCTET STRING
113      }
114
115
116      AP-REQ ::= [APPLICATION 14] SEQUENCE {
117              pvno [0]         INTEGER,        -- indicates Version 5
118              msg-type [1]     INTEGER,        -- indicates KRB_AP_REQ
119              ap-options[2]    APOptions,
120              ticket[3]        Ticket,
121              authenticator[4] EncryptedData
122      }
123
124
125
126Trostle, Swift, Brezak, Gossman                                 [Page 2]
127
128INTERNET DRAFT                 June 2001           Expires December 2001
129
130
131      APOptions ::= BIT STRING {
132
133              reserved (0),
134              use-session-key (1),
135              mutual-required (2)
136      }
137
138      Ticket ::= [APPLICATION 1] SEQUENCE {
139              tkt-vno [0]     INTEGER,        -- indicates Version 5
140              realm [1]       Realm,
141              sname [2]       PrincipalName,
142              enc-part [3]    EncryptedData
143      }
144
145
146      -- Encrypted part of ticket
147      EncTicketPart ::= [APPLICATION 3] SEQUENCE {
148              flags[0]        TicketFlags,
149              key[1]          EncryptionKey,
150              crealm[2]       Realm,
151              cname[3]        PrincipalName,
152              transited[4]    TransitedEncoding,
153              authtime[5]     KerberosTime,
154              starttime[6]    KerberosTime OPTIONAL,
155              endtime[7]      KerberosTime,
156              renew-till[8]   KerberosTime OPTIONAL,
157              caddr[9]        HostAddresses OPTIONAL,
158              authorization-data[10]  AuthorizationData OPTIONAL
159      }
160
161      -- Unencrypted authenticator
162      Authenticator ::= [APPLICATION 2] SEQUENCE  {
163              authenticator-vno[0]    INTEGER,
164              crealm[1]               Realm,
165              cname[2]                PrincipalName,
166              cksum[3]                Checksum OPTIONAL,
167              cusec[4]                INTEGER,
168              ctime[5]                KerberosTime,
169              subkey[6]               EncryptionKey OPTIONAL,
170              seq-number[7]           INTEGER OPTIONAL,
171              authorization-data[8]   AuthorizationData OPTIONAL
172      }
173
174      AP-REP ::= [APPLICATION 15] SEQUENCE {
175              pvno [0]        INTEGER,        -- represents Kerberos V5
176              msg-type [1]    INTEGER,        -- represents KRB_AP_REP
177              enc-part [2]    EncryptedData
178      }
179
180      EncAPRepPart ::= [APPLICATION 27] SEQUENCE {
181              ctime [0]       KerberosTime,
182              cusec [1]       INTEGER,
183              subkey [2]      EncryptionKey OPTIONAL,
184              seq-number [3]  INTEGER OPTIONAL
185
186
187
188Trostle, Swift, Brezak, Gossman                                 [Page 3]
189
190INTERNET DRAFT                 June 2001           Expires December 2001
191
192
193      }
194
195   Here is the syntax of the KRB-ERROR message:
196
197      KRB-ERROR ::=   [APPLICATION 30] SEQUENCE {
198              pvno[0]         INTEGER,
199              msg-type[1]     INTEGER,
200              ctime[2]        KerberosTime OPTIONAL,
201              cusec[3]        INTEGER OPTIONAL,
202              stime[4]        KerberosTime,
203              susec[5]        INTEGER,
204              error-code[6]   INTEGER,
205              crealm[7]       Realm OPTIONAL,
206              cname[8]        PrincipalName OPTIONAL,
207              realm[9]        Realm, -- Correct realm
208              sname[10]       PrincipalName, -- Correct name
209              e-text[11]      GeneralString OPTIONAL,
210              e-data[12]      OCTET STRING OPTIONAL
211      }
212
213   The KRB-PRIV message is used to send the request and reply data:
214
215      KRB-PRIV ::=     [APPLICATION 21] SEQUENCE {
216                   pvno[0]                   INTEGER,
217                   msg-type[1]               INTEGER,
218                   enc-part[3]               EncryptedData
219      }
220
221      EncKrbPrivPart ::=   [APPLICATION 28] SEQUENCE {
222                   user-data[0]              OCTET STRING,
223                   timestamp[1]              KerberosTime OPTIONAL,
224                   usec[2]                   INTEGER OPTIONAL,
225                   seq-number[3]             INTEGER OPTIONAL,
226                   s-address[4]              HostAddress,
227                                                        -- sender's addr
228                   r-address[5]              HostAddress OPTIONAL
229                                                        -- recip's addr
230      }
231
232
2334. The Protocol
234
235   The service SHOULD accept requests on UDP port 464 and TCP port 464
236   as well. Use of other ports can significantly increase the complexity
237   and size of IPSEC policy rulesets in organizations that have IPSEC
238   capable nodes.
239
240   The protocol consists of a single request message followed by a
241   single reply message.  For UDP transport, each message must be fully
242   contained in a single UDP packet.
243
244   For TCP transport, there is a 4 octet header in network byte order
245   that precedes the message and specifies the length of the message.
246   This requirement is consistent with the TCP transport header in
247
248
249
250Trostle, Swift, Brezak, Gossman                                 [Page 4]
251
252INTERNET DRAFT                 June 2001           Expires December 2001
253
254
255   1510bis.
256
257
258
259   Request Message
260
261        0                   1                   2                   3
262        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
263       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
264       |         message length        |    protocol version number    |
265       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
266       |          AP-REQ length        |         AP-REQ data           /
267       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
268       /                        KRB-PRIV message                       /
269       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
270
271   All 16 bit fields are in network byte order.
272
273   message length field: contains the number of bytes in the message
274   including this field.
275
276   protocol version number: contains the hex constant 0x0002 (network
277   byte order).
278
279   AP-REQ length: length of AP-REQ data, in bytes. If the length is
280   zero, then the last field contains a KRB-ERROR message instead of a
281   KRB-PRIV message.
282
283   AP-REQ data: (see [3]) For a change password/key request, the AP-REQ
284   message service ticket sname, srealm principal identifier is
285   kadmin/changepw@REALM where REALM is the realm of the change password
286   service. The same applies to a set password/key request except the
287   principal identifier is kadmin/setpw@REALM. The authenticator in the
288   AP-REQ MUST contain a subsession key (which will be used to encrypt
289   the KRB-PRIV user data field - see below). The KDC may have stronger
290   pseudorandom generating capability then the clients; thus, the client
291   SHOULD use the session key as an input (along with additional locally
292   pseudorandom generated bits) into the generation of the subsession
293   key. To enable setting of passwords/keys, it is not required that the
294   initial flag be set in the Kerberos service ticket. The initial flag
295   is required for change requests, but not for set requests. We have
296   the following definitions:
297
298                   old passwd   initial flag  target principal can be
299                   in request?  required?     distinct from
300                                              authenticating principal?
301
302   change password:  yes         yes           no
303
304   set password:     no          policy (*)    yes
305
306   set key:          no          policy (*)    yes
307
308   change key:       no          yes           no
309
310
311
312Trostle, Swift, Brezak, Gossman                                 [Page 5]
313
314INTERNET DRAFT                 June 2001           Expires December 2001
315
316
317   policy (*): implementations SHOULD allow administrators to set the
318   initial flag required for set requests policy to either yes or no.
319   Clients MUST be able to retry set requests that fail due to error 7
320   (initial flag required) with an initial ticket. Clients SHOULD NOT
321   cache service tickets targetted at kadmin/changepw.
322
323   KRB-PRIV message (see [3]) This KRB-PRIV message must be encrypted
324   using the subsession key from the authenticator in the AP-REQ. The
325   authenticator MUST contain a subsession key. The timestamp and usec
326   fields of the KRB-PRIV message MUST be present, and the data values
327   MUST be copies of the same data values from the authenticator. The
328   recipient should ignore the sender address field in the KRB-PRIV
329   message.
330
331   The user-data component of the message contains the DER encoding of
332   the ChangePasswdData ASN.1 type described below:
333
334    ChangePasswdData ::=  SEQUENCE {
335                        passwds [0]          PasswordSequence OPTIONAL,
336                        keys [1]             KeySequences OPTIONAL,
337                          -- exactly one of the above two will be
338                          -- present, else KRB5_KPASSWD_MALFORMED
339                          -- error will be returned by the server.
340                        targname[2]          PrincipalName OPTIONAL,
341                          -- only present in set password/key: the
342                          -- principal which will have its password
343                          -- or keys set. Not present in a set request
344                          -- if the client principal from the ticket is
345                          -- the principal having its passwords or keys
346                          -- set.
347                        targrealm[3]         Realm OPTIONAL,
348                          -- only present in set password/key: the realm
349                          -- for the principal which will have its
350                          -- password or keys set. Not present in a set
351                          -- request if the client principal from the
352                          -- ticket is the principal having its
353                          -- passwords or keys set.
354                        flags[4]             RequestFlags OPTIONAL
355                          -- 32 bit string
356                        }
357
358    KeySequences ::= SEQUENCE (SIZE (1..MAX)) OF KeySequence
359
360    KeySequence ::= SEQUENCE {
361                     key[0]        EncryptionKey,
362                     salt[1]       OCTET STRING OPTIONAL,
363                           -- depends on enc type, not currently used
364                     salt-type[2]  INTEGER OPTIONAL
365                           -- depends on enc type, not currently used
366    }
367
368    PasswordSequence ::= SEQUENCE {
369                        newpasswd[0]  OCTET STRING,
370                        oldpasswd[1]  OCTET STRING OPTIONAL
371
372
373
374Trostle, Swift, Brezak, Gossman                                 [Page 6]
375
376INTERNET DRAFT                 June 2001           Expires December 2001
377
378
379                          -- oldpasswd always present for change
380                          -- password but not present for set
381                          -- password, set key, or change key
382                          -- NOTE: the passwords are UTF8 strings.
383    }
384
385    RequestFlags ::= BIT STRING (SIZE (32..MAX))
386                      -- reserved(0)
387                      -- request-srv-gen-keys(1)
388                           -- only in change/set keys
389                           -- if the client desires
390                           -- server to contribute to
391                           -- keys;
392                           -- server will return keys
393
394
395   The server must verify the AP-REQ message, check whether the client
396   principal in the ticket is authorized to set/change the password/keys
397   (either for that principal, or for the principal in the targname
398   field if present), and decrypt the new password/keys. The server also
399   checks whether the initial flag is required for this request,
400   replying with status 0x0007 if it is not set and should be. An
401   authorization failure is cause to respond with status 0x0005. For
402   forward compatibility, the server should be prepared to ignore fields
403   after targrealm in the structure that it does not understand.
404
405   If the passwds field is present, it contains the new cleartext
406   password (with the old cleartext password for a change password
407   operation). Otherwise the keys field is present, and it contains a
408   sequence of encryption keys.
409
410   In the cleartext password case, if the old password is sent in the
411   request, the request MUST be a change password request. If the old
412   password is not present in the request, the request MUST be a set
413   password request. The server should apply policy checks to the old
414   and new password after verifying that the old password is valid. The
415   server can check validity by obtaining a key from the old password
416   with a keytype that is present in the KDC database for the user and
417   comparing the keys for equality. The server then generates the
418   appropriate keytypes from the password and stores them in the KDC
419   database. If all goes well, status 0x0000 is returned to the client
420   in the reply message (see below). For a change password operation,
421   the initial flag in the service ticket MUST be set.
422
423   In the key sequence case, the sequence of keys is sent to the change
424   or set password service (kadmin/changepw or kadmin/setpw
425   respectively). For a principal that can act as a server, its
426   preferred keytype should be sent as the first key in the sequence,
427   but the KDC is not required to honor this preference. Application
428   servers SHOULD use the key sequence option for changing/setting their
429   keys. The change/set password services should check that all keys are
430   in the proper format, returning the KRB5_KPASSWD_MALFORMED error
431   otherwise.
432
433
434
435
436Trostle, Swift, Brezak, Gossman                                 [Page 7]
437
438INTERNET DRAFT                 June 2001           Expires December 2001
439
440
441   For change/set key, the request message may include the request flags
442   bit string with the request-srv-gen-keys bit set. In this case, the
443   client is requesting that the server add entropy to its keys in the
444   KeySequences field. When using this option, the client SHOULD attempt
445   to generate pseudorandom keys with as much entropy as possible in its
446   request. The server will return the final key sequence in a
447   KeySequences structure in the edata of the reply message. The server
448   does not store any of the new keys at this point. The client MUST
449   make a subsequent change/set key request without the request-srv-
450   gen-keys bit; if the server returns KRB5_KPASSWD_SUCCESS for this
451   second request, then the new keys have been written into the
452   database. A conformant server MUST support this option.
453
454
455
456
457
458
459
460   Reply Message
461
462        0                   1                   2                   3
463        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
464       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
465       |         message length        |    protocol version number    |
466       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
467       |          AP-REP length        |         AP-REP data           /
468       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
469       /                          KRB-PRIV message                     /
470       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
471
472   All 16 bit fields are in network byte order.
473
474   message length field: contains the number of bytes in the message
475   including this field.
476
477   protocol version number: contains the hex constant 0x0002 (network
478   byte order). (The reply message has the same format as in the
479   original Kerberos change password protocol).
480
481   AP-REP length: length of AP-REP data, in bytes. If the length is
482   zero, then the last field contains a KRB-ERROR message instead of a
483   KRB-PRIV message. An implementation should check this field to
484   determine whether a KRB-ERROR message or KRB-PRIV message has been
485   returned.
486
487   AP-REP data: the AP-REP is the response to the AP-REQ in the request
488   packet. The subkey MUST be present in the AP-REP message.
489
490   KRB-PRIV message: This KRB-PRIV message must be encrypted using the
491   subkey from the AP-REP message. The client should ignore the sender
492   address (the server's address) in the KRB-PRIV message. Reflection
493   attacks are prevented since the subkey is used to encrypt the user-
494   data field of the KRB-PRIV message. The timestamp and usec fields of
495
496
497
498Trostle, Swift, Brezak, Gossman                                 [Page 8]
499
500INTERNET DRAFT                 June 2001           Expires December 2001
501
502
503   the KRB-PRIV message MUST be present, and the data values MUST be
504   copies of the same data values from the AP-REP message.
505
506   The server will respond with a KRB-PRIV message unless it cannot
507   validate the client AP-REQ or KRB-PRIV message, in which case it will
508   respond with a KRB-ERROR message.
509
510   The user-data component of the KRB-PRIV message, or e-data component
511   of the KRB-ERROR message, must consist of the following data.
512
513        0                   1                   2                   3
514        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
515       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
516       |          result code          | key version (only on success) |
517       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
518       |     result string length      |         result string         /
519       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
520       |                             edata                             /
521       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
522
523       result code (16 bits) (result codes 0-4 are the same as in the
524       original Kerberos change password protocol):
525
526       The result code must have one of the following values (network
527       byte order):
528
529       KRB5_KPASSWD_SUCCESS            0 request succeeds (This
530                                         value is not allowed in a
531                                         KRB-ERROR message)
532
533       KRB5_KPASSWD_MALFORMED          1 request fails due to being
534                                         malformed
535
536       KRB5_KPASSWD_HARDERROR          2 request fails due to "hard"
537                                         error in processing the
538                                         request (for example, there
539                                         is a resource or other
540                                         problem causing the request
541                                         to fail)
542
543       KRB5_KPASSWD_AUTHERROR          3 request fails due to an
544                                         error in authentication
545                                         processing
546
547       KRB5_KPASSWD_SOFTERROR          4 request fails due to a soft
548                                         error in processing the
549                                         request
550
551       KRB5_KPASSWD_ACCESSDENIED       5 requestor not authorized
552
553       KRB5_KPASSWD_BAD_VERSION        6 protocol version unsupported
554
555       KRB5_KPASSWD_INITIALFLAG_NEEDED 7 initial flag required
556
557
558
559
560Trostle, Swift, Brezak, Gossman                                 [Page 9]
561
562INTERNET DRAFT                 June 2001           Expires December 2001
563
564
565       KRB5_KPASSWD_POLICY_REJECT      8 new cleartext password fails
566                                         policy; the result string
567                                         should include a text
568                                         message to be presented to
569                                         the user.
570
571       KRB5_KPASSWD_WRONG_SRV          9 policy failure: the client
572                                         sent change/set key and
573                                         should have sent change/set
574                                         passwd, or vice-versa.
575
576       KRB5_KPASSWD_BAD_PRINCIPAL     10 target principal does not
577                                         exist (only in response to
578                                         a set password or set key
579                                         request).
580
581       KRB5_KPASSWD_ETYPE_NOSUPP 11 the request contains a key sequence
582                                    containing at least one etype that
583                                    is not supported by the KDC. The
584                                    response edata contains an ASN.1
585                                    DER encoded PKERB-ETYPE-INFO type
586                                    that specifies the etypes that the
587                                    KDC supports:
588
589                                    KERB-ETYPE-INFO-ENTRY :: = SEQUENCE
590                                    {
591                                         encryption-type[0]  INTEGER,
592                                         salt[1]        OCTET STRING
593                                           OPTIONAL -- not sent, client
594                                                    -- may ignore if
595                                                    -- sent
596                                    }
597
598                                    PKERB-ETYPE-INFO ::= SEQUENCE OF
599                                                  KERB-ETYPE-INFO-ENTRY
600
601                                    The client should retry the request
602                                    using only etypes (keytypes) that
603                                    are contained within the
604                                    PKERB-ETYPE-INFO structure in the
605                                    previous response.
606
607       KRB5_KPASSWD_ETYPE_SRVGENKEYS 12 See the following paragraph.
608
609
610       The KRB5_KPASSWD_ETYPE_SRVGENKEYS result code is returned when
611       the request has the request-srv-gen-keys flag set and the
612       server is returning the KeySequences structure defined above in
613       the edata field of the reply. The server returns one key sequence
614       structure of the same keytype for each key sequence structure in
615       the client request, unless it does not support one of the
616       keytypes (or etypes). In that case, it returns error
617       KRB5_KPASSWD_ETYPE_NOSUPP as discussed above. The server MUST
618       add keylength number of bits of entropy to each key, where
619
620
621
622Trostle, Swift, Brezak, Gossman                                [Page 10]
623
624INTERNET DRAFT                 June 2001           Expires December 2001
625
626
627       keylength is the number of actual key bits in the key (minus
628       any parity or non-entropy contributing bits). The assumption
629       here is that the client may have added insufficient entropy
630       to the request keys. The server SHOULD use the client key from
631       each KeySequence structure as input into the final keyvalue for
632       the returned key. The client MUST make another request after
633       receiving a reply with this status, since no keys have been
634       written into the database.
635
636       0xFFFF is returned if the request fails for some other reason.
637       The client must interpret any non-zero result code as a failure.
638
639       key version (16 bits - optional):
640       Present if and only if the result
641       code is KRB5_KPASSWD_SUCCESS. This contains the key version of
642       the new key(s).
643
644       result string length (16 bits):
645       Gives the length of the following result string field, in bytes.
646       If the result string is not present, the length is zero.
647
648       result string (optional):
649       This field is a UTF-8 encoded string which can be displayed
650       to the user. Specific reasons for a password set/change policy
651       failure is one possible use for this string.
652
653       edata (optional):
654       Used to convey additional information as defined by the
655       result code.
656
6575.  Acknowledgements
658
659   The authors thank Ken Raeburn, Tom Yu, Martin Rex, Sam Hartman, Tony
660   Andrea, Nicolas Williams, and other participants from the IETF
661   Kerberos Working Group for their input to the document.
662
6636.  Security Considerations
664
665   Password policies should be enforced to make sure that users do not
666   pick passwords (for change password/key) that are vulnerable to brute
667   force password guessing attacks.
668
6697.  References
670
671   [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
672       9, RFC 2026, October 1996.
673
674   [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
675       Levels", BCP 14, RFC 2119, March 1997
676
677   [3] J. Kohl, C. Neuman. The Kerberos Network Authentication
678       Service (V5), Request for Comments 1510.
679
680
681
682
683
684Trostle, Swift, Brezak, Gossman                                [Page 11]
685
686INTERNET DRAFT                 June 2001           Expires December 2001
687
688
6898. Expiration Date
690
691      This draft expires on December 31st, 2001.
692
6939. Authors' Addresses
694
695      Jonathan Trostle
696      Cisco Systems
697      170 W. Tasman Dr.
698      San Jose, CA 95134
699      Email: jtrostle@cisco.com
700
701      Mike Swift
702      University of Washington
703      Seattle, WA
704      Email: mikesw@cs.washington.edu
705
706      John Brezak
707      Microsoft
708      1 Microsoft Way
709      Redmond, WA 98052
710      Email: jbrezak@microsoft.com
711
712      Bill Gossman
713      Cisco Systems
714      500 108th Ave. NE, Suite 500
715      Bellevue, WA 98004
716      Email: bgossman@cisco.com
717
71810. Full Copyright Statement
719
720   Copyright (C) The Internet Society (2001).  All Rights Reserved.
721
722   This document and translations of it may be copied and furnished to
723   others, and derivative works that comment on or otherwise explain it
724   or assist in its implmentation may be prepared, copied, published and
725   distributed, in whole or in part, without restriction of any kind,
726   provided that the above copyright notice and this paragraph are
727   included on all such copies and derivative works.  However, this
728   document itself may not be modified in any way, such as by removing
729   the copyright notice or references to the Internet Society or other
730   Internet organizations, except as needed for the purpose of
731   developing Internet standards in which case the procedures for
732   copyrights defined in the Internet Standards process must be
733   followed, or as required to translate it into languages other than
734   English.
735
736   The limited permissions granted above are perpetual and will not be
737   revoked by the Internet Society or its successors or assigns.
738
739   This document and the information contained herein is provided on an
740   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
741   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
742   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
743
744
745
746Trostle, Swift, Brezak, Gossman                                [Page 12]
747
748INTERNET DRAFT                 June 2001           Expires December 2001
749
750
751   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
752   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808Trostle, Swift, Brezak, Gossman                                [Page 13]
809
810