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

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