doc/standardisation/draft-zhu-kerb-enctype-nego-01.txt

   1
   2
   3 NETWORK WORKING GROUP                                             L. Zhu
   4 Internet-Draft                                                  P. Leach
   5 Expires: October 2, 2005                                   K. Jaganathan
   6                                                    Microsoft Corporation
   7                                                           March 31, 2005
   8
   9
  10               Kerberos Cryptosystem Negotiation Extension
  11                       draft-zhu-kerb-enctype-nego-01
  12
  13 Status of this Memo
  14
  15    This document is an Internet-Draft and is subject to all provisions
  16    of Section 3 of RFC 3667.  By submitting this Internet-Draft, each
  17    author represents that any applicable patent or other IPR claims of
  18    which he or she is aware have been or will be disclosed, and any of
  19    which he or she become aware will be disclosed, in accordance with
  20    RFC 3668.
  21
  22    Internet-Drafts are working documents of the Internet Engineering
  23    Task Force (IETF), its areas, and its working groups.  Note that
  24    other groups may also distribute working documents as
  25    Internet-Drafts.
  26
  27    Internet-Drafts are draft documents valid for a maximum of six months
  28    and may be updated, replaced, or obsoleted by other documents at any
  29    time.  It is inappropriate to use Internet-Drafts as reference
  30    material or to cite them other than as "work in progress."
  31
  32    The list of current Internet-Drafts can be accessed at
  33    http://www.ietf.org/ietf/1id-abstracts.txt.
  34
  35    The list of Internet-Draft Shadow Directories can be accessed at
  36    http://www.ietf.org/shadow.html.
  37
  38    This Internet-Draft will expire on October 2, 2005.
  39
  40 Copyright Notice
  41
  42    Copyright (C) The Internet Society (2005).
  43
  44 Abstract
  45
  46    This document specifies an extension by Kerberos to negotiate new
  47    encryption types between the client-server peers.
  48
  49
  50
  51
  52
  53
  54 Zhu, et al.              Expires October 2, 2005                [Page 1]
  55 \f
  56 Internet-Draft             Enctype Negotiation                March 2005
  57
  58
  59 Table of Contents
  60
  61    1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
  62    2.   Conventions Used in This Document  . . . . . . . . . . . . . . 3
  63    3.   Negotiation Extension  . . . . . . . . . . . . . . . . . . . . 3
  64    4.   Security Considerations  . . . . . . . . . . . . . . . . . . . 4
  65    5.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 4
  66    6.   Normative References . . . . . . . . . . . . . . . . . . . . . 4
  67         Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 5
  68    A.   Leveraging this Enctype Negotiation in Windows SPNEGO
  69         Implementations  . . . . . . . . . . . . . . . . . . . . . . . 5
  70         Intellectual Property and Copyright Statements . . . . . . . . 7
  71
  72
  73
  74
  75
  76
  77
  78
  79
  80
  81
  82
  83
  84
  85
  86
  87
  88
  89
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110 Zhu, et al.              Expires October 2, 2005                [Page 2]
 111 \f
 112 Internet-Draft             Enctype Negotiation                March 2005
 113
 114
 115 1.  Introduction
 116
 117    Under the current mechanism [CLAR], the KDC must limit the ticket
 118    session key enctype chosen for a given server to one it believes is
 119    supported by both the client and the server.  If both the client and
 120    server understand a stronger enctype than the one selected by the
 121    KDC, they can not negotiate it.  As the result, the protection of
 122    application traffic is often weaker than necessary when the server
 123    can support different sets of enctypes depending on the server
 124    application software being used.
 125
 126    This document specifies an extension to Kerberos to allow clients and
 127    servers to negotiate a different and possible stronger cryptosystem
 128    to be used in subsequent communication.
 129
 130    This extension utilizes an authorization data element in the
 131    authenticator of the AP-REQ message [CLAR].  The client sends the
 132    list of enctypes that it supports to the server, the server then
 133    informs the client its choice.  The negotiated subkey is sent in the
 134    AP-REP message [CLAR].
 135
 136 2.  Conventions Used in This Document
 137
 138    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 139    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 140    document are to be interpreted as described in [RFC2119].
 141
 142 3.  Negotiation Extension
 143
 144    If the client prefers an enctype over that of the service ticket
 145    session key, then it MUST send the list of enctypes it supports
 146    (including the one selected by the KDC) in decreasing preference
 147    order.
 148
 149    The client sends the enctype list via the authorization-data of the
 150    authenticator in the AP-REQ [CLAR].  A new authorization data element
 151    type AD-ETYPE-NEGOTIATION (129) is defined.  This authorization data
 152    element itself is enclosed in the AD-IF-RELEVANT container, thus a
 153    correctly implemented server that does not understand this element
 154    should ignore it [CLAR].  The value of this authorization element
 155    contains the DER [X60] encoding of the following ASN.1 type:
 156
 157            EtypeList ::= SEQUENCE OF Int32
 158               -- Specifies the enctypes supported by the client.
 159               -- This enctype list is in decreasing preference order
 160               -- (favorite choice first).
 161               -- Int32 is defined in [CLAR].
 162
 163
 164
 165
 166 Zhu, et al.              Expires October 2, 2005                [Page 3]
 167 \f
 168 Internet-Draft             Enctype Negotiation                March 2005
 169
 170
 171    If the EtypeList is present and the server prefers an enctype from
 172    the client's enctype list over that of the AP-REQ authenticator
 173    subkey (if that is present) or the service ticket session key, the
 174    server MUST create a subkey using that enctype.  This negotiated
 175    subkey is sent in the subkey field of AP-REP message and it MUST be
 176    used for subsequent communication.
 177
 178    This negotiation extension MUST NOT be used when the client does not
 179    expect the subkey in the AP-REP message from the server.
 180
 181    Note that to preserve the quality of randomness provided by the KDC,
 182    implementations of this extension SHOULD consider using the service
 183    ticket session key value as a source of additional entropy when
 184    generating the negotiated subkey.  If the AP-REQ authenticator subkey
 185    is present, it MAY also be used as a source of entropy.
 186
 187    The policy by which the client or the server chooses an enctype
 188    (i.e., how the preference order for the supported enctypes is
 189    selected) is an implementation-specific local matter.
 190
 191 4.  Security Considerations
 192
 193    The client's enctype list and the server's reply enctype are part of
 194    encrypted data, thus the security considerations are the same as
 195    those of the Kerberos encrypted data.
 196
 197    In all cases, the communicating peers are exposed to the denial of
 198    service threat.
 199
 200 5.  IANA Considerations
 201
 202    No IANA actions are required for this document.
 203
 204 6.  Normative References
 205
 206    [CLAR]     RFC-Editor: To be replaced by RFC number for draft-ietf-
 207               krb-wg-kerberos-clarifications.  Work in Progress.
 208
 209    [GSS-CFX]  RFC-Editor: To be replaced by RFC number for draft-ietf-
 210               krb-wg-gssapi-cfx.  Work in Progress.
 211
 212    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 213               Requirement Levels", BCP 14, RFC 2119, March 1997.
 214
 215    [RFC2743]  Linn, J., "Generic Security Service Application Program
 216               Interface Version 2, Update 1", RFC 2743, January 2000.
 217
 218
 219
 220
 221 Zhu, et al.              Expires October 2, 2005                [Page 4]
 222 \f
 223 Internet-Draft             Enctype Negotiation                March 2005
 224
 225
 226    [SPNEGOBIS]
 227               RFC-Editor: To be replaced by RFC number for draft-ietf-
 228               kitten-2478bis.  Work in progress.
 229
 230    [X690]     ASN.1 encoding rules: Specification of Basic Encoding Rules
 231               (BER), Canonical Encoding Rules (CER) and Distinguished
 232               Encoding Rules (DER), ITU-T Recommendation X.690 (1997) |
 233               ISO/IEC International Standard 8825-1:1998.
 234
 235
 236 Authors' Addresses
 237
 238    Larry Zhu
 239    Microsoft Corporation
 240    One Microsoft Way
 241    Redmond, WA  98052
 242    US
 243
 244    Email: lzhu@microsoft.com
 245
 246
 247    Paul Leach
 248    Microsoft Corporation
 249    One Microsoft Way
 250    Redmond, WA  98052
 251    US
 252
 253    Email: paulle@microsoft.com
 254
 255
 256    Karthik Jaganathan
 257    Microsoft Corporation
 258    One Microsoft Way
 259    Redmond, WA  98052
 260    US
 261
 262    Email: karthikj@microsoft.com
 263
 264 Appendix A.  Leveraging this Enctype Negotiation in Windows SPNEGO
 265             Implementations
 266
 267    The SPNEGO implementations in Windows 2000, Windows XP and Windows
 268    2003 do not generate or verify the mechlistMIC field when it is
 269    required [SPNEGOBIS].
 270
 271    When the SPNEGO implementations that are updated according to
 272    [SPNEGOBIS], an SSPI initiator or acceptor needs to determine if the
 273    peer is updated, so that it can generate the mechlistMIC token when
 274    the peer can process it.  With the bidirectional negotiation, the
 275    updated SPNEGO implementation can achieve the following two goals:
 276
 277
 278
 279
 280
 281 Zhu, et al.              Expires October 2, 2005                [Page 5]
 282 \f
 283 Internet-Draft             Enctype Negotiation                March 2005
 284
 285
 286    o  It can remain backward compatible with legacy implementations, if
 287       local policy allows unsafe and unprotected negotiation with
 288       downlevel implementations when the mechlistMIC token exchange
 289       would otherwise be required by [SPNEGOBIS].
 290
 291    o  The mechanism negotiation is protected according to [SPNEGOBIS]
 292       when both peers are updated.
 293
 294    However, the updated SPNEGO implementation itself can not securely
 295    inform the peer whether the local implementation is updated, thus it
 296    has to obtain such information from the negotiated mechanism.
 297
 298    For Windows SPNEGO implementations, both the initiator and the
 299    acceptor are assumed to have been updated if a "newer" [CLAR] or
 300    different enctype is negotiated for use by the Kerberos GSS-API
 301    mechanism.
 302
 303
 304
 305
 306
 307
 308
 309
 310
 311
 312
 313
 314
 315
 316
 317
 318
 319
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337 Zhu, et al.              Expires October 2, 2005                [Page 6]
 338 \f
 339 Internet-Draft             Enctype Negotiation                March 2005
 340
 341
 342 Intellectual Property Statement
 343
 344    The IETF takes no position regarding the validity or scope of any
 345    Intellectual Property Rights or other rights that might be claimed to
 346    pertain to the implementation or use of the technology described in
 347    this document or the extent to which any license under such rights
 348    might or might not be available; nor does it represent that it has
 349    made any independent effort to identify any such rights.  Information
 350    on the procedures with respect to rights in RFC documents can be
 351    found in BCP 78 and BCP 79.
 352
 353    Copies of IPR disclosures made to the IETF Secretariat and any
 354    assurances of licenses to be made available, or the result of an
 355    attempt made to obtain a general license or permission for the use of
 356    such proprietary rights by implementers or users of this
 357    specification can be obtained from the IETF on-line IPR repository at
 358    http://www.ietf.org/ipr.
 359
 360    The IETF invites any interested party to bring to its attention any
 361    copyrights, patents or patent applications, or other proprietary
 362    rights that may cover technology that may be required to implement
 363    this standard.  Please address the information to the IETF at
 364    ietf-ipr@ietf.org.
 365
 366
 367 Disclaimer of Validity
 368
 369    This document and the information contained herein are provided on an
 370    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 371    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 372    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 373    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 374    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 375    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 376
 377
 378 Copyright Statement
 379
 380    Copyright (C) The Internet Society (2005).  This document is subject
 381    to the rights, licenses and restrictions contained in BCP 78, and
 382    except as set forth therein, the authors retain all their rights.
 383
 384
 385 Acknowledgment
 386
 387    Funding for the RFC Editor function is currently provided by the
 388    Internet Society.
 389
 390
 391
 392
 393 Zhu, et al.              Expires October 2, 2005                [Page 7]
 394 \f
 395