doc/specifications/draft-ietf-krb-wg-kerberos-set-passwd-01.txt

   1
   2 Kerberos Working Group                                  Nicolas Williams
   3 INTERNET-DRAFT                                          Sun Microsystems
   4 Category: Standards Track                               Jonathan Trostle
   5                                                            Cisco Systems
   6                                                               Mike Swift
   7                                                         University of WA
   8                                                              John Brezak
   9                                                                Microsoft
  10                                                             Bill Gossman
  11                                                            Cisco Systems
  12
  13
  14
  15                 Kerberos Set/Change Password: Version 2
  16               <draft-ietf-krb-wg-kerberos-set-passwd-01.txt>
  17
  18
  19
  20
  21 Status of this Memo
  22
  23    This document is an Internet-Draft and is in full conformance with
  24    all provisions of Section 10 of RFC2026 [RFC2026].
  25
  26    Internet-Drafts are working documents of the Internet Engineering
  27    Task Force (IETF), its areas, and its working groups.  Note that
  28    other groups may also distribute working documents as Internet-
  29    Drafts.
  30
  31    Internet-Drafts are draft documents valid for a maximum of six months
  32    and may be updated, replaced, or obsoleted by other documents at any
  33    time.  It is inappropriate to use Internet- Drafts as reference
  34    material or to cite them other than as "work in progress."
  35
  36    The list of current Internet-Drafts can be accessed at
  37    http://www.ietf.org/ietf/1id-abstracts.txt
  38
  39    The list of Internet-Draft Shadow Directories can be accessed at
  40    http://www.ietf.org/shadow.html.
  41
  42    This draft expires on December 31st, 2001. Please send comments to
  43    the authors.
  44
  45
  46 Copyright Notice
  47
  48    Copyright (C) The Internet Society (2003).  All Rights Reserved.
  49
  50 Abstract
  51
  52    This document specifies an extensible protocol for setting keys and
  53    changing the passwords of Kerberos V principals.
  54
  55
  56
  57 N. Williams et. al.                                             [Page 1]\f
  58
  59
  60 Table of Contents
  61
  62    1  Introduction
  63    2  The Protocol
  64    2.1  Transports
  65    2.2  Protocol Framing
  66    2.2.1  The protocol over UDP
  67    2.2.2  The protocol over TCP
  68    2.3  Protocol version negotiation
  69    2.3.1  Protocol major version negotiation
  70    2.3.2  Protocol minor version negotiation
  71    2.4  Use of Kerberos V
  72    2.5  Use of ASN.1
  73    2.6  Internationalization
  74    2.6.1  Normalization Forms for UTF-8 Strings
  75    2.6.2  Language Negotiation
  76    2.7  Protocol Extensibility
  77    2.8  Protocol Subsets
  78    3  Protocol Elements
  79    3.1  PDUs
  80    3.2  Operations
  81    3.2.1  Null
  82    3.2.2  Change Kerberos Password
  83    3.2.3  Set Kerberos Password
  84    3.2.4  Set Kerberos Keys
  85    3.2.5  Generate Kerberos Keys
  86    3.2.6  Get New Keys
  87    3.2.7  Commit New Keys
  88    3.2.8  Get Password Quality Policy
  89    3.2.9  Get Principal Aliases
  90    3.2.10  Get Realm's Supported Kerberos V Version and Features
  91    4  ASN.1 Module
  92    6  IANA Considerations
  93    7  Security Considerations
  94    8  Acknowledgements
  95    9  References
  96    9.1  Normative References
  97    9.2  Informative References
  98    10  Authors' Addresses
  99    11  Notes to the RFC Editor
 100
 101 Conventions used in this document
 102
 103    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 104    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
 105    document are to be interpreted as described in [RFC2119].
 106
 107 1  Introduction
 108
 109    Up to this point Kerberos V has lacked a single, standard protocol
 110    for changing passwords and keys.  While several vendor-specific
 111
 112 N. Williams et. al.                                             [Page 2]\f
 113
 114 DRAFT           Kerberos Set/Change Password v2         Expires April 2004
 115
 116    protocols exist for changing Kerberos passwords/keys, none are
 117    properly internationalized and all are incomplete in one respect or
 118    another and none are sufficiently extensible to cope with new
 119    features that may be added to Kerberos V at some future time.
 120
 121    This document defines a protocol that is somewhat backward-compatible
 122    with the "kpasswd" protocol, version 1 [KPASSWDv1] and a derivative
 123    defined in [RFC3244] that uses more or less the same protocol
 124    framing.
 125
 126    This new protocol is designed to be extensible and properly
 127    internationalized.
 128
 129 2  The Protocol
 130
 131    The structure of the protocol is quite similar to that of typical RPC
 132    protocols.  Each transaction consists of a data structure specific to
 133    an operation which is then wrapped in a data structure which is
 134    general to all operations of the protocol.  These data structures are
 135    defined with the Abstract Syntax Notation 1 (ASN.1) [X680] and they
 136    are encoded using the Distinguished Encoding Rules (DER) [X690].
 137
 138    The protocol data is wrapped in a KRB-PRIV, or, in some cases, a
 139    KRB-ERROR, and framed in a header that is backwards compatible with
 140    version 1 [KPASSWDv1] of this protocol and [RFC3244].
 141
 142    [Discussion:  Should the v1/rfc3244 framing and port numbers be
 143                  dropped?]
 144
 145 2.1  Transports
 146
 147    The service SHOULD accept requests on UDP port 464 and TCP port 464.
 148    This is the same port used by version 1 [KPASSWDv1] of this protocol,
 149    but version 2 is a completely different protocol sharing with
 150    [KPASSWDv1] and [RFC3244] only the outer framing.
 151
 152    [Discussion:  Should we remove UDP support?  I think so [Nico].]
 153
 154 2.2  Protocol Framing
 155
 156    For compatibility with the original Kerberos password changing
 157    protocol developed at MIT as well as RFC3244, the first 4 bytes of
 158    the message consist of a 2-byte network byte order message length,
 159    followed by a 2 byte network byte order protocol version number,
 160    followed by a 2 byte network byte order length for an optional
 161    AP-REQ, AP-REP or KRB-ERROR, followed by the same, if present,
 162    followed by a KRB-PRIV (optional in TCP) containing the actual
 163    protocol message encoded in DER [X690].
 164
 165    In the case of TCP there is an additional 4 byte network byte order
 166    length prepended to the frame described above as per-RFC3244.
 167
 168    The protocol version number MUST be set to 2 for this protocol.
 169
 170 N. Williams et. al.                                             [Page 3]\f
 171
 172 DRAFT           Kerberos Set/Change Password v2         Expires April 2004
 173
 174
 175    Bytes on the wire description of the framing:
 176
 177        0                   1                   2                   3
 178        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
 179       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 180       |         message length        |    protocol version number    |
 181       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 182       | AP-REQ length (0 if absent)   | AP-REQ data (if present)      |
 183       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 184       |                   KRB-PRIV message                            |
 185       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 186
 187    The same framing applies equally to requests and responses, but
 188    responses use AP-REP and/or KRB-ERROR instead of AP-REQ:
 189
 190        0                   1                   2                   3
 191        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
 192       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 193       |         message length        |    protocol version number    |
 194       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 195       | AP-REP length (0 if absent)   | AP-REP data (if present)      |
 196       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 197       |                   KRB-PRIV message                            |
 198       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 199
 200        0                   1                   2                   3
 201        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
 202       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 203       |         message length        |    protocol version number    |
 204       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 205       | KRB-ERROR length (0 if absent)| KRB-ERROR data (if present)   |
 206       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 207
 208    For the UDP case the AP-REQ/AP-REP/KRB-ERROR MUST always be included.
 209
 210    Note that this framing is used by version 1 [KPASSWDv1] and version
 211    0xff80 [RFC3244], though the latter does not use the framing when
 212    responding with KRB-ERROR messages.
 213
 214    Version 0xff80 servers may respond to requests with an un-framed
 215    KRB-ERROR and e-data set as per-RFC3244 [RFC3244], otherwise clients
 216    and server MUST always use this framing.  See section 2.3.
 217
 218 2.2.1  The protocol over UDP
 219
 220    In the UDP case there is a single message from the client and a
 221    single response from the server with no state kept between requests,
 222    and each request MUST include a Kerberos AP-REQ and a KRB-PRIV and
 223    each response MUST carry an AP-REP, or KRB-ERROR and a KRB-PRIV.
 224
 225    Both the client and server MUST destroy the sub-session key, if any,
 226    resulting from the AP exchange after each operation.
 227
 228 N. Williams et. al.                                             [Page 4]\f
 229
 230 DRAFT           Kerberos Set/Change Password v2         Expires April 2004
 231
 232
 233    UDP clients MUST not request the use of sequence numbers, otherwise
 234    they cannot generate the KRB-PRIV prior to receiving the AP-REP.
 235
 236 2.2.2  The protocol over TCP
 237
 238    The initial message from the client MUST carry an AP-REQ and the
 239    response to any request bearing an AP-REQ MUST carry an AP-REP.
 240
 241    Subsequent messages MAY involve Kerberos V AP exchanges, but
 242    generally the client SHOULD NOT initiate a new AP exchange except
 243    when it desires to authenticate as a different principal, when the
 244    ticket last used for authentication expires or when the server
 245    responds with an error indicating that the client must
 246    re-authenticate.
 247
 248    KRB-PRIV messages should use the session or sub-session key
 249    established in the most recent AP exchange performed over the same
 250    TCP connection.
 251
 252    After each new AP exchange the client and server MUST destroy the
 253    sub-session key, if any, resulting from the previous AP exchange.
 254
 255    Servers MAY close open sessions at any time.
 256
 257 2.3  Protocol version negotiation
 258
 259    There are several major versions of this protocol.  Version 2 also
 260    introduces a notion of protocol minor versions for use in negotiating
 261    protocol extensions.  As of this time only one minor version is
 262    defined for major version 2: minor version 0, defined herein.
 263
 264 2.3.1  Protocol major version negotiation
 265
 266    Version 2 clients that also support other versions, such as
 267    [KPASSWDv1] or [RFC3244] SHOULD attempt to use version 2 of the
 268    protocol first and then MAY try other versions if the server responds
 269    with either a message framed as described in section 2.2 but with a
 270    protocol version number other than 2, or a KRB-ERROR with an error
 271    code of KRB5_KPASSWD_BAD_VERSION in the e-data field.
 272
 273    Note that some version 1 servers return a KRB-ERROR indicating that
 274    versions other than 1 of the change password protocol are not
 275    supported rather than an AP-REP and a KRB-PRIV containing the error
 276    data.
 277
 278    Also note that some [RFC3244] implementations do not return any
 279    responses to requests for protocol versions other than 0xff80, and in
 280    the TCP case close the TCP connection.
 281
 282    As a result change password protocol major version negotiation is
 283    subject to downgrade attacks.  Therefore major version negotiation is
 284    NOT RECOMMENDED.
 285
 286 N. Williams et. al.                                             [Page 5]\f
 287
 288 DRAFT           Kerberos Set/Change Password v2         Expires April 2004
 289
 290
 291    Version 2 servers SHOULD respond to non-v2 requests using whatever
 292    response is appropriate for the versions used by the clients, but if
 293    a server does not do this or know how to do this then it MUST respond
 294    with an error framed as in section 2.2, using an AP-REP and KRB-PRIV
 295    if the client's AP-REQ can be accepted, or a KRB-ERROR (framed)
 296    otherwise and using a ProtocolErrorCode value of
 297    unsupported-major-version or .
 298
 299 2.3.2  Protocol minor version negotiation
 300
 301    Version 2 clients are free to use whatever protocol minor version and
 302    message extensions are available to them in their initial messages to
 303    version 2 servers, provided that the minor versions (other than 0)
 304    have been defined through IETF documents and registered with the
 305    IANA.
 306
 307    Version 2 servers MUST answer with the highest protocol minor version
 308    number supported by the server and the client.
 309
 310    Version 2 clients MUST use the protocol minor version used in a
 311    server's reply for any subsequent messages in the same TCP session.
 312
 313    See section 2.7 for further description of the protocol's
 314    extensibility and its relation to protocol minor versions and the
 315    negotiation thereof.
 316
 317 2.4  Use of Kerberos V
 318
 319    This protocol makes use of messages defined in [RFC1510] and
 320    [clarifications].  Specifically, AP-REQ, AP-REP, KRB-ERROR and
 321    KRB-PRIV.
 322
 323    All operations are to be performed by the server on behalf of the
 324    client principal.
 325
 326    Clients SHOULD use "kadmin/setpw" as the principal name of the server
 327    for all requests except when changing the client principal's own
 328    password, when expired, for which they should use "kadmin/changepw".
 329
 330    The client MUST request mutual authentication and the client MUST NOT
 331    request the use of sequence numbers when using the protocol over
 332    UDP, but it MUST request the use of sequence numbers when running
 333    over TCP.
 334
 335    Clients SHOULD use INITIAL tickets for change password requests.
 336    Servers MAY force the use of INITIAL tickets for any request - see
 337    section 3.2.
 338
 339 2.5  Use of ASN.1
 340
 341    This protocol's messages are defined in ASN.1, using only features
 342    from [X680].  All ASN.1 types defined herein are to be encoded in
 343
 344 N. Williams et. al.                                             [Page 6]\f
 345
 346 DRAFT           Kerberos Set/Change Password v2         Expires April 2004
 347
 348    DER [X690].  A complete ASN.1 module is given in section 4.  The
 349    ASN.1 tagging environment for this module is EXPLICIT.
 350
 351    The DER encoding of the ASN.1 PDUs are exchanged wrapped in a
 352    KRB-PRIV as described above and/or as e-data in KRB-ERROR messages.
 353
 354 2.6  Internationalization
 355
 356    This protocol's request PDU carries an optional field indicating the
 357    languages spoken by the client user; the client SHOULD send its list
 358    of spoken languages to the server (once per-TCP session).  All
 359    strings in the protocol are UTF-8 strings.
 360
 361    The server SHOULD localize all strings intended for users to a
 362    language in common with the languages spoken by the client user.
 363
 364    For TCP sessions servers MUST cache the optional language tag lists
 365    from prior requests for use with subsequent requests that exclude the
 366    language tag list.  Clients MAY expect such server behaviour and send
 367    the language tag lists only when they change or even just once
 368    per-TCP session.  Clients SHOULD send the server the language tag
 369    list at least once.
 370
 371    Kerberos principal and realm names used in this protocol MUST be
 372    constrained as per the specification of the version of Kerberos V
 373    used by the client.
 374
 375 2.6.1  Normalization Forms for UTF-8 Strings
 376
 377    No normalization form is required for string types other than
 378    for PrincipalName and Realm, which two types are constrained by the
 379    specification of the version of Kerberos V used by the client, and
 380    the password fields in the change password operation, which MUST be
 381    normalized according to [k5stringprep].
 382
 383 2.6.2  Language Negotiation
 384
 385    The server MUST pick a language from the client's input list or
 386    the default language tag (see [RFC3066]) for text in its responses
 387    which is meant for the user to read.
 388
 389    The server SHOULD use a language selection algorithm such that
 390    consideration is first given to exact matches between the client's
 391    spoken languages and the server's available locales, followed by
 392    "fuzzy" matches where only the first sub-tags of the client's
 393    language tag list are used for matching against the servers available
 394    locales.
 395
 396    When the server has a message catalog for one of the client's spoken
 397    languages the server SHOULD localize any text strings intended for
 398    users to read.
 399
 400 2.7  Protocol Extensibility
 401
 402 N. Williams et. al.                                             [Page 7]\f
 403
 404 DRAFT           Kerberos Set/Change Password v2         Expires April 2004
 405
 406
 407    The protocol is defined in ASN.1 and uses extensibility markers
 408    throughout.  As such, the module presented herein can be extended
 409    within the framework of [X680].
 410
 411    Typed holes are not used in this protocol as it is very simple and
 412    does not require the ability to deal with abstract data types defined
 413    in different layers.  For this reason, the only way to extend this
 414    protocol is by extending the ASN.1 module within the framework of the
 415    IETF; all future extensions to this protocol have to be defined in
 416    IETF documents unless otherwise specified in a future IETF revision
 417    of this protocol.
 418
 419    A protocol minor version number is used to negotiate use of
 420    extensions.  See section 2.3.2 for the minor version negotiation.
 421
 422    Message extensions are to be closely tied to protocol minor numbers.
 423
 424    Clients MAY use any protocol minor version that they support in
 425    initial requests, and MUST use the protocol minor version indicated
 426    in the server's initial reply in any subsequent requests in the same
 427    TCP session.
 428
 429    Servers SHOULD ignore additions to the ASN.1 types, in initial
 430    requests, where the syntax allows them that they do not understand,
 431    except for extensions to the "Op-req" type, which MUST result in an
 432    error; servers MAY respond with an error (ProtocolErrorCode value of
 433    unsupported-minor-version) to clients that use minor versions
 434    unsupported by the server in their initial requests.
 435
 436    Servers MUST select the highest minor version in common with their
 437    clients for use in replies.
 438
 439 2.8  Protocol Subsets
 440
 441    The structure of the protocol is such that the ASN.1 syntaxes for the
 442    various operations supported by the protocol are independent of the
 443    each other.  Client and server mplementations MAY implement subsets
 444    of the overall protocol by removing some alternatives to the Op-req,
 445    Op-rep and Op-err CHOICEs from the ASN.1 module given in section 4.
 446
 447    For example, it should be possible to have a password-change only
 448    client that cannot set principal's keys - and vice versa.
 449
 450 3  Protocol Elements
 451
 452    The protocol as defined herein supports the following operations
 453    relating to the management of Kerberos principal's passwords or keys:
 454
 455      - change password
 456      - set password (administrative)
 457      - set new keys
 458      - generate new keys
 459
 460 N. Williams et. al.                                             [Page 8]\f
 461
 462 DRAFT           Kerberos Set/Change Password v2         Expires April 2004
 463
 464      - get new, un-committed keys
 465      - commit new keys
 466      - get password policy name and/or description of principal
 467      - list aliases of a principal
 468      - list enctypes and version of Kerberos V supported by realm
 469
 470    These operations are needed to support Kerberos V interoperability
 471    between clients and KDCs of different implementation origins.
 472
 473    The operation for retrieving a list of aliases of a principal is
 474    needed where KDCs implement aliasing of principal names and allows
 475    clients to properly setup their "keytabs" when principal aliasing is
 476    in use.
 477
 478    Operations such as creation or deletion of principals are outside the
 479    scope of this document, and should be performed via other means, such
 480    as through directories or other Kerberos administration protocols.
 481
 482    The individual operations are described in section 3.2.
 483
 484 3.1  PDUs
 485
 486    The types "Request," "Response" and "Error-Response" are the ASN.1
 487    module's PDUs.
 488
 489    The "Request" and "Response" PDUs are always to be sent wrapped in
 490    KRB-PRIV messages, except for the "Error-Response" PDU which MUST be
 491    sent as KRB-ERROR e-data (see section 2.4.1) when AP exchanges fail,
 492    otherwise it MUST be sent wrapped in a KRB-PRIV.
 493
 494    The ASN.1 syntax for the PDUs is given in section 4.
 495
 496    Note that the first field of each PDU is the major version of the
 497    protocol, defaulted to 2, meaning that it is never included in
 498    version 2 exchanges.  Similarly, the second field of each PDU is the
 499    minor version, defaulted to 0.
 500
 501    The request, responses and error PDUs consist of an outer structure
 502    ("Request," "Response" and "Error-Response") containing fields common
 503    to all requests/responses, and an inner structure for fields that are
 504    specific to each operation's requests/responses.  The inner structure
 505    is optional in the case of the Error-Response PDU and need not be
 506    included when generic errors occur for which there is a suitable
 507    ProtocolErrorCode.
 508
 509    Specifically, the outer Request structure has a field for passing a
 510    client user's spoken (read) languages to the server.  It also has two
 511    optional fields for identifying the requested operation's target
 512    principal's name and realm (if not sent then the server MUST use the
 513    client principal name and realm from the AP exchange as the target).
 514
 515    The Response and Error PDUs' outer structures include a field
 516    indicating the language that the server has chosen for localization
 517
 518 N. Williams et. al.                                             [Page 9]\f
 519
 520 DRAFT           Kerberos Set/Change Password v2         Expires April 2004
 521
 522    of text intended to be displayed to users; this field is defaulted
 523    to "i-default".  This language tag applies to all UTF8 strings
 524    in the inner structure (Op-rep and Op-err) that are meant to be
 525    displayed to users.
 526
 527    The protocol error codes are:
 528
 529       - proto-generic-error
 530
 531         An operation-specific error ocurred, see the inner Op-error.
 532
 533       - proto-format-error
 534       - proto-unsupported-major-version
 535       - proto-unsupported-minor-version
 536       - proto-unsupported-operation
 537
 538       - proto-wrong-service-principal
 539
 540         Use kadmin/setpw for the server's principal name.
 541
 542       - proto-re-authentication-required
 543
 544         The server demands that the client re-authenticate through a new
 545         AP exchange.
 546
 547       - proto-initial-ticket-required
 548
 549         Use of an INITIAL ticket is required for the requested
 550         operation.
 551
 552       - proto-client-and-target-realm-mismatch
 553
 554         The server requires that the client's principal name and the
 555         target principal of the operation share the same realm name.
 556
 557       - proto-target-principal-unknown
 558       - proto-authorization-failed
 559
 560 3.2  Operations
 561
 562    This section describes the semantics of each operation request and
 563    response defined in the ASN.1 module in section 4.
 564
 565 3.2.1  Null
 566
 567    NAME
 568
 569       null - Null or "ping" operation
 570
 571    DESCRIPTION
 572
 573       The null request is intended for use with TCP; its purpose is
 574       similar to RPC null procedures and is akin to a "ping" operation.
 575
 576 N. Williams et. al.                                             [Page 10]\f
 577
 578 DRAFT           Kerberos Set/Change Password v2         Expires April 2004
 579
 580
 581    ERRORS
 582
 583       None.
 584
 585 3.2.2  Change Kerberos Password
 586
 587    NAME
 588
 589       change-pw - Change password operation
 590
 591    SYNOPSIS
 592
 593       Req-change-pw(old-pw, [new-pw], [etypes]) ->
 594          Rep-change-pw([info-text], [new-pw], [etypes]) |
 595          Err-change-pw([help-text], error code, [error info])
 596
 597    DESCRIPTION
 598
 599       Change a principal's password.
 600
 601       The change password request has one required field and three
 602       optional fields: "old-pw" (required), "new-pw" and "etypes",
 603       corresponding to the target principal's old password, new password
 604       and desired enctypes for the new long-term keys.
 605
 606       The server MUST validate the old password and MUST check the
 607       quality of the new password, if sent, according the password
 608       quality policy associated with the target principal.
 609
 610       The server SHOULD require that the old password be sent or that
 611       the client's ticket be INITIAL, or both, when the client principal
 612       and the target principal are the same.
 613
 614       A client MAY request that the server generate a new password by
 615       excluding the new password from its request, in which case the
 616       server MUST either generate a new password or respond with an
 617       error indicating that it does not support this feature.
 618
 619       Server-generated passwords MUST meet the target principal's
 620       password quality policy.  It is RECOMMENDED that server-generated
 621       passwords be user-friendly, that is, memorable and that the target
 622       principal's preferred languages be taken into account by the
 623       password generation alogrithm used by the server.
 624
 625    RETURN
 626
 627       Upon successful password changes the server responds with a
 628       Rep-change-pw.  The fields of Rep-change-pw are all optional and
 629       include:
 630
 631          - 'info-text' which the server can use to send a message to the
 632            user such as "Your new password will expire in 90 days," for
 633
 634 N. Williams et. al.                                             [Page 11]\f
 635
 636 DRAFT           Kerberos Set/Change Password v2         Expires April 2004
 637
 638            example.
 639
 640          - 'new-pw' which the server MUST include if the client
 641            requested that the server generate a new password; generated
 642            passwords MUST pass the target principal's password quality
 643            policy.
 644
 645          - 'etypes' which the server MAY include to indicate which types
 646            of long-term keys it created for the target principal and
 647            which the server MUST include if the client specified a set
 648            of enctypes in its request.
 649
 650    ERRORS
 651
 652       The server may respond to change password requests with protocol
 653       or operation errors.  See section 3.1 for a description of
 654       protocol error codes.
 655
 656       All operation errors include an optional 'help-text' field by
 657       which the server can describe the error in a human-readable,
 658       localizaed string.
 659
 660       Change password error codes include:
 661
 662          - generic-error
 663
 664          - old-pw-incorrect
 665
 666          - wont-generate-new-pw
 667
 668            The server will not generate a new password for this
 669            principal or does not support password generation in general.
 670
 671          - new-pw-rejected-generic
 672
 673            The client's proposed new password failed the target
 674            principal's password quality policy.
 675
 676            The server MUST include a description of the password quality
 677            policy or aspect of it that the client's proposed new
 678            password failed to meet.
 679
 680            The server MAY generate and send a new password that the
 681            client can then use as a new password and which is guaranteed
 682            to pass the target principal's current password quality
 683            policy.
 684
 685          - etype-not-supported
 686
 687            The client requested an enctype that the KDC does not
 688            support.
 689
 690 3.2.3  Set Kerberos Password
 691
 692 N. Williams et. al.                                             [Page 12]\f
 693
 694 DRAFT           Kerberos Set/Change Password v2         Expires April 2004
 695
 696
 697    NAME
 698
 699       set-pw - Set password operation
 700
 701    SYNOPSIS
 702
 703       Req-set-pw([languages], [new-pw], [etypes]) ->
 704          Rep-set-pw([info-text], [new-pw], [etypes]) |
 705          Err-set-pw([help-text], error code, [error info])
 706
 707    DESCRIPTION
 708
 709       Administratively set a principal's password.
 710
 711       The change password request has three optional fields:
 712       "languages", "new-pw" and "etypes", corresponding to the target
 713       principal's preferred languages, new password and desired enctypes
 714       for the new long-term keys.
 715
 716       The server MUST check the quality of the new password, if sent,
 717       according the password quality policy associated with the target
 718       principal.
 719
 720       The server SHOULD require that the client use the change-pw
 721       operation instead of set-pw when the client principal and the
 722       target principal are the same.
 723
 724       A client MAY request that the server generate a new password by
 725       excluding the new password from its request, in which case the
 726       server MUST either generate a new password or respond with an
 727       error indicating that it does not support this feature.
 728
 729       Server-generated passwords MUST meet the target principal's
 730       password quality policy.  It is RECOMMENDED that server-generated
 731       passwords be user-friendly, that is, memorable and that the target
 732       principal's preferred languages be taken into account by the
 733       password generation alogrithm used by the server.
 734
 735    RETURN
 736
 737       Upon successful password changes the server responds with a
 738       Rep-change-pw.  The fields of Rep-change-pw are all optional and
 739       include:
 740
 741          - 'info-text' which the server can use to send a message to the
 742            user such as "Your new password will expire in 90 days," for
 743            example.
 744
 745          - 'new-pw' which the server MUST include if the client
 746            requested that the server generate a new password; generated
 747            passwords MUST pass the target principal's password quality
 748            policy.
 749
 750 N. Williams et. al.                                             [Page 13]\f
 751
 752 DRAFT           Kerberos Set/Change Password v2         Expires April 2004
 753
 754
 755          - 'etypes' which the server MAY include to indicate which types
 756            of long-term keys it created for the target principal and
 757            which the server MUST include if the client specified a set
 758            of enctypes in its request.
 759
 760    ERRORS
 761
 762       The server may respond to change password requests with protocol
 763       or operation errors.  See section XYZ for a description of
 764       protocol error codes.
 765
 766       All operation errors include an optional 'help-text' field by
 767       which the server can describe the error in a human-readable,
 768       localizaed string.
 769
 770       Change password error codes include:
 771
 772          - generic-error
 773
 774          - use-change-pw
 775
 776            The server demands that the client use the change-pw
 777            operation for the target principal of the set-pw request.
 778
 779          - wont-generate-new-pw
 780
 781            The server will not generate a new password for this
 782            principal or does not support password generation in general.
 783
 784          - new-pw-rejected-generic
 785
 786            The client's proposed new password failed the target
 787            principal's password quality policy.
 788
 789            The server MUST include a description of the password quality
 790            policy or aspect of it that the client's proposed new
 791            password failed to meet.
 792
 793            The server MAY generate and send a new password that the
 794            client can then use as a new password and which is guaranteed
 795            to pass the target principal's current password quality
 796            policy.
 797
 798          - etype-not-supported
 799
 800            The client requested an enctype that the KDC does not
 801            support.
 802
 803 3.2.4  Set Kerberos Keys
 804
 805    NAME
 806
 807
 808 N. Williams et. al.                                             [Page 14]\f
 809
 810 DRAFT           Kerberos Set/Change Password v2         Expires April 2004
 811
 812       set-keys
 813
 814    SYNOPSIS
 815
 816       Req-set-keys(new-keys, commit?, [isupport]) ->
 817          Rep-set-keys([info-text], kvno, aliases, [isupport])
 818
 819    DESCRIPTION
 820
 821       The set-keys request consists of two required fields and one
 822       optional field: "new-keys", "commit" (a boolean field - see below)
 823       and "isupport", an optional field for indicating to the KDC what
 824       Kerberos V features are supported by the target principal.
 825
 826       When "commit" is true the KDC makes the new keys available for
 827       issueing tickets encrypted in them immediately.  Otherwise the
 828       client MUST follow up with a commit-keys request to make the keys
 829       available.
 830
 831       If a principal has keys are awaiting commitment when a new
 832       set-keys request for that principal s made then the KDC MUST
 833       overwrite the deferred keys.
 834
 835    RETURN
 836
 837       For successful set-keys operations the server returns:
 838
 839          - Informational text, optional.
 840
 841          - The new kvno for the target principal.
 842
 843          - A list of aliases of the target principal known to the KDC
 844            (optional).
 845
 846          - The set of Kerberos V features supported by the KDC
 847            (optional).
 848
 849    ERRORS
 850
 851       The server may respond with the following errors:
 852
 853          - generic
 854          - deferred-commit-no-support
 855          - etype-no-support
 856
 857 3.2.5  Generate Kerberos Keys
 858
 859    NAME
 860
 861       gen-keys
 862
 863    SYNOPSIS
 864
 865
 866 N. Williams et. al.                                             [Page 15]\f
 867
 868 DRAFT           Kerberos Set/Change Password v2         Expires April 2004
 869
 870       Req-gen-keys(etypes, [entropy], commit?, [isupport]) ->
 871          Rep-set-keys([info-text], key, kvno, aliases, [isupport])
 872
 873    DESCRIPTION
 874
 875       The gen-keys is similar to the set-keys request (see section
 876       3.2.4) but differs in that the server generates keys of
 877       client-requested enctypes, rather than the client providing
 878       specific keys.
 879
 880       The gen-keys request consists of two required fields and two
 881       optional fields: "etypes" (the enctypes of the new keys),
 882       "entropy", "commit" and "isupport" (see section 3.2.4).
 883
 884       If a principal has keys are awaiting commitment when a new
 885       set-keys request for that principal s made then the KDC MUST
 886       overwrite the deferred keys.
 887
 888    RETURN
 889
 890       For successful set-keys operations the server returns:
 891
 892          - Informational text, optional.
 893
 894          - The new kvno for the target principal.
 895
 896          - The new key (only one is needed).
 897
 898          - A list of aliases of the target principal known to the KDC
 899            (optional).
 900
 901          - The set of Kerberos V features supported by the KDC
 902            (optional).
 903
 904    ERRORS
 905
 906       The server may respond with the following errors:
 907
 908          - generic
 909          - deferred-commit-no-support
 910          - etype-no-support
 911
 912 3.2.6  Get New Keys
 913
 914    NAME
 915
 916       get-keys
 917
 918    SYNOPSIS
 919
 920       Req-get-keys(kvno) ->
 921          Rep-get-keys([info-text], keys, aliases, [isupport]) |
 922          Err-get-keys([help-text], error code, [error info])
 923
 924 N. Williams et. al.                                             [Page 16]\f
 925
 926 DRAFT           Kerberos Set/Change Password v2         Expires April 2004
 927
 928
 929    DESCRIPTION
 930
 931       This request allows a client to get the keys set or generated in a
 932       previous set-keys or gen-keys request with deferred commitment..
 933
 934    RETURN
 935
 936       If the target principal and kvno correspond to uncommitted keys
 937       the server MUST respond with the actual keys that would be set by
 938       a subsequent commit-keys request.  Otherwise the server MUST
 939       respond with an error (meaning that this operation cannot be used
 940       to extract keys from the KDC that may be in use).
 941
 942    ERRORS
 943
 944          - generic
 945          - kvno-committed
 946          - no-such-kvno
 947
 948 3.2.7  Commit New Keys
 949
 950    NAME
 951
 952       commit-keys
 953
 954    SYNOPSIS
 955
 956       Req-commit-keys(kvno) ->
 957          Rep-commit-keys() |
 958          Err-commit-keys([help-text], error code, [error info])
 959
 960    DESCRIPTION
 961
 962       The commit-keys operation allows a client to bring a principal's
 963       new keys into use at the KDC.
 964
 965       Clients SHOULD make a commit-keys request corresponding to a
 966       deferred commitment set-keys/gen-keys operation as soon as the
 967       local key database for the target principal is updated.
 968
 969       The target principal name and the kvno MUST match those from a
 970       prior set-keys or gen-keys operation.
 971
 972       Servers MAY expire delayed key commitments at will.  Servers
 973       SHOULD expire uncommitted new keys after a reasonable amount of
 974       time (600 seconds is RECOMMENDED).
 975
 976       Servers MUST respond to new set-keys requests for principals with
 977       pending, uncommitted new keys by expiring the uncommitted new keys
 978       and proceeding as if there had been no expired new keys.
 979
 980    ERRORS
 981
 982 N. Williams et. al.                                             [Page 17]\f
 983
 984 DRAFT           Kerberos Set/Change Password v2         Expires April 2004
 985
 986
 987       - generic
 988       - new-keys-conflict (A set-keys or gen-keys request succeeded
 989                            subsequent to the request that matches this
 990                            {principal, kvno} tuple.)
 991
 992 3.2.8  Get Password Quality Policy
 993
 994    NAME
 995
 996       get-pw-policy
 997
 998    SYNOPSIS
 999
1000       Req-get-pw-policy() ->
1001          Rep-get-pw-policy([policy name], [policy description])
1002
1003    DESCRIPTION
1004
1005       Returns a description of the target principal's associated
1006       password quality policy, if any, as a list of localized
1007       UTF8String values.
1008
1009       Clients can use this operation in conjunction with the change-pw
1010       operation to obtain text that can be displayed to the user before
1011       the user actually enters a new password.
1012
1013       It is common for sites to set policies with respect to password
1014       quality.  It is beyond the scope of this document to describe such
1015       policies.  Management of password quality policies' actual content
1016       is also beyond the scope of this protocol.
1017
1018    ERRORS
1019
1020       No operation errors are defined.
1021
1022
1023 3.2.9  Get Principal Aliases
1024
1025    NAME
1026
1027       get-print-aliases
1028
1029    SYNOPSIS
1030
1031       Req-get-princ-aliases() ->
1032          Rep-get-princ-aliases(aliases)
1033
1034    DESCRIPTION
1035
1036       Returns a list of aliases of the target principal.
1037
1038    ERRORS
1039
1040 N. Williams et. al.                                             [Page 18]\f
1041
1042 DRAFT           Kerberos Set/Change Password v2         Expires April 2004
1043
1044
1045       No operation-specific errors.
1046
1047 3.2.10  Get Realm's Supported Kerberos V Version and Features
1048
1049    NAME
1050
1051       get-realm-krb5-support
1052
1053    SYNOPSIS
1054
1055       Req-get-realm-krb5-support() ->
1056          Rep-get-realm-krb5-support(isupport)
1057
1058    DESCRIPTION
1059
1060       Returns set of Kerberos V features support by the target
1061       principal's realm's KDCs.
1062
1063    ERRORS
1064
1065       No operation-specific errors.
1066
1067 3.3  Principal Aliases
1068
1069    Applications that use Kerberos often have to derive acceptor
1070    principal names from hostnames entered by users.  Such hostnames may
1071    be aliases, they may be fully qualified, partially qualified or not
1072    qualified at all.  Some implementations have resorted to deriving
1073    principal names from such hostnames by utilizing the names services
1074    to canonicalize the hostname first; such practices are not secure
1075    unless the name service are secure, which often aren't.
1076
1077    One method for securely deriving principal names from hostnames is to
1078    alias principals at the KDC such that the KDC will issue tickets for
1079    principal names which are aliases of others.  It is helpful for
1080    principals to know what are their aliases as known by the KDCs.
1081
1082    Note that changing a principal's aliases is out of scope for this
1083    protocol.
1084
1085 3.4  Kerberos V Feature Negotiation
1086
1087    ...
1088
1089 4  ASN.1 Module
1090
1091    DEFINITIONS EXPLICIT TAGS ::= BEGIN
1092
1093    -- From [clarifications] with modifications
1094    PrincipalName            ::= SEQUENCE {
1095         name-string [1] SEQUENCE OF UTF8String
1096    }
1097
1098 N. Williams et. al.                                             [Page 19]\f
1099
1100 DRAFT           Kerberos Set/Change Password v2         Expires April 2004
1101
1102    Realm                    ::= UTF8String
1103
1104    -- NOTE WELL: Principal and realm names MUST be constrained by the
1105    --            specification of the version of Kerberos V used by the
1106    --            client.
1107    --
1108    -- [Perhaps PrincipalName should be a SEQUENCE of an optional name
1109    --  type and a UTF8String, for simplicity.]
1110
1111    -- From [clarifications]
1112    Int32            ::= INTEGER (-2147483648..2147483647)
1113    UInt32           ::= INTEGER (0..4294967295)
1114
1115    -- Based on [clarifications]
1116    Etype            ::= Int32   -- as in [clarifications]
1117    Key      ::= SEQUENCE {
1118         enc-type        [0] Etype,      -- from Kerberos
1119         key             [1] OCTET STRING,
1120         ...
1121    }
1122
1123    Language-Tag     ::= UTF8String -- Constrained by [RFC3066]
1124
1125    -- Empty, extensible SEQUENCEs are legal ASN.1
1126    Extensible-NULL      ::= SEQUENCE {
1127         ...
1128    }
1129
1130    -- Kerberos clients negotiate some parameters relating to their peers
1131    -- indirectly through the KDC.  Today this is true of ticket session
1132    -- key enctypes, but in the future this indirect negotiation may also
1133    -- occur with respect to the minor version of Kerberos V to be used
1134    -- between clients and servers.  Additionally, KDCs may need to know
1135    -- what authorization-data types are supported by service principals,
1136    -- both, for compatibility with legacy software and for optimization.
1137    --
1138    -- Thesefore it is important for KDCs to know what features of
1139    -- Kerberos V each service principal supports.
1140    --
1141    -- In version 2.0 of this protocol the clients and servers may notify
1142    -- each other of their support for:
1143    --
1144    --  - KerberosV minor version (rfc1510 -> 0, clarifications ->1)
1145    --  - enctypes
1146    --  - authorization data types
1147    --  - transited encoding data types
1148    --
1149    -- All authorization-data types defined in [clarifications] are
1150    -- assumed to be supported if the minor version is 1 and do not need
1151    -- to be included in the ad-type list.
1152    --
1153    -- Int32 is used for enctype and transited encoding data type
1154    -- identifiers.
1155
1156 N. Williams et. al.                                             [Page 20]\f
1157
1158 DRAFT           Kerberos Set/Change Password v2         Expires April 2004
1159
1160    --
1161    -- An extensible CHOICE of Int32 is used for authorization data
1162    -- types.
1163
1164    KerberosV-TR-ID              ::= Int32
1165
1166    KerberosV-AD-ID              ::= CHOICE {
1167         ad-int          [0] Int32,
1168         ...
1169    }
1170
1171    KerberosVSupportNego ::= SEQUENCE {
1172         version         [0] ENUM {
1173                 rfc1510,
1174                 clarifications, -- replace with assigned RFC number
1175                 -- add extensions
1176                 ...
1177         }
1178         enc-types       [1] SEQUENCE OF Etype,
1179         ad-types        [2] SEQUENCE OF KerberosV-AD-ID OPTIONAL,
1180                                     -- authorization data types
1181         tr-enc-types    [3] SEQUENCE OF KerberosV-TR-ID OPTIONAL,
1182                                     -- transited encoding types
1183         ...
1184         -- A future extended Kerberos V may have optional features, in
1185         -- which case there might be an additional choice here, not of
1186         -- NULL, but of some other, possibly structured, type.
1187    }
1188
1189    Request              ::= [APPLICATION 0] SEQUENCE {
1190         pvno-minor      [0] INTEGER DEFAULT 0,
1191         languages       [1] SEQUENCE OF Language-Tag OPTIONAL,
1192                 -- Should be defaulted to the SEQUENCE of "i-default"
1193         targ-name       [2] PrincipalName OPTIONAL,
1194         targ-realm      [3] Realm OPTIONAL,
1195                 -- If targ-name/realm are missing then the request
1196                 -- applies to the principal of the client
1197         operation       [4] Op-req,
1198         ...
1199    }
1200
1201    Response     ::= [APPLICATION 1] SEQUENCE {
1202         pvno-minor      [0] INTEGER DEFAULT 0,
1203         language        [1] Language-Tag DEFAULT "i-default",
1204         result          [2] Op-rep,
1205         ...
1206    }
1207
1208    Error-Response       ::= [APPLICATION 2] SEQUENCE {
1209         pvno-minor      [0] INTEGER DEFAULT 0,
1210         language        [1] Language-Tag DEFAULT "i-default",
1211         error-code      [2] ProtocolErrorCode,
1212         help-text       [3] UTF8String OPTIONAL,
1213
1214 N. Williams et. al.                                             [Page 21]\f
1215
1216 DRAFT           Kerberos Set/Change Password v2         Expires April 2004
1217
1218         op-error        [4] Op-err OPTIONAL,
1219         ...
1220    }
1221
1222    Op-req               ::= CHOICE {
1223         null                    [0] Req-null,
1224         change-pw               [1] Req-change-pw,
1225         set-pw                  [2] Req-set-pw,
1226         set-keys                [3] Req-set-keys,
1227         gen-keys                [4] Req-gen-keys,
1228         get-keys                [5] Req-get-keys,
1229         commit-keys             [6] Req-commit-keys,
1230         get-pw-policy           [7] Req-get-pw-policy,
1231         get-princ-aliases       [8] Req-get-princ-aliases,
1232         get-realm-krb5-support  [9] Req-get-realm-krb5-support,
1233         ...
1234    }
1235
1236    Op-rep               ::= CHOICE {
1237         null                    [0] Rep-null,
1238         change-pw               [1] Rep-change-pw,
1239         set-pw                  [2] Rep-set-pw,
1240         set-keys                [3] Rep-set-keys,
1241         gen-keys                [4] Req-gen-keys,
1242         get-keys                [5] Req-get-keys,
1243         commit-keys             [6] Rep-commit-keys,
1244         get-pw-policy           [7] Rep-get-pw-policy,
1245         get-princ-aliases       [8] Rep-get-princ-aliases,
1246         get-realm-krb5-support  [9] Rep-get-realm-krb5-support,
1247         ...
1248    }
1249
1250    Op-err       ::= CHOICE {
1251         null                    [0] Err-null,
1252         change-pw               [1] Err-change-pw,
1253         set-pw                  [2] Err-set-pw,
1254         set-keys                [3] Err-set-keys,
1255         gen-keys                [4] Err-gen-keys,
1256         get-keys                [5] Err-get-keys,
1257         commit-keys             [6] Err-commit-keys,
1258         get-pw-policy           [7] Err-get-pw-policy,
1259         get-princ-aliases       [8] Err-get-princ-aliases,
1260         get-realm-krb5-support  [9] Err-get-realm-krb5-support,
1261         ...
1262    }
1263
1264    ProtocolErrorCode        ::= ENUM {
1265         proto-format-error,
1266         proto-unsupported-major-version,
1267         proto-unsupported-minor-version,
1268         proto-unsupported-operation,      -- Request CHOICE tag unknown
1269         proto-generic-see-op-error,       -- See Op-error
1270         proto-wrong-service-principal,    -- Use kadmin/setpw
1271
1272 N. Williams et. al.                                             [Page 22]\f
1273
1274 DRAFT           Kerberos Set/Change Password v2         Expires April 2004
1275
1276         proto-re-authentication-required,
1277         proto-initial-ticket-required,
1278         proto-client-and-target-realm-mismatch,
1279         proto-target-principal-unknown,
1280         proto-authorization-failed,
1281         ...
1282    }
1283
1284    --
1285    -- Requests and responses
1286    --
1287
1288    -- NULL request, much like ONC RPC's NULL procedure - NOT extensible
1289    Req-null    ::= NULL
1290
1291    Rep-null    ::= NULL
1292
1293    Err-null    ::= NULL
1294
1295    -- Change password
1296    Req-change-pw        ::= SEQUENCE {
1297         old-pw          [0] UTF8String,
1298         new-pw          [1] UTF8String OPTIONAL,
1299         etypes          [2] SEQUENCE (1..) OF Etype OPTIONAL,
1300         ...
1301    }
1302
1303    Rep-change-pw        ::= SEQUENCE {
1304         info-text       [0] UTF8String OPTIONAL,
1305         new-pw          [1] UTF8String OPTIONAL,
1306                                 -- generated by the server if present
1307                                 -- (and requested by the client)
1308         etypes          [2] SEQUENCE (1..) OF Etype OPTIONAL,
1309         ...
1310    }
1311
1312    Err-change-pw        ::= SEQUENCE {
1313         help-text               [0] UTF8String OPTIONAL,
1314         error                   [1] CHOICE {
1315                 op-generic-error                [0] Extensible-NULL,
1316                 op-old-pw-incorrect             [1] Extensible-NULL,
1317                 op-wont-generate-new-pw         [2] Extensible-NULL,
1318                 op-new-pw-rejected-generic      [3] SEQUENCE {
1319                         policy              [1] SEQUENCE OF UTF8String,
1320                         suggested-pw        [2] UTF8String OPTIONAL,
1321                         ...
1322                 }
1323                 op-etype-not-supported          [4] SEQUENCE {
1324                         supported-etypes    [1] SEQUENCE OF Etype,
1325                         ...
1326                 },
1327                 ...
1328         },
1329
1330 N. Williams et. al.                                             [Page 23]\f
1331
1332 DRAFT           Kerberos Set/Change Password v2         Expires April 2004
1333
1334         ...
1335    }
1336
1337    -- Set password
1338    Req-set-pw   ::= SEQUENCE {
1339         languages       [0] SEQUENCE OF Language-Tag OPTIONAL,
1340         new-pw          [1] UTF8String OPTIONAL,
1341         etypes          [2] SEQUENCE (1..) OF Etype OPTIONAL,
1342         ...
1343    }
1344
1345    Rep-set-pw   ::= SEQUENCE {
1346         info-text       [0] UTF8String OPTIONAL,
1347         new-pw          [1] UTF8String OPTIONAL,
1348                                 -- generated by the server if present
1349                                 -- (and requested by the client)
1350         etypes          [2] SEQUENCE (1..) OF Etype OPTIONAL,
1351         ...
1352    }
1353
1354    Err-set-pw   ::= SEQUENCE {
1355         help-text               [0] UTF8String OPTIONAL,
1356         error                   [1] CHOICE {
1357                 op-generic-error                [0] Extensible-NULL,
1358                 op-use-change-pw                [1] Extensible-NULL,
1359                 op-wont-generate-new-pw         [2] Extensible-NULL,
1360                 op-new-pw-rejected-generic      [3] SEQUENCE {
1361                         policy              [1] SEQUENCE OF UTF8String,
1362                         suggested-pw        [2] UTF8String OPTIONAL,
1363                         ...
1364                 }
1365                 op-etype-not-supported          [4] SEQUENCE {
1366                         supported-etypes    [1] SEQUENCE OF Etype,
1367                         ...
1368                 },
1369                 ...
1370         },
1371         ...
1372    }
1373
1374    -- Set keys
1375    Req-set-keys ::= SEQUENCE {
1376         keys            [0] SEQUENCE OF Key,
1377         commit          [1] BOOLEAN,
1378                                 -- TRUE  -> install keys now
1379                                 --
1380                                 -- FALSE -> require set-keys-commit
1381                                 --          before issuing tickets
1382                                 --          encrypted with these keys.
1383                                 --
1384                                 -- See commit-keys op
1385         isupport        [2] KerberosVSupportNego OPTIONAL,
1386                                 -- For future Kerberos V extensions KDCs
1387
1388 N. Williams et. al.                                             [Page 24]\f
1389
1390 DRAFT           Kerberos Set/Change Password v2         Expires April 2004
1391
1392                                 -- may need to know what krb5 version is
1393                                 -- supported by individual service
1394                                 -- principals.  This field provides a
1395                                 -- way to tell the KDC what version of
1396                                 -- Kerberos V the target principal
1397                                 -- supports.
1398         ...
1399    }
1400
1401    Rep-set-keys ::= SEQUENCE {
1402         info-text       [0] UTF8String OPTIONAL,
1403         kvno            [1] UInt32,
1404         aliases         [2] SEQUENCE OF SEQUENCE {
1405                 name        [0] PrincipalName,
1406                 realm       [1] Realm OPTIONAL,
1407                 ...
1408         },
1409         isupport        [3] KerberosVSupportNego OPTIONAL,
1410         ...
1411         -- Should there be ETYPE-INFO2 stuff here?
1412    }
1413
1414    Err-set-keys ::= SEQUENCE {
1415         help-text       [0] UTF8String OPTIONAL, -- Reason for rejection
1416         error           [1] CHOICE {
1417                 op-generic                      [0] Extensible-NULL,
1418                 op-deferred-commit-no-support   [1] Extensible-NULL,
1419                 op-etype-no-support             [2] SEQUENCE OF {
1420                         supported-etypes        [1] SEQUENCE OF Etype,
1421                         ...
1422                 }
1423                 ...
1424         }
1425    }
1426
1427    -- Generate keys
1428    Req-gen-keys ::= SEQUENCE {
1429         etypes          [0] SEQUENCE (1..) OF Etype,
1430         entropy         [1] OCTET STRING OPTIONAL,
1431         commit          [2] BOOLEAN,
1432                                 -- TRUE  -> install keys now
1433                                 --
1434                                 -- FALSE -> require set-keys-commit
1435                                 --          before issuing tickets
1436                                 --          encrypted with these keys.
1437                                 --
1438                                 -- See commit-keys op
1439         isupport        [3] KerberosVSupportNego OPTIONAL,
1440                                 -- For future Kerberos V extensions KDCs
1441                                 -- may need to know what krb5 version is
1442                                 -- supported by individual service
1443                                 -- principals.  This field provides a
1444                                 -- way to tell the KDC what version of
1445
1446 N. Williams et. al.                                             [Page 25]\f
1447
1448 DRAFT           Kerberos Set/Change Password v2         Expires April 2004
1449
1450                                 -- Kerberos V the target principal
1451                                 -- supports.
1452         ...
1453    }
1454
1455    Rep-gen-keys ::= SEQUENCE {
1456         info-text       [0] UTF8String OPTIONAL,
1457         kvno            [1] UInt32,
1458         key             [2] Key,
1459         aliases         [3] SEQUENCE OF SEQUENCE {
1460                 name        [0] PrincipalName,
1461                 realm       [1] Realm OPTIONAL,
1462                 ...
1463         },
1464         isupport        [4] KerberosVSupportNego OPTIONAL,
1465         ...
1466         -- Should there be ETYPE-INFO2 stuff here?
1467    }
1468
1469    Err-gen-keys ::= Err-set-keys
1470
1471    -- Get un-committed key request
1472    Req-get-keys ::= SEQUENCE {
1473         kvno            [0] UInt32,
1474         ...
1475    }
1476
1477    Rep-get-keys ::= SEQUENCE {
1478         info-text       [0] UTF8String OPTIONAL,
1479         keys            [1] SEQUENCE OF Key,
1480         aliases         [2] SEQUENCE OF SEQUENCE {
1481                 name        [0] PrincipalName,
1482                 realm       [1] Realm OPTIONAL,
1483                 ...
1484         },
1485         isupport        [3] KerberosVSupportNego OPTIONAL,
1486         ...
1487         -- Should there be ETYPE-INFO2 stuff here?
1488    }
1489
1490    Err-get-keys ::= SEQUENCE {
1491         help-text       [0] UTF8String OPTIONAL, -- Reason for rejection
1492         error           [1] CHOICE {
1493                 op-generic              [0] Extensible-NULL,
1494                 op-kvno-committed       [1] Extensible-NULL,
1495                 op-no-such-kvno         [1] Extensible-NULL,
1496                 ...
1497         }
1498    }
1499
1500    -- Commit a set keys request
1501    Req-commit-keys ::= SEQUENCE {
1502         kvno            [0] UInt32,
1503
1504 N. Williams et. al.                                             [Page 26]\f
1505
1506 DRAFT           Kerberos Set/Change Password v2         Expires April 2004
1507
1508         ...
1509    }
1510
1511    Rep-commit-keys ::= Extensible-NULL
1512
1513    Err-commit-keys ::= SEQUENCE {
1514         help-text       [0] UTF8String OPTIONAL, -- Reason for rejection
1515         error           [1] CHOICE {
1516                 op-generic                  [0] Extensible-NULL,
1517                 op-kvno-expired             [1] Extensible-NULL,
1518                     -- The client took too long to respond.
1519                 op-kvno-unknown             [2] Extensible-NULL,
1520                     -- The targ princ/kvno is invalid or unknown to the
1521                     -- server (perhaps it lost track of state)
1522                 op-new-keys-conflict        [3] Extensible-NULL,
1523                     -- A new-keys/commit-keys request subsequent to the
1524                     -- new-keys that produced the kvno has completed
1525                     -- and incremented the principal's kvno
1526                 ...
1527         }
1528         ...
1529    }
1530
1531    -- Get password policy
1532    Req-get-pw-policy   ::= Extensible-NULL
1533
1534    Rep-get-pw-policy   ::= SEQUENCE {
1535         policy-name     [0] UTF8String OPTIONAL,
1536         description     [1] SEQUENCE OF UTF8String OPTIONAL,
1537         ...
1538    }
1539
1540    Err-get-pw-policy   ::= Extensible-NULL
1541
1542    -- Get principal aliases
1543    Req-get-princ-aliases        ::= Extensible-NULL
1544
1545    Rep-get-princ-aliases        ::= SEQUENCE {
1546         help-text       [0] UTF8String OPTIONAL,
1547         aliases         [1] SEQUENCE OF SEQUENCE {
1548                 name        [0] PrincipalName,
1549                 realm       [1] Realm OPTIONAL,
1550                 ...
1551         },
1552         ...
1553    }
1554
1555    Err-get-princ-aliases        ::= Extensible-NULL
1556
1557    -- Get list of enctypes supported by KDC for new keys
1558    Req-get-realm-krb5-support   ::=     Extensible-NULL
1559
1560    Rep-get-realm-krb5-support   ::= SEQUENCE {
1561
1562 N. Williams et. al.                                             [Page 27]\f
1563
1564 DRAFT           Kerberos Set/Change Password v2         Expires April 2004
1565
1566         isupport        [0] KerberosVSupportNego,
1567                                 -- Version of Kerberos V supported by
1568                                 -- the target realm.
1569         ...
1570    }
1571
1572    Err-get-realm-krb5-support   ::= Extensible-NULL
1573
1574    END
1575
1576
1577 6  IANA Considerations
1578
1579    None.
1580
1581 7  Security Considerations
1582
1583    Implementors and site administrators should note that the redundancy
1584    of UTF-8 encodings varies by Unicode codepoint used.  Password
1585    quality policies should, therefore, take this into account when
1586    estimating the amount of redundancy and entropy in a proposed new
1587    password.  [?? It's late at night - I think this is correct.]
1588
1589    Kerberos set/change password/key protocol major version negotiation
1590    cannot be done securely.  A downgrade attack is possible against
1591    clients that attempt to negotiate the protocol major version to use
1592    with a server.  It is not clear at this time that the attacker would
1593    gain much from such a downgrade attack other than denial of service
1594    (DoS) by forcing the client to use a protocol version which does not
1595    support some feature needed by the client (Kerberos V in general is
1596    subject to a variety of DoS attacks anyways [RFC1510]).
1597
1598    This protocol does not have Perfect Forward Security (PFS).  As a
1599    result, any passive network snooper watching password/key changing
1600    operations who has stolen a principal's password or long-term keys
1601    can find out what the new ones are.
1602
1603    [More text needed]
1604
1605 8  Acknowledgements
1606
1607    The authors would like to thank  Raeburn, Tom Yu, Martin Rex, Sam
1608    Hartman, Tony Andrea, Paul W. Nelson, Marcus Watts, Love, Joel N.
1609    Weber II, Jeffrey Hutzelman and other participants from the IETF
1610    Kerberos Working Group for their assistance.
1611
1612 9  References
1613
1614 9.1  Normative References
1615
1616    [RFC2026]
1617       S. Bradner, RFC2026:  "The Internet Standard Process - Revision
1618       3," October 1996, Obsoletes - RFC 1602, Status: Best Current
1619
1620 N. Williams et. al.                                             [Page 28]\f
1621
1622 DRAFT           Kerberos Set/Change Password v2         Expires April 2004
1623
1624       Practice.
1625
1626    [RFC2119]
1627       S. Bradner, RFC2119 (BCP14):  "Key words for use in RFCs to
1628       Indicate Requirement Levels," March 1997, Status: Best Current
1629       Practice.
1630
1631    [X680]
1632       Abstract Syntax Notation One (ASN.1): Specification of Basic
1633       Notation, ITU-T Recommendation X.680 (1997) | ISO/IEC
1634       International Standard 8824-1:1998.
1635       http://www.itu.int/ITU-T/studygroups/com17/languages/X680_0702.pdf
1636
1637    [X690]
1638       ASN.1 encoding rules: Specification of Basic Encoding Rules (BER),
1639       Canonical Encoding Rules (CER) and Distinguished Encoding Rules
1640       (DER), ITU-T Recommendation X.690 (1997)| ISO/IEC International
1641       Standard 8825-1:1998.
1642       http://www.itu.int/ITU-T/studygroups/com17/languages/X690_0702.pdf
1643
1644    [clarifications]
1645       RFC-Editor: To be replaced by RFC number for draft-ietf-krb-wg-
1646       kerberos-clarifications.
1647
1648    [k5stringprep]
1649       RFC-Editor: To be replaced by RFC number for draft-ietf-krb-wg-
1650       utf8-profile.
1651
1652    [RFC3066]
1653       H. Alvestrand, RFC3066 (BCP47): "Tags for the Identification of
1654       Languages," January 2001, Obsoletes RFC1766, Status: Best Current
1655       Practice.
1656
1657    [KPASSWDv1]
1658       (Reference needed!)
1659
1660 9.2  Informative References
1661
1662    [RFC3244]
1663       M. Swift, J. Trostle, J. Brezak, RFC3244: "Microsoft Windows 2000
1664       Kerberos Change Password and Set Password Protocols," February
1665       2002, Status: Informational.
1666
1667 10  Authors' Addresses
1668
1669       Nicolas Williams
1670       Sun Microsystems
1671       5300 Riata Trace Ct
1672       Austin, TX 78727
1673       Email: nicolas.williams@sun.com
1674
1675       Jonathan Trostle
1676       Cisco Systems
1677
1678 N. Williams et. al.                                             [Page 29]\f
1679
1680 DRAFT           Kerberos Set/Change Password v2         Expires April 2004
1681
1682       170 W. Tasman Dr.
1683       San Jose, CA 95134
1684       Email: jtrostle@cisco.com
1685
1686       Mike Swift
1687       University of Washington
1688       Seattle, WA
1689       Email: mikesw@cs.washington.edu
1690
1691       John Brezak
1692       Microsoft
1693       1 Microsoft Way
1694       Redmond, WA 98052
1695       Email: jbrezak@microsoft.com
1696
1697       Bill Gossman
1698       Cisco Systems
1699       500 108th Ave. NE, Suite 500
1700       Bellevue, WA 98004
1701       Email: bgossman@cisco.com
1702
1703 11  Notes to the RFC Editor
1704
1705    This document has two KRB WG drafts as normative references and
1706    cannot progress until those drafts progress, but no other draft
1707    depends on this one.
1708
1709 Full Copyright Statement
1710
1711    Copyright (C) The Internet Society (2003).  All Rights Reserved.
1712
1713    This document and translations of it may be copied and furnished to
1714    others, and derivative works that comment on or otherwise explain it
1715    or assist in its implementation may be prepared, copied, published
1716    and distributed, in whole or in part, without restriction of any
1717    kind, provided that the above copyright notice and this paragraph are
1718    included on all such copies and derivative works.  However, this
1719    document itself may not be modified in any way, such as by removing
1720    the copyright notice or references to the Internet Society or other
1721    Internet organizations, except as needed for the purpose of
1722    developing Internet standards in which case the procedures for
1723    copyrights defined in the Internet Standards process must be
1724    followed, or as required to translate it into languages other than
1725    English.
1726
1727    The limited permissions granted above are perpetual and will not be
1728    revoked by the Internet Society or its successors or assigns.
1729
1730    This document and the information contained herein is provided on an
1731    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1732    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1733    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1734    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1735
1736 N. Williams et. al.                                             [Page 30]\f
1737
1738 DRAFT           Kerberos Set/Change Password v2         Expires April 2004
1739
1740    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1741
1742 Acknowledgement
1743
1744    Funding for the RFC Editor function is currently provided by the
1745    Internet Society.
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797 N. Williams et. al.                                             [Page 31]\f
1798
1799
1800
1801