doc/standardisation/draft-josefsson-krb-tcp-expansion-02.txt

   1
   2
   3
   4 Network Working Group                                       S. Josefsson
   5 Internet-Draft                                                       SJD
   6 Updates: 4120 (if approved)                               April 23, 2006
   7 Expires: October 25, 2006
   8
   9
  10 Extended Kerberos Version 5 Key Distribution Center (KDC) Exchanges Over
  11                                   TCP
  12                   draft-josefsson-krb-tcp-expansion-02
  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 October 25, 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 October 25, 2006                [Page 1]
  56 \f
  57 Internet-Draft          Kerberos V5 TCP extension             April 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 October 25, 2006                [Page 2]
 112 \f
 113 Internet-Draft          Kerberos V5 TCP extension             April 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 MUST NOT close the
 153    connection, and MUST 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    The behaviour when more than one non-high bit is set depends on the
 161    particular extension mechanisms.  If a requested extension (bit X)
 162    does not specify how it interact with another requested extensions
 163    (bit Y), the KDC MUST treat the request as a PROBE or unsupported
 164
 165
 166
 167 Josefsson               Expires October 25, 2006                [Page 3]
 168 \f
 169 Internet-Draft          Kerberos V5 TCP extension             April 2006
 170
 171
 172    extension, and proceed as above.
 173
 174    Each extension MUST describe the structure of protocol data beyond
 175    the length field, and the behaviour of the client and KDC.  If an
 176    extension mechanism reserve multiple bits, it MUST describe how they
 177    interact.
 178
 179
 180 4.  Interoperability Consideration
 181
 182    Implementations with support for TCP that do not claim to conform to
 183    RFC 4120 may not handle the high bit correctly.  Behaviour may
 184    include closing the TCP connection without any response, and logging
 185    an error message in the KDC log.  When this was written, this problem
 186    existed in modern versions of popular implementations.
 187    Implementations experiencing trouble getting the expected responses
 188    from a server SHOULD assume that it does not support this extension
 189    mechanism.  Clients MAY remember this semi-permanently, to avoid
 190    excessive logging in the server.  Care should be taken to avoid
 191    unexpected behaviour for the user when the KDC is eventually
 192    upgraded.  How to handle these backwards compatibility quirks are in
 193    general left unspecified.
 194
 195
 196 5.  Security Considerations
 197
 198    Because the initial length field is not protected, it is possible for
 199    an active attacker (i.e., one that is able to modify traffic between
 200    the client and the KDC) to make it appear to the client that the
 201    server does not support this extension mechanism.  Client and KDC
 202    policies can be used to reject connections that does not use any
 203    expansion.
 204
 205
 206 6.  IANA Considerations
 207
 208    IANA needs to create a new registry for "Kerberos 5 TCP Extensions".
 209    The initial contents of this registry should be:
 210
 211    [[RFC Editor: Replace xxxx below with the number of this RFC.]]
 212
 213    Bit #         Meaning                             Reference
 214    -----         -------                             ---------
 215    0..29         AVAILABLE for registration.
 216    30            RESERVED.                           RFC XXXX
 217
 218    IANA will register values 0 to 29 after IESG Approval, as defined in
 219    BCP 64 [2].  Assigning value 30 requires a Standards Action.
 220
 221
 222
 223 Josefsson               Expires October 25, 2006                [Page 4]
 224 \f
 225 Internet-Draft          Kerberos V5 TCP extension             April 2006
 226
 227
 228 7.  Acknowledgements
 229
 230    Thanks to Andrew Bartlett who pointed out that some implementations
 231    (MIT Kerberos and Heimdal) did not follow RFC 4120 properly with
 232    regards to the high bit, which resulted in an Interoperability
 233    Consideration.
 234
 235    Nicolas Williams and Jeffrey Hutzelman provided comments that
 236    improved the document.
 237
 238 8.  Normative References
 239
 240    [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
 241         Levels", BCP 14, RFC 2119, March 1997.
 242
 243    [2]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
 244         Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
 245
 246    [3]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos
 247         Network Authentication Service (V5)", RFC 4120, July 2005.
 248
 249
 250 Appendix A.  Copying conditions
 251
 252    Regarding this entire document or any portion of it, the author makes
 253    no guarantees and is not responsible for any damage resulting from
 254    its use.  The author grants irrevocable permission to anyone to use,
 255    modify, and distribute it in any way that does not diminish the
 256    rights of anyone else to use, modify, and distribute it, provided
 257    that redistributed derivative works do not contain misleading author
 258    or version information.  Derivative works need not be licensed under
 259    similar terms.
 260
 261
 262
 263
 264
 265
 266
 267
 268
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278
 279 Josefsson               Expires October 25, 2006                [Page 5]
 280 \f
 281 Internet-Draft          Kerberos V5 TCP extension             April 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 October 25, 2006                [Page 6]
 336 \f
 337 Internet-Draft          Kerberos V5 TCP extension             April 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 October 25, 2006                [Page 7]
 392 \f