doc/draft-ietf-cat-kerb-chg-password-00.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                        M. Horowitz
   8 <draft-ietf-cat-kerb-chg-password-00.txt>               Cygnus Solutions
   9 Internet-Draft                                               March, 1997
  10 Expire in six months
  11
  12                    Kerberos Change Password Protocol
  13
  14 Status of this Memo
  15
  16    This document is an Internet-Draft.  Internet-Drafts are working
  17    documents of the Internet Engineering Task Force (IETF), its areas,
  18    and its working groups.  Note that other groups may also distribute
  19    working documents as Internet-Drafts.
  20
  21    Internet-Drafts are draft documents valid for a maximum of six months
  22    and may be updated, replaced, or obsoleted by other documents at any
  23    time.  It is inappropriate to use Internet-Drafts as reference
  24    material or to cite them other than as ``work in progress.''
  25
  26    To learn the current status of any Internet-Draft, please check the
  27    ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
  28    Directories on ds.internic.net (US East Coast), nic.nordu.net
  29    (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
  30    Rim).
  31
  32    Distribution of this memo is unlimited.  Please send comments to the
  33    <cat-ietf@mit.edu> mailing list.
  34
  35 Abstract
  36
  37    The Kerberos V5 protocol [RFC1510] does not describe any mechanism
  38    for users to change their own passwords.  In order to promote
  39    interoperability between workstations, personal computers, terminal
  40    servers, routers, and KDC's from multiple vendors, a common password
  41    changing protocol is required.
  42
  43
  44
  45 Overview
  46
  47    When a user wishes to change his own password, or is required to by
  48    local policy, a simple request of a password changing service is
  49    necessary.  This service must be implemented on at least one host for
  50    each Kerberos realm, probably on one of the kdc's for that realm.
  51    The service must accept requests on UDP port 464 (kpasswd), and may
  52    accept requests on TCP port 464 as well.
  53
  54    The protocol itself consists of a single request message followed by
  55    a single reply message.  For UDP transport, each message must be
  56    fully contained in a single UDP packet.
  57
  58
  59
  60
  61
  62
  63
  64
  65 Horowitz                                                        [Page 1]
  66 \f
  67 Internet Draft      Kerberos Change Password Protocol        March, 1997
  68
  69
  70 Request Message
  71
  72        0                   1                   2                   3
  73        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
  74       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  75       |         message length        |    protocol version number    |
  76       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  77       |          AP_REQ length        |         AP-REQ data           /
  78       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  79       /                        KRB-PRIV message                       /
  80       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  81
  82    message length (16 bits)
  83       Contains the length of the message, including this field, in bytes
  84       (big-endian integer)
  85    protocol version number (16 bits)
  86       Contains the hex constant 0x0001 (big-endian integer)
  87    AP-REQ length (16 bits)
  88       length (big-endian integer) of AP-REQ data, in bytes.
  89    AP-REQ data, as described in RFC1510 (variable length)
  90       This AP-REQ must be for the service principal
  91       kadmin/changepw@REALM, where REALM is the REALM of the user who
  92       wishes to change his password.  The Ticket in the AP-REQ must be
  93       derived from an AS request (thus having the INITIAL flag set), and
  94       must include a subkey in the Authenticator.
  95    KRB-PRIV message, as described in RFC1510 (variable length)
  96       This KRB-PRIV message must be generated using the subkey in the
  97       Authenticator in the AP-REQ data.  The user-data component of the
  98       message must consist of the user's new password.
  99
 100    The server must verify the AP-REQ message, decrypt the new password,
 101    perform any local policy checks (such as password quality, history,
 102    authorization, etc.) required, then set the password to the new value
 103    specified.
 104
 105    The principal whose password is to be changed is the principal which
 106    authenticated to the password changing service.  This protocol does
 107    not address administrators who want to change passwords of principal
 108    besides their own.
 109
 110
 111 Reply Message
 112
 113        0                   1                   2                   3
 114        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
 115       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 116       |         message length        |    protocol version number    |
 117       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 118       |          AP_REP length        |         AP-REP data           /
 119       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 120       /                KRB-PRIV or KRB-ERROR message                  /
 121       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 122
 123    message length (16 bits)
 124
 125
 126
 127 Horowitz                                                        [Page 2]
 128 \f
 129 Internet Draft      Kerberos Change Password Protocol        March, 1997
 130
 131
 132       Contains the length of the message, including this field, in bytes
 133       (big-endian integer),
 134    protocol version number (16 bits)
 135       Contains the hex constant 0x0001 (big-endian integer)
 136    AP-REP length (16 bits)
 137       length of AP-REP data, in bytes.  If the the length is zero, then
 138       the last field will contain a KRB-ERROR message instead of a KRB-
 139       PRIV message.
 140    AP-REP data, as described in RFC1510 (variable length)
 141       The AP-REP corresponding to the AP-REQ in the request packet.
 142    KRB-PRIV or KRB-ERROR message, as described in RFC1510 (variable
 143       length)
 144       If the AP-REP length is zero, then this field contains a KRB-ERROR
 145       message.  Otherwise, it contains a KRB-PRIV message.  This KRB-
 146       PRIV message must be generated using the subkey in the
 147       Authenticator in the AP-REQ data.
 148
 149       The user-data component of the KRB-PRIV message, or e-data
 150       component of the KRB-ERROR message, must consist of the following
 151       data:
 152
 153        0                   1                   2                   3
 154        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
 155       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 156       |          result code          |        result string          /
 157       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 158
 159       result code (16 bits)
 160          The result code must have one of the following values (big-
 161          endian integer):
 162          0x0000 if the request succeeds.  (This value is not permitted
 163             in a KRB-ERROR message.)
 164          0x0001 if the request fails due to being malformed
 165          0x0002 if the request fails due to a "hard" error processing
 166             the request (for example, there is a resource or other
 167             problem causing the request to fail)
 168          0x0003 if the request fails due to an error in authentication
 169             processing
 170          0x0004 if the request fails due to a "soft" error processing
 171             the request (for example, some policy or other similar
 172             consideration is causing the request to be rejected).
 173          0xFFFF if the request fails for some other reason.
 174          Although only four non-zero result codes are specified here,
 175          the client should accept any non-zero result code as indicating
 176          failure.
 177       result string (variable length)
 178          This field should contain information which the server thinks
 179          might be useful to the user.  No particular format is mandated,
 180          and the field may be omitted if the server does not wish to
 181          include it.  This field is analogous to the string which
 182          follows the numeric code in SMTP, FTP, and similar protocols.
 183
 184
 185
 186
 187
 188
 189 Horowitz                                                        [Page 3]
 190 \f
 191 Internet Draft      Kerberos Change Password Protocol        March, 1997
 192
 193
 194 Security Considerations
 195
 196    This document deals with changing passwords for Kerberos.  Because
 197    Kerberos is used for authentication and key distribution, it is
 198    important that this protocol use the highest level of security
 199    services available to a particular installation.  Mutual
 200    authentication is performed, so that the server knows the request is
 201    valid, and the client knows that the request has been received and
 202    processed by the server.
 203
 204    There are also security issues relating to dropped, stolen, or
 205    modified messages.  An attacker (or simply a lossy network) could
 206    cause either the request or reply to be dropped, or substitute a KRB-
 207    ERROR message in the reply.
 208
 209    If a reply is dropped, it is reasonable for the client to construct a
 210    new authenticator, re-encrypt the request, and retransmit.  If the
 211    request was lost, the server will treat this as a valid request, and
 212    all should work normally.  If the reply was lost, then the server
 213    should take care to notice that the request was a duplicate of the
 214    prior request, and indicate success without actually changing the
 215    password or any other information (such as modification timestamps).
 216
 217    If a success reply was replaced with an error reply, then one would
 218    expect that the user would attempt the operation again.  Again, the
 219    server should recognize the request as a duplicate and indicate
 220    success without changing the password.  If the user is required to
 221    provide the old password again, but the password was actually changed
 222    successfully, then some user confusion could result.  This is,
 223    unfortunately, impossible to prevent.
 224
 225
 226 References
 227
 228    [RFC1510] Kohl, J. and Neuman, C., "The Kerberos Network
 229       Authentication Service (V5)", RFC 1510, September 1993.
 230
 231
 232 Author's Address
 233
 234    Marc Horowitz
 235    Cygnus Solutions
 236    955 Massachusetts Avenue
 237    Cambridge, MA 02139
 238
 239    Phone: +1 617 354 7688
 240    Email: marc@cygnus.com
 241
 242
 243
 244
 245
 246
 247
 248
 249
 250
 251 Horowitz                                                        [Page 4]
 252 \f