[Search] [txt|pdfized|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03 04 05 06                                          
Network Working Group                                   Jonathan Trostle
INTERNET-DRAFT                                             Cisco Systems
Category: Standards Track                                     Mike Swift
                                                        University of WA
                                                             John Brezak
                                                            Bill Gossman
                                                           Cisco Systems

                Kerberos Set/Change Password: Version 2

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [6].

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet- Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This draft expires on October 31st, 2001. Please send comments to the

1. Abstract

   This proposal specifies a Kerberos (RFC 1510 [3]) change/set password
   protocol and a Kerberos change/set key protocol. The protocol
   consists of a single request and reply message. The request message
   includes both AP_REQ and KRB_PRIV submessages; the new password is
   contained in the KRB_PRIV submessage which is encrypted in the
   session key from the ticket. The original Kerberos change password
   protocol did not allow for an administrator to set a password for a
   new user. This functionality is useful in some environments, and this
   proposal allows password setting as well as password changing. The
   protocol includes fields in the request message to indicate the
   principal which is having its password set. We also extend the
   set/change protocol to allow a client to send a sequence of keys to

Trostle, Swift, Brezak, Gossman                                 [Page 1]

INTERNET DRAFT                 April 2001           Expires October 2001

   the KDC instead of a cleartext password. If in the cleartext password
   case, the cleartext password fails to satisfy password policy, the
   server should use the result code KRB5_KPASSWD_POLICY_REJECT.

2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC2119 [7].

3. Definitions from RFC 1510

   We include some of the relevant ASN.1 definitions from RFC 1510 in
   this section.

      Realm ::=           GeneralString

      PrincipalName ::=   SEQUENCE {
                          name-type[0]     INTEGER,
                          name-string[1]   SEQUENCE OF GeneralString

      KerberosTime ::=    GeneralizedTime
                          -- Specifying UTC time zone (Z)

      HostAddress ::=     SEQUENCE  {
                          addr-type[0]             INTEGER,
                          address[1]               OCTET STRING

      EncryptedData ::=   SEQUENCE {
                        etype[0]     INTEGER, -- EncryptionType
                        kvno[1]      INTEGER OPTIONAL,
                        cipher[2]    OCTET STRING -- ciphertext

      EncryptionKey ::=   SEQUENCE {
                          keytype[0]    INTEGER,
                          keyvalue[1]   OCTET STRING

      Checksum ::=        SEQUENCE {
                          cksumtype[0]   INTEGER,
                          checksum[1]    OCTET STRING

              pvno [0]         INTEGER,        -- indicates Version 5
              msg-type [1]     INTEGER,        -- indicates KRB_AP_REQ
              ap-options[2]    APOptions,
              ticket[3]        Ticket,
              authenticator[4] EncryptedData

Trostle, Swift, Brezak, Gossman                                 [Page 2]

INTERNET DRAFT                 April 2001           Expires October 2001

      APOptions ::= BIT STRING {

              reserved (0),
              use-session-key (1),
              mutual-required (2)

      Ticket ::= [APPLICATION 1] SEQUENCE {
              tkt-vno [0]     INTEGER,        -- indicates Version 5
              realm [1]       Realm,
              sname [2]       PrincipalName,
              enc-part [3]    EncryptedData

      -- Encrypted part of ticket
      EncTicketPart ::= [APPLICATION 3] SEQUENCE {
              flags[0]        TicketFlags,
              key[1]          EncryptionKey,
              crealm[2]       Realm,
              cname[3]        PrincipalName,
              transited[4]    TransitedEncoding,
              authtime[5]     KerberosTime,
              starttime[6]    KerberosTime OPTIONAL,
              endtime[7]      KerberosTime,
              renew-till[8]   KerberosTime OPTIONAL,
              caddr[9]        HostAddresses OPTIONAL,
              authorization-data[10]  AuthorizationData OPTIONAL

      -- Unencrypted authenticator
      Authenticator ::= [APPLICATION 2] SEQUENCE  {
              authenticator-vno[0]    INTEGER,
              crealm[1]               Realm,
              cname[2]                PrincipalName,
              cksum[3]                Checksum OPTIONAL,
              cusec[4]                INTEGER,
              ctime[5]                KerberosTime,
              subkey[6]               EncryptionKey OPTIONAL,
              seq-number[7]           INTEGER OPTIONAL,
              authorization-data[8]   AuthorizationData OPTIONAL

              pvno [0]        INTEGER,        -- represents Kerberos V5
              msg-type [1]    INTEGER,        -- represents KRB_AP_REP
              enc-part [2]    EncryptedData

      EncAPRepPart ::= [APPLICATION 27] SEQUENCE {
              ctime [0]       KerberosTime,
              cusec [1]       INTEGER,
              subkey [2]      EncryptionKey OPTIONAL,
              seq-number [3]  INTEGER OPTIONAL

Trostle, Swift, Brezak, Gossman                                 [Page 3]

INTERNET DRAFT                 April 2001           Expires October 2001


   Here is the syntax of the KRB_ERROR message:

              pvno[0]         INTEGER,
              msg-type[1]     INTEGER,
              ctime[2]        KerberosTime OPTIONAL,
              cusec[3]        INTEGER OPTIONAL,
              stime[4]        KerberosTime,
              susec[5]        INTEGER,
              error-code[6]   INTEGER,
              crealm[7]       Realm OPTIONAL,
              cname[8]        PrincipalName OPTIONAL,
              realm[9]        Realm, -- Correct realm
              sname[10]       PrincipalName, -- Correct name
              e-text[11]      GeneralString OPTIONAL,
              e-data[12]      OCTET STRING OPTIONAL

   The KRB_PRIV message is used to send the request and reply data:

                   pvno[0]                   INTEGER,
                   msg-type[1]               INTEGER,
                   enc-part[3]               EncryptedData

      EncKrbPrivPart ::=   [APPLICATION 28] SEQUENCE {
                   user-data[0]              OCTET STRING,
                   timestamp[1]              KerberosTime OPTIONAL,
                   usec[2]                   INTEGER OPTIONAL,
                   seq-number[3]             INTEGER OPTIONAL,
                   s-address[4]              HostAddress,
                                                        -- sender's addr
                   r-address[5]              HostAddress OPTIONAL
                                                        -- recip's addr

4. The Protocol

   The service SHOULD accept requests on UDP port 464 and TCP port 464
   as well. Use of other ports can significantly increase the complexity
   and size of IPSEC policy rulesets in organizations that have IPSEC
   capable nodes.

   The protocol consists of a single request message followed by a
   single reply message.  For UDP transport, each message must be fully
   contained in a single UDP packet.

   For TCP transport, there is a 4 octet header in network byte order
   that precedes the message and specifies the length of the message.
   This requirement is consistent with the TCP transport header in

Trostle, Swift, Brezak, Gossman                                 [Page 4]

INTERNET DRAFT                 April 2001           Expires October 2001


   Request Message

        0                   1                   2                   3
        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
       |         message length        |    protocol version number    |
       |          AP_REQ length        |         AP-REQ data           /
       /                        KRB-PRIV message                       /

   All 16 bit fields are in network byte order.

   message length field: contains the number of bytes in the message
   including this field.

   protocol version number: contains the hex constant 0x0002 (network
   byte order).

   AP-REQ length: length of AP-REQ data, in bytes. If the length is
   zero, then the last field contains a KRB-ERROR message instead of a
   KRB-PRIV message.

   AP-REQ data: (see [3]) For a change password/key request, the AP-REQ
   message service ticket sname, srealm principal identifier is
   kadmin/changepw@REALM where REALM is the realm of the change password
   service. The same applies to a set password/key request except the
   principal identifier is kadmin/setpw@REALM. To enable setting of
   passwords/keys, it is not required that the initial flag be set in
   the Kerberos service ticket. The initial flag is required for change
   requests, but not for set requests. We have the following

                   old passwd   initial flag  target principal can be
                   in request?  required?     distinct from
                                              authenticating principal?

   change password:  yes         yes           no

   set password:     no          policy (*)    yes

   set key:          no          policy (*)    yes

   change key:       no          yes           no

   policy (*): implementations SHOULD allow administrators to set the
   initial flag required for set requests policy to either yes or no.
   Clients MUST be able to retry set requests that fail due to error 7
   (initial flag required) with an initial ticket. Clients SHOULD NOT

Trostle, Swift, Brezak, Gossman                                 [Page 5]

INTERNET DRAFT                 April 2001           Expires October 2001

   cache service tickets targetted at kadmin/changepw.

   KRB-PRIV message (see [3]) This KRB-PRIV message must be encrypted
   using the session key from the ticket in the AP-REQ.

   The user-data component of the message consists of the following
   ASN.1 encoded structure:

    ChangePasswdData :: =  SEQUENCE {
                        newpasswdorkeys[0]   NewPasswdOrKeys,
                        targname[1]          PrincipalName OPTIONAL,
                          -- only present in set password/key: the
                          -- principal which will have its password
                          -- or keys set. Not present in a set request
                          -- if the client principal from the ticket is
                          -- the principal having its passwords or keys
                          -- set.
                        targrealm[2]         Realm OPTIONAL,
                          -- only present in set password/key: the realm
                          -- for the principal which will have its
                          -- password or keys set. Not present in a set
                          -- request if the client principal from the
                          -- ticket is the principal having its
                          -- passwords or keys set.
                        flags[3]             RequestFlags OPTIONAL
                          -- 32 bit string

    NewPasswdOrKeys :: = CHOICE {
                       passwords[0]  PasswordSequence, -- chg/set passwd
                       keyseq[1]     KeySequences      -- chg/set key

    KeySequences :: = SEQUENCE OF KeySequence

    KeySequence :: = SEQUENCE {
                     key[0]        EncryptionKey,
                     salt[1]       OCTET STRING OPTIONAL,
                     salt-type[2]  INTEGER OPTIONAL

    PasswordSequence :: = SEQUENCE {
                        newpasswd[0]  OCTET STRING,
                        oldpasswd[1]  OCTET STRING OPTIONAL
                          -- oldpasswd always present for change
                          -- password but not present for set
                          -- password, set key, or change key

    RequestFlags :: = BIT STRING {
                           -- only in change/set keys
                           -- if the client desires

Trostle, Swift, Brezak, Gossman                                 [Page 6]

INTERNET DRAFT                 April 2001           Expires October 2001

                           -- server to contribute to
                           -- keys;
                           -- server will return keys

   The server must verify the AP-REQ message, check whether the client
   principal in the ticket is authorized to set/change the password/keys
   (either for that principal, or for the principal in the targname
   field if present), and decrypt the new password/keys. The server also
   checks whether the initial flag is required for this request,
   replying with status 0x0007 if it is not set and should be. An
   authorization failure is cause to respond with status 0x0005. For
   forward compatibility, the server should be prepared to ignore fields
   after targrealm in the structure that it does not understand.

   The newpasswdorkeys field contains either the new cleartext password
   (with the old cleartext password for a change password operation), or
   a sequence of encryption keys with their respective salts.

   In the cleartext password case, if the old password is sent in the
   request, the request MUST be a change password request. If the old
   password is not present in the request, the request MUST be a set
   password request. The server should apply policy checks to the old
   and new password after verifying that the old password is valid. The
   server can check validity by obtaining a key from the old password
   with a keytype that is present in the KDC database for the user and
   comparing the keys for equality. The server then generates the
   appropriate keytypes from the password and stores them in the KDC
   database. If all goes well, status 0x0000 is returned to the client
   in the reply message (see below). For a change password operation,
   the initial flag in the service ticket MUST be set.

   In the key sequence case, the sequence of keys is sent to the change
   or set password service (kadmin/changepw or kadmin/setpw
   respectively). For a principal that can act as a server, its
   preferred keytype should be sent as the first key in the sequence,
   but the KDC is not required to honor this preference. Application
   servers should use the key sequence option for changing/setting their
   keys. The change/set password services should check that all keys are
   in the proper format, returning the KRB5_KPASSWD_MALFORMED error

   For change/set key, the request message may include the request flags
   bit string with the request-srv-gen-keys bit set. In this case, the
   client is requesting that the server add entropy to its keys in the
   KeySequences field. When using this option, the client SHOULD attempt
   to generate pseudorandom keys with as much entropy as possible in its
   request. The server will return the final key sequence in a
   KeySequences structure in the edata of the reply message. The server
   does not store any of the new keys at this point. The client MUST
   make a subsequent change/set key request without the request-srv-
   gen-keys bit; if the server returns KRB5_KPASSWD_SUCCESS for this
   second request, then the new keys have been written into the
   database. A conformant server MUST support this option.

Trostle, Swift, Brezak, Gossman                                 [Page 7]

INTERNET DRAFT                 April 2001           Expires October 2001

   Reply Message

        0                   1                   2                   3
        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
       |         message length        |    protocol version number    |
       |          AP_REP length        |         AP-REP data           /
       /                          KRB-PRIV message                     /

   All 16 bit fields are in network byte order.

   message length field: contains the number of bytes in the message
   including this field.

   protocol version number: contains the hex constant 0x0002 (network
   byte order). (The reply message has the same format as in the
   original Kerberos change password protocol).

   AP-REP length: length of AP-REP data, in bytes. If the length is
   zero, then the last field contains a KRB-ERROR message instead of a
   KRB-PRIV message. An implementation should check this field to
   determine whether a KRB-ERROR message or KRB-PRIV message has been

   AP-REP data: the AP-REP is the response to the AP-REQ in the request

   KRB-PRIV message: This KRB-PRIV message must be encrypted using the
   session key from the ticket in the AP-REQ.

   The server will respond with a KRB-PRIV message unless it cannot
   validate the client AP-REQ or KRB-PRIV message, in which case it will
   respond with a KRB-ERROR message.

   The user-data component of the KRB-PRIV message, or e-data component
   of the KRB-ERROR message, must consist of the following data.

        0                   1                   2                   3
        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
       |          result code          | key version (only on success) |
       |     result string length      |         result string         /
       |                             edata                             /

       result code (16 bits) (result codes 0-4 are the same as in the
       original Kerberos change password protocol):

       The result code must have one of the following values (network

Trostle, Swift, Brezak, Gossman                                 [Page 8]

INTERNET DRAFT                 April 2001           Expires October 2001

       byte order):

       KRB5_KPASSWD_SUCCESS            0 request succeeds (This
                                         value is not allowed in a
                                         KRB-ERROR message)

       KRB5_KPASSWD_MALFORMED          1 request fails due to being

       KRB5_KPASSWD_HARDERROR          2 request fails due to "hard"
                                         error in processing the
                                         request (for example, there
                                         is a resource or other
                                         problem causing the request
                                         to fail)

       KRB5_KPASSWD_AUTHERROR          3 request fails due to an
                                         error in authentication

       KRB5_KPASSWD_SOFTERROR          4 request fails due to a soft
                                         error in processing the

       KRB5_KPASSWD_ACCESSDENIED       5 requestor not authorized

       KRB5_KPASSWD_BAD_VERSION        6 protocol version unsupported

       KRB5_KPASSWD_INITIALFLAG_NEEDED 7 initial flag required

       KRB5_KPASSWD_POLICY_REJECT      8 new cleartext password fails
                                         policy; the result string
                                         should include a text
                                         message to be presented to
                                         the user.

       KRB5_KPASSWD_BAD_PRINCIPAL      9 target principal does not
                                         exist (only in response to
                                         a set password or set key

       KRB5_KPASSWD_ETYPE_NOSUPP 10 the request contains a key sequence
                                    containing at least one etype that
                                    is not supported by the KDC. The
                                    response edata contains an ASN.1
                                    encoded PKERB-ETYPE-INFO type that
                                    specifies the etypes that the KDC

                                    KERB-ETYPE-INFO-ENTRY :: = SEQUENCE
                                         encryption-type[0]  INTEGER,
                                         salt[1]        OCTET STRING
                                           OPTIONAL -- not sent, client

Trostle, Swift, Brezak, Gossman                                 [Page 9]

INTERNET DRAFT                 April 2001           Expires October 2001

                                                    -- ignores if sent

                                    PKERB-ETYPE-INFO ::= SEQUENCE OF

                                    The client should retry the request
                                    using only etypes (keytypes) that
                                    are contained within the
                                    PKERB-ETYPE-INFO structure in the
                                    previous response.

       KRB5_KPASSWD_ETYPE_SRVGENKEYS 11 the request has the request-
                                        srv-gen-keys flag set and the
                                        server is returning the
                                        KeySequence structure defined
                                        above in the edata field of the
                                        reply. The server returns one
                                        key sequence structure of the
                                        same keytype for each key
                                        sequence structure in the
                                        client request, unless it does
                                        not support one of the keytypes
                                        (or etypes). In that case, it
                                        returns error
                                        KRB5_KPASSWD_ETYPE_NOSUPP as
                                        discussed above. The server MUST
                                        add keylength number of bits of
                                        entropy to each key. The
                                        assumption here is that the
                                        client may have added
                                        insufficient entropy to the
                                        request keys. The server SHOULD
                                        use the client key from each
                                        KeySequence structure as input
                                        into the final keyvalue for the
                                        returned key.

       0xFFFF is returned if the request fails for some other reason.
       The client must interpret any non-zero result code as a failure.

       key version (16 bits - optional):
       Present if and only if the result
       code is KRB5_KPASSWD_SUCCESS. This contains the key version of
       the new key(s).

       result string length (16 bits):
       Gives the length of the following result string field, in bytes.
       If the result string is not present, the length is zero.

       result string (optional):
       This field is a UTF-8 encoded string which can be displayed
       to the user. Specific reasons for a password set/change policy
       failure is one possible use for this string.

Trostle, Swift, Brezak, Gossman                                [Page 10]

INTERNET DRAFT                 April 2001           Expires October 2001

       edata (optional):
       Used to convey additional information as defined by the
       result code.

5.  Acknowledgements

   The authors thank Ken Raeburn, Sam Hartman, Tony Andrea, and other
   participants from the IETF Kerberos Working Group for their input to
   the document.

6.  Security Considerations

   Password policies should be enforced to make sure that users do not
   pick passwords (for change password/key) that are vulnerable to brute
   force password guessing attacks.

7.  References

   [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
       9, RFC 2026, October 1996.

   [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997

   [3] J. Kohl, C. Neuman. The Kerberos Network Authentication
       Service (V5), Request for Comments 1510.

8. Expiration Date

      This draft expires on October 31st, 2001.

9. Authors' Addresses

      Jonathan Trostle
      Cisco Systems
      170 W. Tasman Dr.
      San Jose, CA 95134
      Email: jtrostle@cisco.com

      Mike Swift
      University of Washington
      Seattle, WA
      Email: mikesw@cs.washington.edu

      John Brezak
      1 Microsoft Way
      Redmond, WA 98052
      Email: jbrezak@microsoft.com

      Bill Gossman
      Cisco Systems
      500 108th Ave. NE, Suite 500
      Bellevue, WA 98004

Trostle, Swift, Brezak, Gossman                                [Page 11]

INTERNET DRAFT                 April 2001           Expires October 2001

      Email: bgossman@cisco.com

10. Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation may be prepared, copied, published and
   distributed, in whole or in part, without restriction of any kind,
   provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an

Trostle, Swift, Brezak, Gossman                                [Page 12]