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

   1 INTERNET-DRAFT                                        Mike Swift
   2 draft-ietf-cat-kerberos-set-passwd-00.txt             Microsoft
   3 expires March, 2000                                   Jonathan Trostle
   4                                                       Cisco Systems
   5                                                       John Brezak
   6                                                       Microsoft
   7
   8          Extending Change Password for Setting Kerberos Passwords
   9
  10 0. Status Of This Memo
  11
  12    This document is an Internet-Draft and is in full conformance with
  13    all provisions of Section 10 of RFC2026.
  14
  15    Internet-Drafts are working documents of the Internet Engineering
  16    Task Force (IETF), its areas, and its working groups.  Note that
  17    other groups may also distribute working documents as
  18    Internet-Drafts.
  19
  20    Internet-Drafts are draft documents valid for a maximum of six
  21    months and may be updated, replaced, or obsoleted by other
  22    documents at any time.  It is inappropriate to use Internet-
  23    Drafts as reference material or to cite them other than as
  24    "work in progress."
  25
  26    The list of current Internet-Drafts can be accessed at
  27    http://www.ietf.org/ietf/1id-abstracts.txt
  28
  29    The list of Internet-Draft Shadow Directories can be accessed at
  30    http://www.ietf.org/shadow.html.
  31
  32    Comments and suggestions on this document are encouraged.  Comments
  33    on this document should be sent to the CAT working group discussion
  34    list:
  35                        ietf-cat-wg@stanford.edu
  36
  37    This document expires in March, 2000.
  38
  39 1. Abstract
  40
  41    The Kerberos [1] change password protocol [2], does not allow for
  42    an administrator to set a password for a new user. This functionality
  43    is useful in some environments, and this proposal extends [2] to
  44    allow password setting. The changes are: adding new fields to the
  45    request message to indicate the principal which is having its
  46    password set, not requiring the initial flag in the service ticket,
  47    using a new protocol version number, and adding three new result
  48    codes.
  49
  50 2. The Protocol
  51
  52    The service must accept requests on UDP port 464 and TCP port 464 as
  53    well. The protocol consists of a single request message followed by
  54    a single reply message.  For UDP transport, each message must be fully
  55    contained in a single UDP packet.
  56
  57    For TCP transport, there is a 4 octet header in network byte order
  58    precedes the message and specifies the length of the message. This
  59    requirement is consistent with the TCP transport header in 1510bis.
  60
  61 Request Message
  62
  63        0                   1                   2                   3
  64        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
  65       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  66       |         message length        |    protocol version number    |
  67       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  68       |          AP_REQ length        |         AP-REQ data           /
  69       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  70       /                        KRB-PRIV message                       /
  71       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  72
  73    All 16 bit fields are in big-endian order.
  74
  75    message length field: contains the number of bytes in the message
  76    including this field.
  77
  78    protocol version number: contains the hex constant 0xff80 (big-endian
  79    integer).
  80
  81    AP-REQ length: length of AP-REP data, in bytes. If the length is zero,
  82    then the last field contains a KRB-ERROR message instead of a KRB-PRIV
  83    message.
  84
  85    AP-REQ data: (see [1]) The AP-REQ message must be for the service
  86    principal kadmin/changepw@REALM, where REALM is the REALM of the user
  87    who wishes to change/set his password.  The ticket in the AP-REQ must
  88    must include a subkey in the Authenticator.
  89
  90    KRB-PRIV message (see [1]) This KRB-PRIV message must be generated
  91    using the subkey from the authenticator in the AP-REQ data. The
  92    initial flag of the service ticket is ignored by the server unless
  93    policy dictates otherwise, in which case the request will be rejected
  94    with result code 0x0007 if the initial flag is not set and is required
  95    for this particular request. The user-data component of the message
  96    consists of the following ASN.1 structure encoded as an OCTET STRING:
  97
  98    ChangePasswdData ::=  SEQUENCE {
  99                        newpasswd[0]   OCTET STRING,
 100                        targname[2]    PrincipalName OPTIONAL,
 101                        targrealm[3]   Realm OPTIONAL
 102                        }
 103
 104    The server must verify the AP-REQ message, check whether the client
 105    principal in the ticket is authorized to set/change the password
 106    (either for that principal, or for the principal in the targname
 107    field if present), and decrypt the new password. The server also
 108    checks whether the initial flag is required for this request,
 109    replying with status 0x0007 if it is not set and should be. An
 110    authorization failure is cause to respond with status 0x0005. For
 111    forward compatibility, the server should be prepared to ignore fields
 112    after targrealm in the structure that it does not understand.
 113
 114    The newpasswd field contains the cleartext password, and the server
 115    should apply any local policy checks including password policy checks.
 116    The server then generates the appropriate keytypes from the password
 117    and stores them in the KDC database. If all goes well, status 0x0000
 118    is returned to the client in the reply message (see below).
 119
 120 Reply Message
 121
 122        0                   1                   2                   3
 123        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
 124       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 125       |         message length        |    protocol version number    |
 126       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 127       |          AP_REP length        |         AP-REP data           /
 128       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 129       /                KRB-PRIV or KRB-ERROR message                  /
 130       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 131
 132    All 16 bit fields are in big-endian order.
 133
 134    message length field: contains the number of bytes in the message
 135    including this field.
 136
 137    protocol version number: contains the hex constant 0x0001 (big-endian
 138    integer). (The reply message has the same format as in [2]).
 139
 140    AP-REP length: length of AP-REP data, in bytes. If the length is zero,
 141    then the last field contains a KRB-ERROR message instead of a KRB-PRIV
 142    message.
 143
 144    AP-REP data: the AP-REP is the response to the AP-REQ in the request
 145    packet.
 146
 147    KRB-PRIV or KRB-ERROR message: - from [2]: if the AP-REP length is
 148    zero, then this field contains a KRB-ERROR message.  Otherwise, it
 149    contains a KRB-PRIV message. This KRB-PRIV message must be generated
 150    using the subkey in the authenticator in the AP-REQ data.
 151
 152    The server will respond with a KRB-PRIV message unless it cannot
 153    decode the client AP-REQ or KRB-PRIV message, in which case it will
 154    respond with a KRB-ERROR message.
 155
 156    The user-data component of the KRB-PRIV message, or e-data component
 157    of the KRB-ERROR message, must consist of the following data.
 158
 159        0                   1                   2                   3
 160        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
 161       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 162       |          result code          |        result string          /
 163       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 164
 165       result code (16 bits) (result codes 0-4 are from [2]):
 166          The result code must have one of the following values (big-
 167          endian integer):
 168          KRB5_KPASSWD_SUCCESS      0 request succeeds (This value is not
 169                                      allowed in a KRB-ERROR message)
 170
 171          KRB5_KPASSWD_MALFORMED    1 request fails due to being malformed
 172          KRB5_KPASSWD_HARDERROR    2 request fails due to "hard" error in
 173                                      processing the request (for example,
 174                                      there is a resource or other problem
 175                                      causing the request to fail)
 176          KRB5_KPASSWD_AUTHERROR    3 request fails due to an error in
 177                                      authentication processing
 178          KRB5_KPASSWD_SOFTERROR    4 request fails due to a "soft" error
 179                                      in processing the request
 180          KRB5_KPASSWD_ACCESSDENIED 5 requestor not authorized
 181          KRB5_KPASSWD_BAD_VERSION  6 protocol version unsupported
 182          KRB5_KPASSWD_INITIAL_FLAG_NEEDED 7 initial flag required
 183          0xFFFF if the request fails for some other reason.
 184          Although only a few non-zero result codes are specified here,
 185          the client should accept any non-zero result code as indicating
 186          failure.
 187       result string - from [2]:
 188          This field should contain information which the server thinks
 189          might be useful to the user, such as feedback about policy
 190          failures.  The string must be encoded in UTF-8.  It may be
 191          omitted if the server does not wish to include it.  If it is
 192          present, the client should display the string to the user.
 193          This field is analogous to the string which follows the numeric
 194          code in SMTP, FTP, and similar protocols.
 195
 196 3. Bibliography
 197
 198    [1] J. Kohl, C. Neuman. The Kerberos Network Authentication
 199    Service (V5). Request for Comments 1510.
 200
 201    [2] M. Horowitz. Kerberos Change Password Protocol.
 202    ftp://ds.internic.net/internet-drafts/
 203    draft-ietf-cat-kerb-chg-password-02.txt
 204
 205 4. Expiration Date
 206
 207 This draft expires on March 31, 2000.
 208
 209 5. Authors' Addresses
 210
 211    Jonathan Trostle
 212    Cisco Systems
 213    170 W. Tasman Dr.
 214    San Jose, CA 95134
 215
 216    Email: jtrostle@cisco.com, jtrostle@world.std.com
 217
 218    Mike Swift
 219    1 Microsoft Way
 220    Redmond, WA 98052
 221    mikesw@microsoft.com
 222
 223    John Brezak
 224    1 Microsoft Way
 225    Redmond, WA 98052
 226    jbrezak@microsoft.com