crypto/heimdal-0.6.3/doc/standardisation/draft-trostle-win2k-cat-kerberos-set-passwd-00.txt

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