doc/standardisation/draft-ietf-cat-kerberos-set-passwd-06.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-06.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 December 31st, 2001. Please send comments to
  45    the 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    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
  64 Trostle, Swift, Brezak, Gossman                                 [Page 1]
  65 \f
  66 INTERNET 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
  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                 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
 188 Trostle, Swift, Brezak, Gossman                                 [Page 3]
 189 \f
 190 INTERNET 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
 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                 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
 312 Trostle, Swift, Brezak, Gossman                                 [Page 5]
 313 \f
 314 INTERNET 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
 374 Trostle, Swift, Brezak, Gossman                                 [Page 6]
 375 \f
 376 INTERNET 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
 436 Trostle, Swift, Brezak, Gossman                                 [Page 7]
 437 \f
 438 INTERNET 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
 498 Trostle, Swift, Brezak, Gossman                                 [Page 8]
 499 \f
 500 INTERNET 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
 560 Trostle, Swift, Brezak, Gossman                                 [Page 9]
 561 \f
 562 INTERNET 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
 622 Trostle, Swift, Brezak, Gossman                                [Page 10]
 623 \f
 624 INTERNET 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
 657 5.  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
 663 6.  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
 669 7.  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
 684 Trostle, Swift, Brezak, Gossman                                [Page 11]
 685 \f
 686 INTERNET DRAFT                 June 2001           Expires December 2001
 687
 688
 689 8. Expiration Date
 690
 691       This draft expires on December 31st, 2001.
 692
 693 9. 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
 718 10. 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
 746 Trostle, Swift, Brezak, Gossman                                [Page 12]
 747 \f
 748 INTERNET 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
 808 Trostle, Swift, Brezak, Gossman                                [Page 13]
 809 \f