third_party/heimdal/doc/standardisation/draft-ietf-krb-wg-kerberos-set-passwd-00.txt

   1
   2 Kerberos Working Group                                  Jonathan Trostle
   3 INTERNET-DRAFT                                             Cisco Systems
   4 Category: Standards Track                                     Mike Swift
   5                                                         University of WA
   6                                                              John Brezak
   7                                                                Microsoft
   8                                                             Bill Gossman
   9                                                            Cisco Systems
  10                                                         Nicolas Williams
  11                                                         Sun Microsystems
  12
  13
  14
  15                 Kerberos Set/Change Password: Version 2
  16               <draft-ietf-krb-wg-kerberos-set-passwd-00.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 proposal specifies an extensible protocol for setting keys and
  53    changing the passwords of Kerberos [RFC1510] principals.
  54
  55    The protocol support a single operation per-session when run over UDP, or
  56
  57 Trostle et. al.                                                 [Page 1]
  58 \f
  59 DRAFT           Kerberos Set/Change Password v2         Expires November 2003
  60
  61    multiple operations per-session when run over TCP.  Clients can
  62    change their own principal's password or keys or they can change
  63    other principals', provided that they are properly authorized to do
  64    so.
  65
  66    Additional related features include the ability to determine the
  67    known aliases of Kerberos principals.  This feature will facilitate
  68    the implementation of aliasing of target principal names in KDC
  69    requests by allowing principals to know which names are aliases of
  70    their canonical principal names.  Principal aliasing is needed to
  71    properly support the use of aliases and short-form names by users
  72    without requiring that clients canonicalize principal names, possibly
  73    using insecure name services in the process.
  74
  75    This protocol uses IETF language tags [RFC3066] to negotiate proper
  76    localization of help messages intended for users.  UTF-8 is used
  77    throughout for strings, suitably constrained, where necessary, by the
  78    minor version of Kerberos V in use by clients and servers.
  79
  80 1. Introduction
  81
  82    Kerberos lacks a single, standard protocol for changing passwords and
  83    keys.  While several vendor-specific protocols exist for changing
  84    Kerberos passwords/keys, none are properly internationalized.
  85
  86    This document defines a protocol that is somewhat backward-compatible
  87    with the "kpasswd" protocol, version 1 [KPASSWDv1] and a derivative
  88    defined in [RFC3244] that uses more or less the same protocol framing.
  89
  90    This new protocol is designed to be extensible and properly
  91    internationalized.
  92
  93 2. Conventions used in this document
  94
  95    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  96    "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
  97    document are to be interpreted as described in [RFC2119].
  98
  99 3. Table of Contents
 100
 101    1. Introduction
 102    2. Conventions used in this document
 103    3. Table of Contents
 104    4. The Protocol
 105    4.1 Transports
 106    4.2 Protocol Framing
 107    4.2.1 The protocol over UDP
 108    4.2.2 The protocol over TCP
 109    4.3 Protocol version negotiation
 110    4.3.1 Protocol major version negotiation
 111    4.3.2 Protocol minor version negotiation
 112    4.4 Use of Kerberos V
 113    4.4.1 Use of KRB-ERROR
 114
 115 Trostle et. al.                                                 [Page 2]
 116 \f
 117 DRAFT           Kerberos Set/Change Password v2         Expires November 2003
 118
 119    4.5 Use of ASN.1
 120    4.6 Protocol internationalization
 121    4.6.1 Normalization forms for UTF-8 strings
 122    4.6.2 Language negotiation
 123    4.7 Protocol Extensibility
 124    4.8 Protocol Subsets
 125    5  Protocol Operations
 126    5.1 PDUs
 127    6  ASN1 Module
 128    7 Descriptions of each protocol requests and responses
 129    7.1 Null Request
 130    7.2 Change Password
 131    7.3 Set Keys Requests
 132    7.5 The Get Policy Request
 133    7.6 The Get Aliases Request
 134    7.7 The Get Supported Enctypes Request
 135    8 IANA Considerations
 136    9 Security Considerations
 137    10 Description of TLV Encoding of Sample Subsets of the Protocol
 138    10.1 TLV encoding of the Null request and response
 139    10.2 TLV encoding of Error-Response
 140    10.3 TLV encoding of the change password requests and responses
 141    10.4 TLV encoding of Change Keys requests and responses
 142    11 Acknowledgements
 143    12 References
 144    13 Expiration Date
 145    14 Authors' Addresses
 146    15 Notes to the RFC Editor
 147
 148 4. The Protocol
 149
 150    The structure of the protocol is quite similar to that of typical RPC
 151    protocols.  Each operation has a structure for each client request and
 152    a structure for each server response.  Each transaction consists of a
 153    single operation; the abstract syntax for the protocol implies the
 154    use, on the wire, of an operation identifier associated with an
 155    opaque blob representing the request of response.  The protocol data
 156    is wrapped in a KRB-PRIV and framed in a header that is backwards
 157    compatible with version 1 of this protocol.
 158
 159 4.1 Transports
 160
 161    The service SHOULD accept requests on UDP port 464 and TCP port 464.
 162    This is the same port used by version 1 [KPASSWDv1] of this protocol,
 163    but version 2 is a completely different protocol sharing with version
 164    1 only the outer framing.
 165
 166 4.2 Protocol Framing
 167
 168    For compatibility with the original Kerberos password changing
 169    protocol developed at MIT, the first 4 bytes of the message consist
 170    of a 2-byte network byte order message length, followed by a 2 byte
 171    network byte order protocol version number, followed by a 2 byte
 172
 173 Trostle et. al.                                                 [Page 3]
 174 \f
 175 DRAFT           Kerberos Set/Change Password v2         Expires November 2003
 176
 177    network byte order length for an optional AP-REQ, AP-REP or
 178    KRB-ERROR, followed by the same, if present, followed by a KRB-PRIV
 179    (optional in TCP) containing the actual protocol message encoded in
 180    DER [X690].
 181
 182    In the case of TCP there is an additional 4 byte network byte order
 183    length prepended to the frame described above.
 184
 185    The protocol version number MUST be set to 2 for this protocol.
 186
 187    Bytes on the wire description of the framing:
 188
 189        0                   1                   2                   3
 190        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
 191       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 192       |         message length        |    protocol version number    |
 193       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 194       | AP-REQ length (0 if absent)   | AP-REQ data (if present)      /
 195       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 196       /                   KRB-PRIV message                            /
 197       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 198
 199    The same framing applies equally to requests and responses, but
 200    responses use AP-REP and/or KRB-ERROR instead of AP-REQ:
 201
 202        0                   1                   2                   3
 203        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
 204       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 205       |         message length        |    protocol version number    |
 206       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 207       | AP-REP length (0 if absent)   | AP-REP data (if present)      /
 208       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 209       /                   KRB-PRIV message                            /
 210       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 211
 212        0                   1                   2                   3
 213        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
 214       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 215       |         message length        |    protocol version number    |
 216       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 217       | KRB-ERROR length (0 if absent)| KRB-ERROR data (if present)   /
 218       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 219
 220    For the UDP case the AP-REQ/AP-REP/KRB-ERROR MUST always be included.
 221
 222    Note that this framing is used by version 1 [KPASSWDv1] and version
 223    0xff80 [RFC3244], though the latter does not use the framing when
 224    responding with KRB-ERROR messages.
 225
 226    Servers MAY respond to version 0xff80 requests with an un-framed
 227    KRB-ERROR and e-data set as per-RFC3244 [RFC3244], otherwise clients
 228    and server MUST always use this framing.  See section 4.3.
 229
 230
 231 Trostle et. al.                                                 [Page 4]
 232 \f
 233 DRAFT           Kerberos Set/Change Password v2         Expires November 2003
 234
 235 4.2.1 The protocol over UDP
 236
 237    In the UDP case there is a single message from the client and a
 238    single response from the server with no state kept between requests,
 239    and each request MUST include a Kerberos AP-REQ and a KRB-PRIV and
 240    each response MUST carry an AP-REP, or KRB-ERROR and a KDB-PRIV.
 241    Both the client and server MUST destroy the authentication context
 242    after each operation.
 243
 244    UDP clients MUST not request the use of sequence numbers, otherwise
 245    it cannot generate the KRB-PRIV prior to receiving the AP-REP.
 246    Clients MAY refuse to operate version 2 of the protocol over UDP; it
 247    is RECOMMENDED that servers reject version 2 UDP requests.
 248
 249 4.2.2 The protocol over TCP
 250
 251    When used with the TCP transport, there is a 4 octet header in
 252    network byte order that precedes the message and specifies the length
 253    of the message.
 254
 255    The initial message from the client MUST carry an AP-REQ and the
 256    response to any request bearing an AP-REQ MUST carry an AP-REP.
 257
 258    Subsequent messages MAY involve Kerberos V AP exchanges, but
 259    generally the client SHOULD NOT initiate a new AP exchange except
 260    when it desires to authenticate as a different principal, when
 261    its current authentication context is about to expire or when the
 262    server responds with an error indicating that the client must
 263    re-initialize the authentication context (possibly due to the
 264    previous context expiring).
 265
 266    The server MUST NOT process any requests that do not contain an
 267    AP-REQ unless a non-expired authentication context is currently
 268    established with the client on the same TCP connection.
 269
 270    Servers MAY close open sessions at any time.
 271
 272 4.3 Protocol version negotiation
 273
 274    There are several major versions of this protocol.  Version 2 also
 275    introduces a notion of protocol minor versions for use in negotiating
 276    protocol extensions.  As of this time only one minor version is
 277    defined for major version 2: minor version 0.
 278
 279 4.3.1 Protocol major version negotiation
 280
 281    Version 2 clients that also support other versions, such as
 282    [KPASSWDv1] or [rfc3244] SHOULD attempt to use version 2 of the
 283    protocol first and then try other versions if the server
 284    responds with either a message framed as described in section 4.2 but
 285    with a protocol version number other than 2 (in the case of
 286    [KPASSWDv1], or a KRB-ERRROR with an error code of
 287    KRB5_KPASSWD_BAD_VERSION in the e-data field [RFC3244].
 288
 289 Trostle et. al.                                                 [Page 5]
 290 \f
 291 DRAFT           Kerberos Set/Change Password v2         Expires November 2003
 292
 293
 294    Note that some version 1 servers return a KRB-ERROR indicating that
 295    versions other than 1 of the change password protocol are not
 296    supported rather than an AP-REP and a KRB-PRIV containing the error
 297    data.  Therefore change password protocol negotiation is subject to
 298    downgrade attacks where version 2 clients support version 1 of this
 299    protocol.
 300
 301    Also note that some [RFC3244] implementations do not return any
 302    responses to requests for protocol versions other than 0xff80, and in
 303    the TCP case close the TCP connection.
 304
 305    Version 2 servers MAY support other versions of the Kerberos password
 306    change protocol.
 307
 308    Version 2 servers SHOULD respond to non-v2 requests using whatever
 309    response is appropriate for the versions used by the clients, but if
 310    a server does not do this or know how to do this then it MUST respond
 311    with an error framed as in section 4.2, using an AP-REP and KRB-PRIV
 312    if the client's AP-REQ can be accepted, or a KRB-ERROR (framed)
 313    otherwise and using a ProtocolErrorCode value of
 314    unsupported-major-version.
 315
 316 4.3.2 Protocol minor version negotiation
 317
 318    Version 2 clients are free to use whatever protocol minor version and
 319    message extensions are available to them in their initial messages to
 320    version 2 servers, provided that the minor versions (other than 0)
 321    have been defined through IETF documents and registered with the
 322    IANA.
 323
 324    Version 2 clients and servers MUST support all protocol minor
 325    versions between 0 to the highest version supported by the client and
 326    server.  That is, a client or server that supports minor version 4
 327    MUST also support minor versions 0, 1, 2 and 3.
 328
 329    Version 2 servers MUST answer with the highest protocol minor version
 330    number supported by the server and the client.
 331
 332    Version 2 clients MUST use the protocol minor version used in a
 333    server's reply for any subsequent messages in the same session
 334    (currently this only applies to TCP sessions).
 335
 336    See section 4.7 for further description of the protocol's
 337    extensibility and its relation to protocol minor versions and the
 338    negotiation thereof.
 339
 340 4.4 Use of Kerberos V
 341
 342    This protocol makes use of messages defined in [RFC1510] and
 343    [clarifications].  Specifically, AP-REQ, AP-REP, KRB-ERROR and
 344    KRB-PRIV.  Because of the proposed extensions to Kerberos V which
 345    will require a new ASN.1 module, and because of the ways that the
 346
 347 Trostle et. al.                                                 [Page 6]
 348 \f
 349 DRAFT           Kerberos Set/Change Password v2         Expires November 2003
 350
 351    Kerberos V ASN.1 types will change, this protocol cannot safely
 352    import any types from the Kerberos V module, therefore the Kerberos
 353    PDUs are encoded as OCTET STRINGs herein.
 354
 355    All operations are to be performed by the server on behalf of the
 356    client principal.
 357
 358    The client SHOULD use "kadmin/changepw" as the server principal name
 359    for this protocol.  The server MUST have a principal name of
 360    "kadmin/changepw" and MAY have a principal name of "kadmin/setpw."
 361
 362    The client MUST request mutual authentication and the client MUST NOT
 363    request the use of sequence numbers when using the protocol over
 364    UDP, but it MUST request the use of sequence numbers when running
 365    over TCP.
 366
 367    The server MUST reject requests that operate on the same principal as
 368    the client's if the client's principal is not in the same realm as
 369    the server's principal name or if the client's ticket is not INITIAL.
 370
 371    The server MAY reject all requests from clients operating on
 372    principals not in the client's realm.  The server MAY reject all
 373    requests operating on principals other than the client's.
 374
 375 4.4.1 Use of KRB-ERROR
 376
 377    When an error arises during the AP exchange for which
 378    [clarifications] does not provide an appropriate error code then the
 379    server MUST use KRB_ERR_GENERIC as the error, a localized (if
 380    possible [er, is that ok, pre-extensions? probably not]) error string
 381    for the e-text field of KRB-ERROR and the encoding of an
 382    Error-Response PDU (see section 6) as e-data.
 383
 384 4.5 Use of ASN.1
 385
 386    This protocol's messages are defined in ASN.1, using only features
 387    from [X680].  All ASN.1 types defined herein are to be encoded in
 388    DER [X690].  A complete ASN.1 module is given in section 6.  The
 389    ASN.1 tagging environment for this module is EXPLICIT.
 390
 391    The DER encoding of the ASN.1 PDUs are exchanged wrapped in a
 392    KRB-PRIV as described above.
 393
 394 4.6 Protocol internationalization
 395
 396    Protocol requests have an optional field indicationg the languages
 397    spoken by the client user; the client SHOULD send its list of spoken
 398    languages to the server (once per-TCP session), but if future
 399    extensions to the Kerberos protocol should add similar functionality
 400    then the client SHOULD NOT use this field when using the extended
 401    Kerberos protocol.  All strings in the protocol are UTF-8 strings.
 402    The server SHOULD localize all strings intended for users to a
 403    language in common with the languages spoken by the client user.
 404
 405 Trostle et. al.                                                 [Page 7]
 406 \f
 407 DRAFT           Kerberos Set/Change Password v2         Expires November 2003
 408
 409
 410    For TCP sessions servers MUST cache the optional language tag lists
 411    from prior requests for use with requests that exclude the language
 412    tag list.  Clients MAY expect such server behaviour and send the
 413    language tag lists only when they change or even just once per-TCP
 414    session.  Clients SHOULD send the server the language tag list at
 415    least once, with or before any actual operation.
 416
 417    Kerberos principal and realm names used in this protocol MUST be
 418    constrained as per the specification of the version of Kerberos V
 419    used by the client.
 420
 421 4.6.1 Normalization forms for UTF-8 strings
 422
 423    No normalization form is required for string types other than
 424    for PrincipalName and Realm, which two types are constrained by the
 425    specification of the version of Kerberos V used by the client, and
 426    the password fields in the change password operation, which MUST be
 427    normalized according to [k5stringprep].
 428
 429 4.6.2 Language negotiation
 430
 431    The server MUST pick a language from the client's input list or
 432    the default language tag (see [RFC3066]) for text in its responses
 433    which is meant for the user to read.
 434
 435    The server SHOULD use a language selection algorithm such that
 436    consideration is first given to exact matches between the client's
 437    spoken languages and the server's available locales, followed by
 438    "fuzzy" matches where only the first sub-tags of the client's
 439    language tag list are used for matching against the servers available
 440    locales.
 441
 442    When the server has a message catalog for one of the client's spoken
 443    languages the server SHOULD localize any text strings intended for
 444    users to read.
 445
 446 4.7 Protocol Extensibility
 447
 448    The protocol is defined in ASN.1 and uses extensibility markers
 449    throughout.  As such, the module presented herein can be extended
 450    within the framework of [X680].
 451
 452    Typed holes are not used in this protocol as it is very simple and
 453    does not require the ability to deal with abstract data types defined
 454    in different layers.  For this reason, the only way to extend this
 455    protocol is by extending the ASN.1 module within the framework of the
 456    IETF; all future extensions to this protocol have to be defined in
 457    IETF documents unless otherwise specified in a future IETF revision
 458    of this protocol.
 459
 460    A protocol minor version number is used to negotiate use of
 461    extensions.  See section 4.3.2 for the minor version negotiation.
 462
 463 Trostle et. al.                                                 [Page 8]
 464 \f
 465 DRAFT           Kerberos Set/Change Password v2         Expires November 2003
 466
 467
 468    Message extensions are to be closely tied to protocol minor numbers.
 469    Clients MAY use any protocol minor version that they support in
 470    initial requests, and MUST use the protocol minor version indicated
 471    in the server's initial reply in any subsequent requests in the same
 472    session (this only applies in the TCP case).  Clients MAY cache the
 473    minor version number supported by any given server for a reasonably
 474    short and finite amount of time - 24 hours is the maximum RECOMMENDED
 475    time for caching server minor version information.
 476
 477    Servers SHOULD ignore protocol extensions and minor versions that they
 478    do not understand in initial requests, except for extensions to the
 479    "Op-req" type, which MUST result in an error; servers MAY respond
 480    with an error (ProtocolErrorCode value of unsupported-minor-version)
 481    to clients that use minor versions unsupported by the server in their
 482    initial requests.
 483
 484    Servers MUST select the highest minor version in common with their
 485    clients for use in replies.
 486
 487    Servers MAY support a subset of the operations defined in this
 488    protocol but MUST support all the PDUs.
 489
 490 4.8 Protocol Subsets
 491
 492    The structure of the protocol is such that the ASN.1 syntaxes for the
 493    various operations supported by the protocol are independent of the
 494    each other.  Clients and servers MAY implement subsets of the overall
 495    protocol.
 496
 497    The structure of this protocol and the properties of the
 498    tag-length-value (TLV) DER encoding of ASN.1 make it possible to
 499    describe the encoding of individual operations' messages very simply.
 500
 501    In the interest of facilitating ease of implementation for trivial
 502    subsets of this protocol, without the need for ASN.1 compilers,
 503    section 10 describes examples of TLV layouts of some individual
 504    protocol operations (but the DER encodings of tags, lengths and
 505    UNIVERSAL values is not described).
 506
 507
 508 5  Protocol Operations
 509
 510    The protocol as defined herein supports the following operations
 511    relating to the management of Kerberos principal's passwords or keys:
 512
 513      - change password
 514      - set key
 515      - get password policy name and/or description of principal
 516      - list aliases of a principal
 517      - list enctypes supported by realm
 518
 519    These operations are needed to support Kerberos V interoperability
 520
 521 Trostle et. al.                                                 [Page 9]
 522 \f
 523 DRAFT           Kerberos Set/Change Password v2         Expires November 2003
 524
 525    between clients and KDCs of different implementation origins.
 526
 527    The operation for retrieving a list of aliases of a principal is
 528    needed where KDCs implement aliasing of principal names and allows
 529    clients to properly setup their "keytabs" when principal aliasing is
 530    in use.
 531
 532    Operations such as creation or deletion of principals are outside the
 533    scope of this document, and should be performed via directories or
 534    other Kerberos administration protocols.  However, it is conceivable
 535    that such operations could be added to this protocol at a later
 536    point.
 537
 538    Operations can be added to the protocol only via future IETF RFCs.
 539
 540    The individual operations are described in section 7.
 541
 542 5.1 PDUs
 543
 544    The types "Request," "Response" and "Error-Response" are the ASN.1
 545    module's PDUs.
 546
 547    The "Request" and "Response" PDUs are always to be sent wrapped in
 548    KRB-PRIV messages, except for the "Error-Response" PDU which MUST be
 549    sent as KRB-ERROR e-data (see section 4.4.1) when AP exchanges fail,
 550    otherwise it MUST be sent wrapped in a KRB-PRIV.
 551
 552    The PDUs are described in section 6.
 553
 554
 555 6  ASN1 Module
 556
 557 DEFINITIONS EXPLICIT TAGS ::= BEGIN
 558
 559 -- Unsafe: IMPORT AP-REQ, AP-REP, KRB-ERROR, KRB-PRIV, PrincipalName,
 560 --                          Realm, KerberosString, FROM KerberosV5Spec2
 561
 562 -- From [clarifications]
 563 PrincipalName       ::= SEQUENCE {
 564         name-type   [0] Int32,
 565         name-string [1] SEQUENCE OF UTF8String
 566 }
 567 Realm               ::= UTF8String
 568 -- NOTE WELL: Principal and realm names MUST be constrained by the
 569 --            specification of the version of Kerberos V used by the
 570 --            client.
 571 --
 572 -- [Perhaps PrincipalName should be a SEQUENCE of an optional name type
 573 -- and a UTF8String, for simplicity.]
 574
 575 -- From [clarifications]
 576 Int32       ::= INTEGER (-2147483648..2147483647)
 577 UInt32      ::= INTEGER (0..4294967295)
 578
 579 Trostle et. al.                                                 [Page 10]
 580 \f
 581 DRAFT           Kerberos Set/Change Password v2         Expires November 2003
 582
 583
 584 -- Based on EncryptionKey type from [clarifications]
 585 Key         ::= SEQUENCE {
 586         enc-type        [0] Int32,      -- from Kerberos
 587         key             [1] OCTET STRING,
 588         ...
 589 }
 590
 591 Etype       ::= Int32   -- as in [clarifications]
 592 -- Perhaps we should use an extensible CHOICE of Int32?
 593
 594 Language-Tag        ::= UTF8String -- Constrained by [RFC3066]
 595
 596 -- Use LangTaggedText instead of UTF8String for *-text fields and remove
 597 -- "language" field?
 598 --
 599 -- LangTaggedText should be used as e-text for KRB-ERROR, at least in
 600 -- extensions, perhaps in [clarifications]
 601 LangTaggedText      ::= SEQUENCE {
 602         language        [0] Language-Tag OPTIONAL,
 603         text            [1] UTF8String,
 604         ...
 605 }
 606
 607 Request         ::= [APPLICATION 0] SEQUENCE {
 608         pvno-major      [0] INTEGER DEFAULT 2,
 609         pvno-minor      [1] INTEGER DEFAULT 0,
 610         languages       [2] SEQUENCE OF Language-Tag OPTIONAL,
 611         targ-name       [3] PrincipalName OPTIONAL,
 612         targ-realm      [4] Realm OPTIONAL,
 613                 -- If targ-name/realm are missing then the request
 614                 -- applies to the principal of the client
 615         operation       [5] Op-req,
 616         ...
 617 }
 618
 619 Response        ::= [APPLICATION 1] SEQUENCE {
 620         pvno-major      [0] INTEGER DEFAULT 2,
 621         pvno-minor      [1] INTEGER DEFAULT 0,
 622         language        [2] Language-Tag DEFAULT "i-default",
 623         result          [3] Op-rep OPTIONAL,
 624         ...
 625 }
 626
 627 Error-Response  ::= [APPLICATION 2] SEQUENCE {
 628         pvno-major      [0] INTEGER DEFAULT 2,
 629         pvno-minor      [1] INTEGER DEFAULT 0,
 630         language        [2] Language-Tag DEFAULT "i-default",
 631         error-code      [3] ProtocolErrorCode,
 632         help-text       [4] UTF8String OPTIONAL,
 633         op-error        [5] Op-error OPTIONAL,
 634         ...
 635 }
 636
 637 Trostle et. al.                                                 [Page 11]
 638 \f
 639 DRAFT           Kerberos Set/Change Password v2         Expires November 2003
 640
 641
 642 Op-req          ::= CHOICE {
 643         null                    [0] Req-null,
 644         change-pw               [1] Req-change-pw,
 645         set-keys                [2] Req-set-keys,
 646         get-pw-policy           [3] Req-get-pw-policy,
 647         get-princ-aliases       [4] Req-get-princ-aliases,
 648         get-supported-etypes    [5] Req-get-supported-etypes,
 649         ...
 650 }
 651
 652 Op-rep          ::= CHOICE {
 653         null                    [0] Rep-null,
 654         change-pw               [1] Rep-change-pw,
 655         set-keys                [2] Rep-set-keys,
 656         get-pw-policy           [3] Rep-get-pw-policy,
 657         get-princ-aliases       [4] Rep-get-princ-aliases,
 658         get-supported-etypes    [5] Rep-get-supported-etypes,
 659         ...
 660 }
 661
 662 Op-error        ::= CHOICE {
 663         null                    [0] Err-null,
 664         change-pw               [1] Err-change-pw,
 665         set-keys                [2] Err-set-keys,
 666         get-pw-policy           [3] Err-get-pw-policy,
 667         get-princ-aliases       [4] Err-get-princ-aliases,
 668         get-supported-etypes    [5] Err-get-supported-etypes,
 669         ...
 670 }
 671
 672 ProtocolErrorCode           ::= ENUM {
 673         -- Remember, ASN.1 enums are zero-based
 674         generic-error,
 675         unsupported-major-version,
 676         unsupported-minor-version,
 677         unsupported-operation,
 678         authorization-failed,
 679         initial-ticket-required,
 680         target-principal-unknown,
 681         ...
 682 }
 683
 684 --
 685 -- Requests and responses
 686 --
 687
 688 -- NULL request, much like ONC RPC's NULL procedure
 689 Req-null    ::= NULL
 690
 691 Rep-null    ::= NULL
 692
 693 Err-null    ::= NULL
 694
 695 Trostle et. al.                                                 [Page 12]
 696 \f
 697 DRAFT           Kerberos Set/Change Password v2         Expires November 2003
 698
 699
 700 -- Change password
 701 Req-change-pw   ::= SEQUENCE {
 702         old-pw          [0] UTF8String,
 703         new-pw          [1] UTF8String OPTIONAL,
 704         etypes          [2] SEQUENCE (1..) OF Etype OPTIONAL,
 705         ...
 706 }
 707
 708 Rep-change-pw   ::= SEQUENCE {
 709         info-text       [0] UTF8String OPTIONAL,
 710         new-pw          [1] UTF8String OPTIONAL,
 711                                 -- generated by the server if present
 712                                 -- (and requested by the client)
 713         etypes          [2] SEQUENCE (1..) OF Etype OPTIONAL,
 714         ...
 715 }
 716
 717 Err-change-pw   ::= SEQUENCE {
 718         help-text               [0] UTF8String OPTIONAL,
 719         code                    [1] ENUM {
 720                 generic,
 721                 wont-generate-new-pw,
 722                 old-pw-incorrect,
 723                 new-pw-rejected-generic,
 724                 pw-change-too-soon,
 725                 ...
 726         },
 727         suggested-new-pw        [2] UTF8String OPTIONAL,
 728         ...
 729 }
 730
 731 -- Change/Set keys
 732
 733 Req-set-keys    ::= SEQUENCE {
 734         etypes          [0] SEQUENCE (1..) OF Etype,
 735         entropy         [1] OCTET STRING OPTIONAL,
 736                                 -- The client can provide entropy for
 737                                 -- the server's use while generating
 738                                 -- keys.
 739         ...
 740 }
 741
 742 Rep-set-keys    ::= SEQUENCE {
 743         info-text       [0] UTF8String OPTIONAL,
 744         kvno            [1] UInt32,
 745         keys            [2] SEQUENCE (1..) OF Key,
 746                                 -- The server always makes the keys.
 747         aliases         [3] SEQUENCE OF SEQUENCE {
 748                 name        [0] PrincipalName,
 749                 realm       [1] Realm OPTIONAL,
 750                 ...
 751         } OPTIONAL,
 752
 753 Trostle et. al.                                                 [Page 13]
 754 \f
 755 DRAFT           Kerberos Set/Change Password v2         Expires November 2003
 756
 757         ...
 758 }
 759
 760 Err-set-keys    ::= SEQUENCE {
 761         help-text       [0] UTF8String OPTIONAL, -- Reason for rejection
 762         enctypes        [1] SEQUENCE of Etype OPTIONAL, -- supported enctypes
 763         code            [2] ENUM {
 764                 etype-no-support,
 765                 ...
 766         }
 767 }
 768
 769 -- Get password policy
 770 Req-get-pw-policy   ::= NULL
 771
 772 Rep-get-pw-policy   ::= SEQUENCE {
 773         help-text       [0] UTF8String OPTIONAL,
 774         policy-name     [1] UTF8String OPTIONAL,
 775         description     [2] UTF8String OPTIONAL,
 776         ...
 777 }
 778
 779 Err-get-pw-policy   ::= NULL
 780
 781 -- Get principal aliases
 782 Req-get-princ-aliases   ::= NULL
 783
 784 Rep-get-princ-aliases   ::= SEQUENCE {
 785         help-text       [0] UTF8String OPTIONAL,
 786         aliases         [1] SEQUENCE OF SEQUENCE {
 787                 name        [0] PrincipalName,
 788                 realm       [1] Realm OPTIONAL,
 789                 ...
 790         } OPTIONAL,
 791         ...
 792 }
 793
 794 Err-get-princ-aliases   ::= NULL
 795
 796 -- Get list of enctypes supported by KDC for new keys
 797 Req-get-supported-etypes    ::= NULL
 798
 799 Rep-get-supported-etypes    ::= SEQUENCE OF Etype
 800
 801 Err-get-supported-etypes    ::= NULL
 802
 803 END
 804
 805 7 Descriptions of each protocol requests and responses
 806
 807    This section describes the semantics of each operation request and
 808    response defined in the ASN.1 module in section 6.
 809
 810
 811 Trostle et. al.                                                 [Page 14]
 812 \f
 813 DRAFT           Kerberos Set/Change Password v2         Expires November 2003
 814
 815    Requests and responses consist of an outer structure ("Request,"
 816    "Response" and "Error-Response") containing fields common to all
 817    requests/responses, and an inner structure for fields that are
 818    specific to each operation's requests/responses.
 819
 820    Specifically, the outer Request structure has a field for passing a
 821    client's spoken (read) languages to the server.  It also has two
 822    optional fields for identifying the operation's target principal's
 823    name and realm (if not sent then the server MUST use the client
 824    principal name and realm from the AP exchange as the target).
 825
 826    The Response and Error PDU' outer structures include a field
 827    indicating the language that the server has chosen for localization
 828    of text intended to be displayed to users.
 829
 830    All three PDUs, "Request," "Response," and "Error-Response" include a
 831    protocol version number and the two responses include an optional
 832    field through which the server can indicate which language, from the
 833    client's list, the server can "speak."
 834
 835 7.1 Null Request
 836
 837    The null request is intended for use with TCP; its purpose is similar
 838    to RPC null procedures and is akin to a "ping" operation.
 839
 840 7.2 Change Password
 841
 842    The change password request has two fields: old-pw (old password -
 843    required) and new-pw (new password - optional).  The server MUST
 844    validate the old password and MUST check the quality of the new
 845    password, if sent, according to the password policy associated with
 846    the client's principal before accepting the request.  If the client
 847    does not specify a new password the server MUST either generate one
 848    and return it in the response or reject the request with
 849    wont-generate-new-pw as the Err-change-pw message's error code.
 850
 851    If the server rejects a client's proposed new password it SHOULD
 852    include a description of the password quality policy in effect for
 853    the target principal and/or an explanation of what was wrong with the
 854    proposed password in the help-text field of the Err-change-pw
 855    message.  Additionally, servers MAY include a randomly generated, but
 856    preferably user-friendly password in the suggested-new-pw field of
 857    Err-change-pw messages when the client's proposed new password
 858    violates the target principal's password quality policy; of course,
 859    any such suggested new password MUST pass the target principal's
 860    password quality policy.
 861
 862    Clients MAY specify key enctypes to set with new passwords, but
 863    generally SHOULD NOT do so.  If a client requests specific enctypes
 864    then the server MUST NOT create keys from the new password of any
 865    enctype other than those requested by the client.
 866
 867    Servers MAY indicate the enctypes of the keys created with new
 868
 869 Trostle et. al.                                                 [Page 15]
 870 \f
 871 DRAFT           Kerberos Set/Change Password v2         Expires November 2003
 872
 873    passwords, but SHOULD NOT do so unless the client requested specific
 874    enctypes - in which case the server MUST include the new key enctypes
 875    in the change password response.
 876
 877 7.3 Set Keys Requests
 878
 879    The set keys request consists of a sequence of key enctypes and an
 880    optional OCTET STRING of client-provided entropy.
 881
 882    The server generates keys of the requested enctypes and returns them.
 883    The server MAY utilize some, all or none of the client-provided
 884    entropy, if any, to generate the keys, but the server SHOULD input
 885    some entropy in the process.
 886
 887    The server SHOULD also include a list of the target principal's
 888    aliases, if there are any.
 889
 890 7.5 The Get Policy Request
 891
 892    It is common for sites to set policies with respect to password
 893    quality.  It is beyond the scope of this document to describe such
 894    policies.  However, it is reasonable for password policies to have
 895    names and as such for this protocol to associate named password
 896    quality policies with principals.  It may also be reasonable for
 897    users to learn of their password quality policies.
 898
 899    The protocol therefore provides an operation for retrieving the name
 900    and/or description of the password policy that applies to the target
 901    principal name.
 902
 903    Management of password quality policies' actual content is beyond the
 904    scope of this protocol.
 905
 906 7.6 The Get Aliases Request
 907
 908    This request allows a client to obtain a list of aliases associated
 909    with a principal so that the client can properly configure the
 910    principal's "keytab."
 911
 912    Principal aliases are principal names for which the KDC will issue
 913    tickets (with the alias being either the client or target principal
 914    name of such tickets) using the same key as the "canonical" principal
 915    name, but without canonicalizing the aliased names in KDC exchanges.
 916
 917 7.7 The Get Supported Enctypes Request
 918
 919    This request allows a client to learn of the target principal's
 920    realm's supported enctypes.
 921
 922
 923 8 IANA Considerations
 924
 925    ...
 926
 927 Trostle et. al.                                                 [Page 16]
 928 \f
 929 DRAFT           Kerberos Set/Change Password v2         Expires November 2003
 930
 931
 932 9 Security Considerations
 933
 934    Implementors and site administrators should note that the redundancy
 935    of UTF-8 encodings varies by Unicode codepoint used.  Password
 936    quality policies should, therefore, take this into account when
 937    estimating the amount of redundancy and entropy in a proposed new
 938    password.  [?? It's late at night - I think this is correct.]
 939
 940    Kerberos set/change password/key protocol major version negotiation
 941    cannot be done securely.  A downgrade attack is possible against
 942    clients that attempt to negotiate the protocol major version to use
 943    with a server.  It is not clear at this time that the attacker would
 944    gain much from such a downgrade attack other than denial of service
 945    (DoS) by forcing the client to use a protocol version which does not
 946    support some feature needed by the client (Kerberos V in general is
 947    subject to a variety of DoS attacks anyways [RFC1510]).
 948
 949    [More text needed]
 950
 951 10 Description of TLV Encoding of Sample Subsets of the Protocol
 952
 953   This section provides example descriptions of the TLV DER encodings of
 954   some requests and responses.  This section is not intended to be
 955   authoritative and implementors are encouraged to base their
 956   implementations on the ASN.1 syntax given in section 6.  These TLV
 957   descriptions are given here in the interest of promoting
 958   implementation of this protocol even by implementors who do not have
 959   access to ASN.1 development tools.
 960
 961   Tags are described as T(<tag>) where <tag> is a letter denoting the
 962   tag type (u for UNIVERSAL, a for APPLICATION, c for CONTEXT and p for
 963   PRIVATE) and a number or universal type name.
 964
 965   Lengths and values are described as L{<value>}, where <value> is a
 966   description of the encoding of the value, except for scalar UNIVERSAL
 967   types, where <value> shall be '<' description of value '>'.
 968
 969   Optional fields are enclosed in square brackets ('[' and ']').
 970
 971   Repetition is denoted by ellipsis ("...").
 972
 973   Extensibility is denoted by "[...]".
 974
 975   Comments are introduced by "--" as in ASN.1
 976
 977 10.1 TLV encoding of the Null request and response
 978
 979    -- Null Request
 980    -- Outer application tag
 981    T(a0)L{T(uSEQUENCE)L{
 982      -- "preamble"
 983      -- pvno-major == 2 so it is left out
 984
 985 Trostle et. al.                                                 [Page 17]
 986 \f
 987 DRAFT           Kerberos Set/Change Password v2         Expires November 2003
 988
 989      -- pvno-minor == 0 so it is left out
 990      -- optional languages list
 991      [T(c2)L{
 992        T(uSEQUENCE)L{
 993          T(uUTF8String)L{<language tag>}
 994          ...
 995        }
 996      }]
 997      -- optional targ-name
 998      [T(c3)L{
 999        Tc(uSEQUENCE)L{
1000          -- name-type
1001          T(c0)L{T(uINTEGER)L{<name-type>}}
1002          -- name-string
1003          T(c1)L{
1004            T(uSEQUENCE)L{
1005              [T(uUTF8String)L{<component name>}]
1006              ...
1007            }
1008          }
1009        }
1010      }]
1011      -- optional targ-realm
1012      [T(c4)L{T(uUTF8String)L{<realm name>}}]
1013      -- end of preamble
1014
1015      -- operation choice tag
1016      T(c5)L{
1017        -- null CHOICE (this tag indicates the CHOICE taken; replace this
1018        -- TLV with the TLV for any operation to get the Request encoding
1019        -- of that operation)
1020        T(c0)L{
1021          -- Req-null (this is the encoding of the value of the CHOICE
1022          -- taken); NULL has no LV part.
1023          T(uNULL)
1024        }
1025      }
1026      -- extensions
1027      [...]
1028    }}
1029
1030    -- Null Response
1031    -- Outer application tag
1032    T(a1)L{T(uSEQUENCE)L{
1033      -- "preamble"
1034      -- pvno-major == 2 so it is left out
1035      -- pvno-minor == 0 so it is left out
1036      -- optional language
1037      [T(c1)L{T(uUTF8String)L{<language tag>}}]
1038      -- end preamble
1039      -- operation choice tag
1040      T(c2)L{
1041        -- null CHOICE
1042
1043 Trostle et. al.                                                 [Page 18]
1044 \f
1045 DRAFT           Kerberos Set/Change Password v2         Expires November 2003
1046
1047        T(c0)L{
1048          T(uNULL)
1049        }
1050      }
1051    }}
1052
1053 10.2 TLV encoding of Error-Response
1054
1055    -- Error Response
1056    -- Outer application tag
1057    T(a1)L{T(uSEQUENCE)L{
1058      -- "preamble"
1059      -- pvno-major == 2 so it is left out
1060      -- pvno-minor == 0 so it is left out
1061      -- optional language
1062      [T(c2)L{T(uUTF8String)L{<language tag>}}]
1063      -- end preamble
1064      -- error code
1065      T(c3)L{T(uENUM)L{<error code}}
1066      T(c4)L{T(uUTF8String)L{<error text}}
1067      -- optional CHOICE
1068      T(c5)L{
1069        -- CHOICE TLV goes here
1070        T(c<choice taken>)L{<value of CHOICE taken>}
1071      }
1072      -- extensions
1073      [...]
1074    }}
1075
1076 10.3 TLV encoding of the change password requests and responses
1077
1078    -- Req-change-pw
1079      -- choice tag
1080      T(c1)L{
1081        T(uSEQUENCE)L{
1082          -- old password
1083          T(c0)L{T(uUTF8String)L{<password string>}}
1084          -- new password (optional; if missing server must generate it)
1085          [T(c1)L{T(uUTF8String)L{<password string>}}]
1086          -- extensions
1087          [...]
1088        }
1089      }
1090
1091    -- Rep-change-pw
1092      -- choice tag
1093      T(c1)L{
1094        T(uSEQUENCE)L{
1095          -- optional informational text
1096          [T(c0)L{T(uUTF8String)L{<text>}}]
1097          -- new password (optional; see section 6)
1098          [T(c1)L{T(uUTF8String)L{<new password>}}]
1099          -- extensions
1100
1101 Trostle et. al.                                                 [Page 19]
1102 \f
1103 DRAFT           Kerberos Set/Change Password v2         Expires November 2003
1104
1105          [...]
1106        }
1107      }
1108
1109    -- Err-change-pw
1110      -- choice tag
1111      T(c1)L{
1112        T(uSEQUENCE)L{
1113          -- optional help text
1114          [T(c0)L{T(uUTF8String)L{<text>}}]
1115          -- error code
1116          T(c1)L{T(uENUM)L{<error code>}}]
1117          -- extensions
1118          [...]
1119        }
1120      }
1121
1122 10.4 TLV encoding of Change Keys requests and responses
1123
1124    -- Req-set-keys
1125      -- choice tag
1126      T(c1)L{
1127        T(uSEQUENCE)L{
1128          -- new key enctypes
1129          T(c0)L{T(uSEQUENCE)L{
1130            T(uINTEGER)L{<etype integer>},
1131            ...
1132          }}
1133          -- optional entropy
1134          [T(c1)L{T(uOCTET STRING)L{<entropy>}}]
1135          -- extensions
1136          [...]
1137        }
1138      }
1139
1140    -- Rep-set-keys
1141      -- choice tag
1142      T(c1)L{
1143        T(uSEQUENCE)L{
1144          -- optional informational text
1145          [T(c0)L{T(uUTF8String)L{<text>}}]
1146          -- new kvno
1147          T(c1)L{T(uINTEGER)L{<new kvno>}}
1148          -- new keys
1149          T(c2)L{T(uSEQUENCE)L{
1150            -- first key
1151            T(uSEQUENCE)L{
1152              T(uINTEGER)L{<etype>}
1153              T(uOCTET STRING)L{<key>}
1154              -- extensions to Key
1155              [...]
1156            }
1157            -- additional keys, if any
1158
1159 Trostle et. al.                                                 [Page 20]
1160 \f
1161 DRAFT           Kerberos Set/Change Password v2         Expires November 2003
1162
1163            ...
1164          }}
1165          -- optional aliases
1166          [T(c3)L{T(uSEQUENCE)L{
1167            -- first alias
1168            T(uSEQUENCE)L{
1169              -- principal name
1170              T(uSEQUENCE)L{
1171                T(uUTF8String)L{<component1>},
1172                -- components 2..N, if any
1173                ...
1174              }
1175              T(uUTF8String)L{<realm name>}
1176              -- extensions
1177              [...]
1178            }
1179            -- additional aliases, if any
1180            ...
1181          }}]
1182          -- extensions
1183          [...]
1184        }
1185      }
1186
1187    -- Err-set-keys
1188      -- choice tag
1189      T(c1)L{
1190        T(uSEQUENCE)L{
1191          -- optional help text
1192          [T(c0)L{T(uUTF8String)L{<text>}}]
1193          -- KDC supported enctypes
1194          [T(c1)L{T(uSEQUENCE)L{
1195            T(uINTEGER)L{<etype integer>},
1196            ...
1197          }}]
1198          -- error code
1199          T(c2)L{T(uENUM)L{<error code>}}]
1200          -- extensions
1201          [...]
1202        }
1203      }
1204
1205 11 Acknowledgements
1206
1207    The authors would like to thank Sam Hartman, Paul W. Nelson and
1208    Marcus Watts for their assistance.
1209
1210    The authors thank Ken Raeburn, Tom Yu, Martin Rex, Sam Hartman, Tony
1211    Andrea, Paul W. Nelson, Marcus Watts and other participants from the
1212    IETF Kerberos Working Group for their input to the document.
1213
1214 12 References
1215
1216
1217 Trostle et. al.                                                 [Page 21]
1218 \f
1219 DRAFT           Kerberos Set/Change Password v2         Expires November 2003
1220
1221 12.1 Normative References
1222
1223    [RFC2026]
1224       S. Bradner, RFC2026:  "The Internet Standard Process - Revision
1225       3," October 1996, Obsoletes - RFC 1602, Status: Best Current
1226       Practice.
1227
1228    [RFC2119]
1229       S. Bradner, RFC2119 (BCP14):  "Key words for use in RFCs to
1230       Indicate Requirement Levels," March 1997, Status: Best Current
1231       Practice.
1232
1233    [X680]
1234       Abstract Syntax Notation One (ASN.1): Specification of Basic
1235       Notation, ITU-T Recommendation X.680 (1997) | ISO/IEC
1236       International Standard 8824-1:1998.
1237       http://www.itu.int/ITU-T/studygroups/com17/languages/X680_0702.pdf
1238
1239    [X690]
1240       ASN.1 encoding rules: Specification of Basic Encoding Rules (BER),
1241       Canonical Encoding Rules (CER) and Distinguished Encoding Rules
1242       (DER), ITU-T Recommendation X.690 (1997)| ISO/IEC International
1243       Standard 8825-1:1998.
1244       http://www.itu.int/ITU-T/studygroups/com17/languages/X690_0702.pdf
1245
1246    [RFC1510]
1247       J. Kohl and  B. C. Neuman, RFC1510: "The Kerberos Network
1248       Authentication Service (v5)," September 1993, Status: Proposed
1249       Standard.
1250
1251    [clarifications]
1252       RFC-Editor: To be replaced by RFC number for draft-ietf-krb-wg-
1253       kerberos-clarifications.
1254
1255    [k5stringprep]
1256       RFC-Editor: To be replaced by RFC number for draft-ietf-krb-wg-
1257       utf8-profile.
1258
1259    [RFC3066]
1260       H. Alvestrand, RFC3066 (BCP47): "Tags for the Identification of
1261       Languages," January 2001, Obsoletes RFC1766, Status: Best Current
1262       Practice.
1263
1264    [KPASSWDv1]
1265       (Reference needed!)
1266
1267 12.1 Informative References
1268
1269    [RFC3244]
1270       M. Swift, J. Trostle, J. Brezak, RFC3244: "Microsoft Windows 2000
1271       Kerberos Change Password and Set Password Protocols," February
1272       2002, Status: Informational.
1273
1274
1275 Trostle et. al.                                                 [Page 22]
1276 \f
1277 DRAFT           Kerberos Set/Change Password v2         Expires November 2003
1278
1279 13 Authors' Addresses
1280
1281       Jonathan Trostle
1282       Cisco Systems
1283       170 W. Tasman Dr.
1284       San Jose, CA 95134
1285       Email: jtrostle@cisco.com
1286
1287       Mike Swift
1288       University of Washington
1289       Seattle, WA
1290       Email: mikesw@cs.washington.edu
1291
1292       John Brezak
1293       Microsoft
1294       1 Microsoft Way
1295       Redmond, WA 98052
1296       Email: jbrezak@microsoft.com
1297
1298       Bill Gossman
1299       Cisco Systems
1300       500 108th Ave. NE, Suite 500
1301       Bellevue, WA 98004
1302       Email: bgossman@cisco.com
1303
1304       Nicolas Williams
1305       Sun Microsystems
1306       5300 Riata Trace Ct
1307       Austin, TX 78727
1308       Email: nicolas.williams@sun.com
1309
1310 14 Notes to the RFC Editor
1311
1312    This document has two KRB WG drafts as normative references and
1313    cannot progress until those drafts progress, but no other draft
1314    depends on this one.
1315
1316 Full Copyright Statement
1317
1318    Copyright (C) The Internet Society (2003).  All Rights Reserved.
1319
1320    This document and translations of it may be copied and furnished to
1321    others, and derivative works that comment on or otherwise explain it
1322    or assist in its implementation may be prepared, copied, published
1323    and distributed, in whole or in part, without restriction of any
1324    kind, provided that the above copyright notice and this paragraph are
1325    included on all such copies and derivative works.  However, this
1326    document itself may not be modified in any way, such as by removing
1327    the copyright notice or references to the Internet Society or other
1328    Internet organizations, except as needed for the purpose of
1329    developing Internet standards in which case the procedures for
1330    copyrights defined in the Internet Standards process must be
1331    followed, or as required to translate it into languages other than
1332
1333 Trostle et. al.                                                 [Page 23]
1334 \f
1335 DRAFT           Kerberos Set/Change Password v2         Expires November 2003
1336
1337    English.
1338
1339    The limited permissions granted above are perpetual and will not be
1340    revoked by the Internet Society or its successors or assigns.
1341
1342    This document and the information contained herein is provided on an
1343    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
1344    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
1345    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
1346    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
1347    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1348
1349 Acknowledgement
1350
1351    Funding for the RFC Editor function is currently provided by the
1352    Internet Society.