crypto/heimdal-0.6.3/doc/standardisation/draft-ietf-cat-kerb-chg-password-02.txt

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