doc/specifications/draft-ietf-cat-kerberos-set-passwd-05.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                   Jonathan Trostle
   8 INTERNET-DRAFT                                             Cisco Systems
   9 Category: 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-05.txt>
  19
  20
  21
  22
  23 Status 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 October 31st, 2001. Please send comments to the
  45    authors.
  46
  47 1. 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    session key from the ticket. 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
  64 Trostle, Swift, Brezak, Gossman                                 [Page 1]
  65 \f
  66 INTERNET DRAFT                 April 2001           Expires October 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
  73 2. 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
  79 3. 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
 126 Trostle, Swift, Brezak, Gossman                                 [Page 2]
 127 \f
 128 INTERNET DRAFT                 April 2001           Expires October 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
 188 Trostle, Swift, Brezak, Gossman                                 [Page 3]
 189 \f
 190 INTERNET DRAFT                 April 2001           Expires October 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
 233 4. 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
 250 Trostle, Swift, Brezak, Gossman                                 [Page 4]
 251 \f
 252 INTERNET DRAFT                 April 2001           Expires October 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. To enable setting of
 288    passwords/keys, it is not required that the initial flag be set in
 289    the Kerberos service ticket. The initial flag is required for change
 290    requests, but not for set requests. We have the following
 291    definitions:
 292
 293                    old passwd   initial flag  target principal can be
 294                    in request?  required?     distinct from
 295                                               authenticating principal?
 296
 297    change password:  yes         yes           no
 298
 299    set password:     no          policy (*)    yes
 300
 301    set key:          no          policy (*)    yes
 302
 303    change key:       no          yes           no
 304
 305    policy (*): implementations SHOULD allow administrators to set the
 306    initial flag required for set requests policy to either yes or no.
 307    Clients MUST be able to retry set requests that fail due to error 7
 308    (initial flag required) with an initial ticket. Clients SHOULD NOT
 309
 310
 311
 312 Trostle, Swift, Brezak, Gossman                                 [Page 5]
 313 \f
 314 INTERNET DRAFT                 April 2001           Expires October 2001
 315
 316
 317    cache service tickets targetted at kadmin/changepw.
 318
 319    KRB-PRIV message (see [3]) This KRB-PRIV message must be encrypted
 320    using the session key from the ticket in the AP-REQ.
 321
 322    The user-data component of the message consists of the following
 323    ASN.1 encoded structure:
 324
 325     ChangePasswdData :: =  SEQUENCE {
 326                         newpasswdorkeys[0]   NewPasswdOrKeys,
 327                         targname[1]          PrincipalName OPTIONAL,
 328                           -- only present in set password/key: the
 329                           -- principal which will have its password
 330                           -- or keys set. Not present in a set request
 331                           -- if the client principal from the ticket is
 332                           -- the principal having its passwords or keys
 333                           -- set.
 334                         targrealm[2]         Realm OPTIONAL,
 335                           -- only present in set password/key: the realm
 336                           -- for the principal which will have its
 337                           -- password or keys set. Not present in a set
 338                           -- request if the client principal from the
 339                           -- ticket is the principal having its
 340                           -- passwords or keys set.
 341                         flags[3]             RequestFlags OPTIONAL
 342                           -- 32 bit string
 343                         }
 344
 345     NewPasswdOrKeys :: = CHOICE {
 346                        passwords[0]  PasswordSequence, -- chg/set passwd
 347                        keyseq[1]     KeySequences      -- chg/set key
 348     }
 349
 350     KeySequences :: = SEQUENCE OF KeySequence
 351
 352     KeySequence :: = SEQUENCE {
 353                      key[0]        EncryptionKey,
 354                      salt[1]       OCTET STRING OPTIONAL,
 355                      salt-type[2]  INTEGER OPTIONAL
 356     }
 357
 358     PasswordSequence :: = SEQUENCE {
 359                         newpasswd[0]  OCTET STRING,
 360                         oldpasswd[1]  OCTET STRING OPTIONAL
 361                           -- oldpasswd always present for change
 362                           -- password but not present for set
 363                           -- password, set key, or change key
 364     }
 365
 366     RequestFlags :: = BIT STRING {
 367                       reserved(0),
 368                       request-srv-gen-keys(1)
 369                            -- only in change/set keys
 370                            -- if the client desires
 371
 372
 373
 374 Trostle, Swift, Brezak, Gossman                                 [Page 6]
 375 \f
 376 INTERNET DRAFT                 April 2001           Expires October 2001
 377
 378
 379                            -- server to contribute to
 380                            -- keys;
 381                            -- server will return keys
 382     }
 383
 384    The server must verify the AP-REQ message, check whether the client
 385    principal in the ticket is authorized to set/change the password/keys
 386    (either for that principal, or for the principal in the targname
 387    field if present), and decrypt the new password/keys. The server also
 388    checks whether the initial flag is required for this request,
 389    replying with status 0x0007 if it is not set and should be. An
 390    authorization failure is cause to respond with status 0x0005. For
 391    forward compatibility, the server should be prepared to ignore fields
 392    after targrealm in the structure that it does not understand.
 393
 394    The newpasswdorkeys field contains either the new cleartext password
 395    (with the old cleartext password for a change password operation), or
 396    a sequence of encryption keys with their respective salts.
 397
 398    In the cleartext password case, if the old password is sent in the
 399    request, the request MUST be a change password request. If the old
 400    password is not present in the request, the request MUST be a set
 401    password request. The server should apply policy checks to the old
 402    and new password after verifying that the old password is valid. The
 403    server can check validity by obtaining a key from the old password
 404    with a keytype that is present in the KDC database for the user and
 405    comparing the keys for equality. The server then generates the
 406    appropriate keytypes from the password and stores them in the KDC
 407    database. If all goes well, status 0x0000 is returned to the client
 408    in the reply message (see below). For a change password operation,
 409    the initial flag in the service ticket MUST be set.
 410
 411    In the key sequence case, the sequence of keys is sent to the change
 412    or set password service (kadmin/changepw or kadmin/setpw
 413    respectively). For a principal that can act as a server, its
 414    preferred keytype should be sent as the first key in the sequence,
 415    but the KDC is not required to honor this preference. Application
 416    servers should use the key sequence option for changing/setting their
 417    keys. The change/set password services should check that all keys are
 418    in the proper format, returning the KRB5_KPASSWD_MALFORMED error
 419    otherwise.
 420
 421    For change/set key, the request message may include the request flags
 422    bit string with the request-srv-gen-keys bit set. In this case, the
 423    client is requesting that the server add entropy to its keys in the
 424    KeySequences field. When using this option, the client SHOULD attempt
 425    to generate pseudorandom keys with as much entropy as possible in its
 426    request. The server will return the final key sequence in a
 427    KeySequences structure in the edata of the reply message. The server
 428    does not store any of the new keys at this point. The client MUST
 429    make a subsequent change/set key request without the request-srv-
 430    gen-keys bit; if the server returns KRB5_KPASSWD_SUCCESS for this
 431    second request, then the new keys have been written into the
 432    database. A conformant server MUST support this option.
 433
 434
 435
 436 Trostle, Swift, Brezak, Gossman                                 [Page 7]
 437 \f
 438 INTERNET DRAFT                 April 2001           Expires October 2001
 439
 440
 441    Reply Message
 442
 443         0                   1                   2                   3
 444         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
 445        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 446        |         message length        |    protocol version number    |
 447        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 448        |          AP_REP length        |         AP-REP data           /
 449        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 450        /                          KRB-PRIV message                     /
 451        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 452
 453    All 16 bit fields are in network byte order.
 454
 455    message length field: contains the number of bytes in the message
 456    including this field.
 457
 458    protocol version number: contains the hex constant 0x0002 (network
 459    byte order). (The reply message has the same format as in the
 460    original Kerberos change password protocol).
 461
 462    AP-REP length: length of AP-REP data, in bytes. If the length is
 463    zero, then the last field contains a KRB-ERROR message instead of a
 464    KRB-PRIV message. An implementation should check this field to
 465    determine whether a KRB-ERROR message or KRB-PRIV message has been
 466    returned.
 467
 468    AP-REP data: the AP-REP is the response to the AP-REQ in the request
 469    packet.
 470
 471    KRB-PRIV message: This KRB-PRIV message must be encrypted using the
 472    session key from the ticket in the AP-REQ.
 473
 474    The server will respond with a KRB-PRIV message unless it cannot
 475    validate the client AP-REQ or KRB-PRIV message, in which case it will
 476    respond with a KRB-ERROR message.
 477
 478    The user-data component of the KRB-PRIV message, or e-data component
 479    of the KRB-ERROR message, must consist of the following data.
 480
 481         0                   1                   2                   3
 482         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
 483        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 484        |          result code          | key version (only on success) |
 485        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 486        |     result string length      |         result string         /
 487        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 488        |                             edata                             /
 489        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 490
 491        result code (16 bits) (result codes 0-4 are the same as in the
 492        original Kerberos change password protocol):
 493
 494        The result code must have one of the following values (network
 495
 496
 497
 498 Trostle, Swift, Brezak, Gossman                                 [Page 8]
 499 \f
 500 INTERNET DRAFT                 April 2001           Expires October 2001
 501
 502
 503        byte order):
 504
 505        KRB5_KPASSWD_SUCCESS            0 request succeeds (This
 506                                          value is not allowed in a
 507                                          KRB-ERROR message)
 508
 509        KRB5_KPASSWD_MALFORMED          1 request fails due to being
 510                                          malformed
 511
 512        KRB5_KPASSWD_HARDERROR          2 request fails due to "hard"
 513                                          error in processing the
 514                                          request (for example, there
 515                                          is a resource or other
 516                                          problem causing the request
 517                                          to fail)
 518
 519        KRB5_KPASSWD_AUTHERROR          3 request fails due to an
 520                                          error in authentication
 521                                          processing
 522
 523        KRB5_KPASSWD_SOFTERROR          4 request fails due to a soft
 524                                          error in processing the
 525                                          request
 526
 527        KRB5_KPASSWD_ACCESSDENIED       5 requestor not authorized
 528
 529        KRB5_KPASSWD_BAD_VERSION        6 protocol version unsupported
 530
 531        KRB5_KPASSWD_INITIALFLAG_NEEDED 7 initial flag required
 532
 533        KRB5_KPASSWD_POLICY_REJECT      8 new cleartext password fails
 534                                          policy; the result string
 535                                          should include a text
 536                                          message to be presented to
 537                                          the user.
 538
 539        KRB5_KPASSWD_BAD_PRINCIPAL      9 target principal does not
 540                                          exist (only in response to
 541                                          a set password or set key
 542                                          request).
 543
 544        KRB5_KPASSWD_ETYPE_NOSUPP 10 the request contains a key sequence
 545                                     containing at least one etype that
 546                                     is not supported by the KDC. The
 547                                     response edata contains an ASN.1
 548                                     encoded PKERB-ETYPE-INFO type that
 549                                     specifies the etypes that the KDC
 550                                     supports:
 551
 552                                     KERB-ETYPE-INFO-ENTRY :: = SEQUENCE
 553                                     {
 554                                          encryption-type[0]  INTEGER,
 555                                          salt[1]        OCTET STRING
 556                                            OPTIONAL -- not sent, client
 557
 558
 559
 560 Trostle, Swift, Brezak, Gossman                                 [Page 9]
 561 \f
 562 INTERNET DRAFT                 April 2001           Expires October 2001
 563
 564
 565                                                     -- ignores if sent
 566                                     }
 567
 568                                     PKERB-ETYPE-INFO ::= SEQUENCE OF
 569                                                   KERB-ETYPE-INFO-ENTRY
 570
 571                                     The client should retry the request
 572                                     using only etypes (keytypes) that
 573                                     are contained within the
 574                                     PKERB-ETYPE-INFO structure in the
 575                                     previous response.
 576
 577        KRB5_KPASSWD_ETYPE_SRVGENKEYS 11 the request has the request-
 578                                         srv-gen-keys flag set and the
 579                                         server is returning the
 580                                         KeySequence structure defined
 581                                         above in the edata field of the
 582                                         reply. The server returns one
 583                                         key sequence structure of the
 584                                         same keytype for each key
 585                                         sequence structure in the
 586                                         client request, unless it does
 587                                         not support one of the keytypes
 588                                         (or etypes). In that case, it
 589                                         returns error
 590                                         KRB5_KPASSWD_ETYPE_NOSUPP as
 591                                         discussed above. The server MUST
 592                                         add keylength number of bits of
 593                                         entropy to each key. The
 594                                         assumption here is that the
 595                                         client may have added
 596                                         insufficient entropy to the
 597                                         request keys. The server SHOULD
 598                                         use the client key from each
 599                                         KeySequence structure as input
 600                                         into the final keyvalue for the
 601                                         returned key.
 602
 603        0xFFFF is returned if the request fails for some other reason.
 604        The client must interpret any non-zero result code as a failure.
 605
 606        key version (16 bits - optional):
 607        Present if and only if the result
 608        code is KRB5_KPASSWD_SUCCESS. This contains the key version of
 609        the new key(s).
 610
 611        result string length (16 bits):
 612        Gives the length of the following result string field, in bytes.
 613        If the result string is not present, the length is zero.
 614
 615        result string (optional):
 616        This field is a UTF-8 encoded string which can be displayed
 617        to the user. Specific reasons for a password set/change policy
 618        failure is one possible use for this string.
 619
 620
 621
 622 Trostle, Swift, Brezak, Gossman                                [Page 10]
 623 \f
 624 INTERNET DRAFT                 April 2001           Expires October 2001
 625
 626
 627        edata (optional):
 628        Used to convey additional information as defined by the
 629        result code.
 630
 631 5.  Acknowledgements
 632
 633    The authors thank Ken Raeburn, Sam Hartman, Tony Andrea, and other
 634    participants from the IETF Kerberos Working Group for their input to
 635    the document.
 636
 637 6.  Security Considerations
 638
 639    Password policies should be enforced to make sure that users do not
 640    pick passwords (for change password/key) that are vulnerable to brute
 641    force password guessing attacks.
 642
 643 7.  References
 644
 645    [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
 646        9, RFC 2026, October 1996.
 647
 648    [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
 649        Levels", BCP 14, RFC 2119, March 1997
 650
 651    [3] J. Kohl, C. Neuman. The Kerberos Network Authentication
 652        Service (V5), Request for Comments 1510.
 653
 654 8. Expiration Date
 655
 656       This draft expires on October 31st, 2001.
 657
 658 9. Authors' Addresses
 659
 660       Jonathan Trostle
 661       Cisco Systems
 662       170 W. Tasman Dr.
 663       San Jose, CA 95134
 664       Email: jtrostle@cisco.com
 665
 666       Mike Swift
 667       University of Washington
 668       Seattle, WA
 669       Email: mikesw@cs.washington.edu
 670
 671       John Brezak
 672       Microsoft
 673       1 Microsoft Way
 674       Redmond, WA 98052
 675       Email: jbrezak@microsoft.com
 676
 677       Bill Gossman
 678       Cisco Systems
 679       500 108th Ave. NE, Suite 500
 680       Bellevue, WA 98004
 681
 682
 683
 684 Trostle, Swift, Brezak, Gossman                                [Page 11]
 685 \f
 686 INTERNET DRAFT                 April 2001           Expires October 2001
 687
 688
 689       Email: bgossman@cisco.com
 690
 691 10. Full Copyright Statement
 692
 693    Copyright (C) The Internet Society (2001).  All Rights Reserved.
 694
 695    This document and translations of it may be copied and furnished to
 696    others, and derivative works that comment on or otherwise explain it
 697    or assist in its implmentation may be prepared, copied, published and
 698    distributed, in whole or in part, without restriction of any kind,
 699    provided that the above copyright notice and this paragraph are
 700    included on all such copies and derivative works.  However, this
 701    document itself may not be modified in any way, such as by removing
 702    the copyright notice or references to the Internet Society or other
 703    Internet organizations, except as needed for the purpose of
 704    developing Internet standards in which case the procedures for
 705    copyrights defined in the Internet Standards process must be
 706    followed, or as required to translate it into languages other than
 707    English.
 708
 709    The limited permissions granted above are perpetual and will not be
 710    revoked by the Internet Society or its successors or assigns.
 711
 712    This document and the information contained herein is provided on an
 713    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 714    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 715    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 716    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 717    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
 718
 719
 720
 721
 722
 723
 724
 725
 726
 727
 728
 729
 730
 731
 732
 733
 734
 735
 736
 737
 738
 739
 740
 741
 742
 743
 744
 745
 746 Trostle, Swift, Brezak, Gossman                                [Page 12]
 747 \f