INTERNET-DRAFT                                        Mike Swift
draft-ietf-cat-kerberos-set-passwd-01.txt             Microsoft
expires March,
February 2000                                         Jonathan Trostle
                                                      Cisco Systems
                                                      John Brezak

         Extending Change Password for Setting
                                                      Bill Gossman

              Kerberos Passwords Set/Change Password: Version 2

0. Status Of This Memo

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

   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-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

   Comments and suggestions on this document are encouraged.  Comments
   on this document should be sent to the CAT working group discussion

   This document expires in March, 2000.

1. Abstract

   The Kerberos [1] (RFC 1510 [3]) change password protocol [2], (Horowitz [4]),
   does not allow for an administrator to set a password for a new user.
   This functionality is useful in some environments, and this proposal
   extends [2] [4] to allow password setting. The changes are: adding new
   fields to the request message to indicate the principal which is
   having its password set, not requiring the initial flag in the service
   ticket, using a new protocol version number, and adding three new
   result codes. We also extend the set/change protocol to allow a
   client to send a sequence of keys to 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

2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   this document are to be interpreted as described in RFC-2119 [2].

3. The Protocol

   The service must accept requests on UDP port 464 and TCP port 464 as
   well. 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
   precedes the message and specifies the length of the message. This
   requirement is consistent with the TCP transport header in 1510bis.

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 big-endian network byte order.

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

   protocol version number: contains the hex constant 0xff80 (big-endian
   integer). 0x0002 (network
   byte order).

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

   AP-REQ data: (see [1]) [3]) The AP-REQ message must be for the service
   principal kadmin/changepw@REALM, where REALM is the REALM of the user
   who wishes to change/set his password.  The ticket in the AP-REQ must
   must include a subkey in the Authenticator. 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 password requests. We have the following definitions:

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

   change password:  yes         yes           no

   set password:     no          no            yes

   set key:          no          policy        yes
   KRB-PRIV message (see [1]) [3]) This KRB-PRIV message must be generated
   using the subkey from the authenticator in the AP-REQ data.

   initial flag of the service ticket is ignored by the server unless
   policy dictates otherwise, in which case the request will be rejected
   with result code 0x0007 if the initial flag is not set and is required
   for this particular request. The user-data component of the message consists of the following ASN.1
   structure encoded as an OCTET STRING:

   ChangePasswdData ::= :: =  SEQUENCE {
                       newpasswd[0]   OCTET STRING,
                       newpasswdorkeys[0]   NewPasswdOrKeys,
                       targname[1]          PrincipalName OPTIONAL,
                         -- only present in set password: the principal
                         -- which will have its password set
                       targrealm[2]         Realm OPTIONAL,
                         -- only present in set password: the realm for
                         -- the principal which will have its password set


   NewPasswdOrKeys :: = CHOICE {
                       passwords[0]  KeySequence,
                       keyseq[1]     PasswordSequence

   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 set password

   The server must verify the AP-REQ message, check whether the client
   principal in the ticket is authorized to set/change set or change the password
   (either for that principal, or for the principal in the targname
   field if present), and decrypt the new password. 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 newpasswd newpasswdorkeys field contains either the new cleartext password, and password
   (with the server
   should apply any local policy checks including old cleartext password policy checks.
   The server then generates for a change password operation),
   or a sequence of encryption keys with their respective salts.

   In the appropriate keytypes from cleartext password case, if the old password
   and stores them is sent in the KDC database. If all goes well, status 0x0000
   request, the request is returned defined to be a change password request. If
   the client old password is not present in the request, the request is 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 set
   password service. 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 set password service should check that all keys are in the
   proper format, returning the KRB5_KPASSWD_MALFORMED error otherwise.

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 or KRB-ERROR message                     /

   All 16 bit fields are in big-endian network byte order.

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

   protocol version number: contains the hex constant 0x0001 (big-endian
   integer). 0x0002 (network
   byte order). (The reply message has the same format as in [2]). [4]).

   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

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

   KRB-PRIV or KRB-ERROR message: - from [2]: if the AP-REP length is
   zero, then this field contains a KRB-ERROR message.  Otherwise, it
   contains a KRB-PRIV message. [4]: This KRB-PRIV message must be generated using the
   subkey in the authenticator in the AP-REQ data.

   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. NOTE: Unlike change password version
   1, the KRB-ERROR message will be sent back without any encapsulation.

   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          |        result string          /
      |                             edata                             /
      result code (16 bits) (result codes 0-4 are from [2]): [4]):
         The result code must have one of the following values (big-
         endian integer): (network
         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 malformed
         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 processing
         KRB5_KPASSWD_SOFTERROR    4 request fails due to a "soft" soft error
                                     in processing the request
         KRB5_KPASSWD_ACCESSDENIED 5 requestor not authorized
         KRB5_KPASSWD_BAD_VERSION  6 protocol version unsupported
         KRB5_KPASSWD_INITIAL_FLAG_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 request).
         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 supports:

                encryption-type[0]  INTEGER,
                salt[1]             OCTET STRING OPTIONAL -- not sent


         The client should retry the request using only etypes (keytypes)
         that are contained within the PKERB-ETYPE-INFO structure in the
         previous response.
         0xFFFF if the request fails for some other reason.
         Although only a few non-zero result codes are specified here,
         The client should accept must interpret any non-zero result code as indicating a failure.
      result string - from [2]: [4]:
         This field should contain information which the server thinks
         might be useful to the user, such as feedback about policy
         failures.  The string must be is a UTF-8 encoded in UTF-8.  It may string which should be
         omitted if the server does not wish displayed
         to include it.  If it is
         present, the client should display the string to user by the user.
         This field client. Specific reasons for a password
         set/change policy failure is analogous one use for this string.
      edata: used to convey additional information as defined by the string which follows the numeric
         code in SMTP, FTP, and similar protocols.

3. Bibliography
         result code.

4. 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
   [3] J. Kohl, C. Neuman. The Kerberos Network Authentication
       Service (V5). (V5), Request for Comments 1510.


   [4] M. Horowitz. Kerberos Change Password Protocol. Protocol,


5. Expiration Date

   This draft expires on March 31, in August 2000.


6. Authors' Addresses

   Jonathan Trostle
   Cisco Systems
   170 W. Tasman Dr.
   San Jose, CA 95134

   Mike Swift
   1 Microsoft Way
   Redmond, WA 98052

   John Brezak
   1 Microsoft Way
   Redmond, WA 98052

   Bill Gossman
   Cybersafe Corporation