doc/standardisation/draft-ietf-krb-wg-tcp-expansion-00.txt

   1
   2
   3
   4 Network Working Group                                       S. Josefsson
   5 Internet-Draft                                                       SJD
   6 Updates: 4120 (if approved)                                 May 10, 2006
   7 Expires: November 11, 2006
   8
   9
  10 Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges Over
  11                                   TCP
  12                    draft-ietf-krb-wg-tcp-expansion-00
  13
  14 Status of this Memo
  15
  16    By submitting this Internet-Draft, each author represents that any
  17    applicable patent or other IPR claims of which he or she is aware
  18    have been or will be disclosed, and any of which he or she becomes
  19    aware will be disclosed, in accordance with Section 6 of BCP 79.
  20
  21    Internet-Drafts are working documents of the Internet Engineering
  22    Task Force (IETF), its areas, and its working groups.  Note that
  23    other groups may also distribute working documents as Internet-
  24    Drafts.
  25
  26    Internet-Drafts are draft documents valid for a maximum of six months
  27    and may be updated, replaced, or obsoleted by other documents at any
  28    time.  It is inappropriate to use Internet-Drafts as reference
  29    material or to cite them other than as "work in progress."
  30
  31    The list of current Internet-Drafts can be accessed at
  32    http://www.ietf.org/ietf/1id-abstracts.txt.
  33
  34    The list of Internet-Draft Shadow Directories can be accessed at
  35    http://www.ietf.org/shadow.html.
  36
  37    This Internet-Draft will expire on November 11, 2006.
  38
  39 Copyright Notice
  40
  41    Copyright (C) The Internet Society (2006).
  42
  43 Abstract
  44
  45    This document describes an extensibility mechanism for the Kerberos
  46    v5 protocol when used over TCP transports.
  47
  48
  49
  50
  51
  52
  53
  54
  55 Josefsson               Expires November 11, 2006               [Page 1]
  56 \f
  57 Internet-Draft          Kerberos V5 TCP extension               May 2006
  58
  59
  60 Table of Contents
  61
  62    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
  63    2.  Conventions used in this document . . . . . . . . . . . . . . . 3
  64    3.  Extension Mechanism for TCP transport . . . . . . . . . . . . . 3
  65    4.  Interoperability Consideration  . . . . . . . . . . . . . . . . 4
  66    5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
  67    6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
  68    7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
  69    8.  Normative References  . . . . . . . . . . . . . . . . . . . . . 5
  70    Appendix A.  Copying conditions . . . . . . . . . . . . . . . . . . 5
  71    Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6
  72    Intellectual Property and Copyright Statements  . . . . . . . . . . 7
  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
 111 Josefsson               Expires November 11, 2006               [Page 2]
 112 \f
 113 Internet-Draft          Kerberos V5 TCP extension               May 2006
 114
 115
 116 1.  Introduction
 117
 118    The Kerberos 5 [3] specification, in section 7.2.2, reserve the high
 119    order bit in the initial length field for TCP transport for future
 120    expansion.  This document update [3] to describe the behaviour when
 121    that bit is set.  This mechanism is intended for extensions that are
 122    specific for the TCP transport.
 123
 124
 125 2.  Conventions used in this document
 126
 127    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 128    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 129    document are to be interpreted as described in RFC 2119 [1].
 130
 131
 132 3.  Extension Mechanism for TCP transport
 133
 134    The reserved high bit of the request length field is used to signal
 135    the use of this extension mechanism.  When the reserved high bit is
 136    set, the remaining 31 bits of the initial 4 octets are interpreted as
 137    a bitmap.  Each bit in the bitmask can be used to request a
 138    particular extension.  The 31 bits form the "extension bitmask".  It
 139    is expected that other documents will describe the details associated
 140    with particular bits.
 141
 142    A 4-octet value with only the high bit set, and thus the extension
 143    bitmask all zeros, is called a PROBE.  A client may send a probe to
 144    find out which extensions a KDC support.  A client may also set
 145    particular bits in the extension bitmask directly, if it does not
 146    need to query the KDC for available extensions before deciding which
 147    extension to request.
 148
 149    If a KDC receive a PROBE, or if a KDC does not support all extensions
 150    corresponding to set bits in the extension bitmask, the KDC MUST
 151    return 4 octets with the high bit set, and with the remaining bitmask
 152    indicate which extensions it supports.  The KDC SHOULD NOT close the
 153    connection, and SHOULD wait for the client to then send a second
 154    4-octet value, with the high bit set and the remaining bits as the
 155    bitmask, to request a particular extension.  If the second 4-octet
 156    value is a PROBE or an unsupported extension, the KDC MUST close the
 157    connection.  This is used by the client to shutdown a session when
 158    the KDC did not support a, by the client, required extension.
 159
 160    Resource avaibility considerations may influence whether, and for how
 161    long, the KDC will wait for the client to send requests.
 162
 163    The behaviour when more than one non-high bit is set depends on the
 164
 165
 166
 167 Josefsson               Expires November 11, 2006               [Page 3]
 168 \f
 169 Internet-Draft          Kerberos V5 TCP extension               May 2006
 170
 171
 172    particular extension mechanisms.  If a requested extension (bit X)
 173    does not specify how it interact with another requested extensions
 174    (bit Y), the KDC MUST treat the request as a PROBE or unsupported
 175    extension, and proceed as above.
 176
 177    Each extension MUST describe the structure of protocol data beyond
 178    the length field, and the behaviour of the client and KDC.  If an
 179    extension mechanism reserve multiple bits, it MUST describe how they
 180    interact.
 181
 182
 183 4.  Interoperability Consideration
 184
 185    Implementations with support for TCP that do not claim to conform to
 186    RFC 4120 may not handle the high bit correctly.  Behaviour may
 187    include closing the TCP connection without any response, and logging
 188    an error message in the KDC log.  When this was written, this problem
 189    existed in modern versions of popular implementations.
 190    Implementations experiencing trouble getting the expected responses
 191    from a server SHOULD assume that it does not support this extension
 192    mechanism.  Clients MAY remember this semi-permanently, to avoid
 193    excessive logging in the server.  Care should be taken to avoid
 194    unexpected behaviour for the user when the KDC is eventually
 195    upgraded.  Implementations MAY also provide a way to enable and
 196    disable this extension on a per-realm basis.  How to handle these
 197    backwards compatibility quirks are in general left unspecified.
 198
 199
 200 5.  Security Considerations
 201
 202    Because the initial length field is not protected, it is possible for
 203    an active attacker (i.e., one that is able to modify traffic between
 204    the client and the KDC) to make it appear to the client that the
 205    server does not support this extension mechanism.  Client and KDC
 206    policies can be used to reject connections that does not use any
 207    expansion.
 208
 209
 210 6.  IANA Considerations
 211
 212    IANA needs to create a new registry for "Kerberos 5 TCP Extensions".
 213    The initial contents of this registry should be:
 214
 215    [[RFC Editor: Replace xxxx below with the number of this RFC.]]
 216
 217    Bit #         Meaning                             Reference
 218    -----         -------                             ---------
 219    0..29         AVAILABLE for registration.
 220
 221
 222
 223 Josefsson               Expires November 11, 2006               [Page 4]
 224 \f
 225 Internet-Draft          Kerberos V5 TCP extension               May 2006
 226
 227
 228    30            RESERVED.                           RFC XXXX
 229
 230    IANA will register values 0 to 29 after IESG Approval, as defined in
 231    BCP 64 [2].  Assigning value 30 requires a Standards Action that
 232    update or obsolete this document.
 233
 234
 235 7.  Acknowledgements
 236
 237    Thanks to Andrew Bartlett who pointed out that some implementations
 238    (MIT Kerberos and Heimdal) did not follow RFC 4120 properly with
 239    regards to the high bit, which resulted in an Interoperability
 240    Consideration.
 241
 242    Nicolas Williams and Jeffrey Hutzelman provided comments that
 243    improved the document.
 244
 245 8.  Normative References
 246
 247    [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
 248         Levels", BCP 14, RFC 2119, March 1997.
 249
 250    [2]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
 251         Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
 252
 253    [3]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos
 254         Network Authentication Service (V5)", RFC 4120, July 2005.
 255
 256
 257 Appendix A.  Copying conditions
 258
 259    Copyright (C) 2005, 2006 Simon Josefsson
 260
 261    Regarding this entire document or any portion of it, the author makes
 262    no guarantees and is not responsible for any damage resulting from
 263    its use.  The author grants irrevocable permission to anyone to use,
 264    modify, and distribute it in any way that does not diminish the
 265    rights of anyone else to use, modify, and distribute it, provided
 266    that redistributed derivative works do not contain misleading author
 267    or version information.  Derivative works need not be licensed under
 268    similar terms.
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278
 279 Josefsson               Expires November 11, 2006               [Page 5]
 280 \f
 281 Internet-Draft          Kerberos V5 TCP extension               May 2006
 282
 283
 284 Author's Address
 285
 286    Simon Josefsson
 287    SJD
 288
 289    Email: simon@josefsson.org
 290
 291
 292
 293
 294
 295
 296
 297
 298
 299
 300
 301
 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 Josefsson               Expires November 11, 2006               [Page 6]
 336 \f
 337 Internet-Draft          Kerberos V5 TCP extension               May 2006
 338
 339
 340 Intellectual Property Statement
 341
 342    The IETF takes no position regarding the validity or scope of any
 343    Intellectual Property Rights or other rights that might be claimed to
 344    pertain to the implementation or use of the technology described in
 345    this document or the extent to which any license under such rights
 346    might or might not be available; nor does it represent that it has
 347    made any independent effort to identify any such rights.  Information
 348    on the procedures with respect to rights in RFC documents can be
 349    found in BCP 78 and BCP 79.
 350
 351    Copies of IPR disclosures made to the IETF Secretariat and any
 352    assurances of licenses to be made available, or the result of an
 353    attempt made to obtain a general license or permission for the use of
 354    such proprietary rights by implementers or users of this
 355    specification can be obtained from the IETF on-line IPR repository at
 356    http://www.ietf.org/ipr.
 357
 358    The IETF invites any interested party to bring to its attention any
 359    copyrights, patents or patent applications, or other proprietary
 360    rights that may cover technology that may be required to implement
 361    this standard.  Please address the information to the IETF at
 362    ietf-ipr@ietf.org.
 363
 364
 365 Disclaimer of Validity
 366
 367    This document and the information contained herein are provided on an
 368    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 369    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 370    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 371    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 372    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 373    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 374
 375
 376 Copyright Statement
 377
 378    Copyright (C) The Internet Society (2006).  This document is subject
 379    to the rights, licenses and restrictions contained in BCP 78, and
 380    except as set forth therein, the authors retain all their rights.
 381
 382
 383 Acknowledgment
 384
 385    Funding for the RFC Editor function is currently provided by the
 386    Internet Society.
 387
 388
 389
 390
 391 Josefsson               Expires November 11, 2006               [Page 7]
 392 \f