doc/specifications/draft-ietf-krb-wg-naming-01.txt

   1
   2
   3 NETWORK WORKING GROUP                                             L. Zhu
   4 Internet-Draft                                     Microsoft Corporation
   5 Updates: 4120 (if approved)                             October 10, 2006
   6 Intended status: Standards Track
   7 Expires: April 13, 2007
   8
   9
  10                  Additional Kerberos Naming Constraits
  11                       draft-ietf-krb-wg-naming-01
  12
  13 Status of this Memo
  14
  15    By submitting this Internet-Draft, each author represents that any
  16    applicable patent or other IPR claims of which he or she is aware
  17    have been or will be disclosed, and any of which he or she becomes
  18    aware will be disclosed, in accordance with Section 6 of BCP 79.
  19
  20    Internet-Drafts are working documents of the Internet Engineering
  21    Task Force (IETF), its areas, and its working groups.  Note that
  22    other groups may also distribute working documents as Internet-
  23    Drafts.
  24
  25    Internet-Drafts are draft documents valid for a maximum of six months
  26    and may be updated, replaced, or obsoleted by other documents at any
  27    time.  It is inappropriate to use Internet-Drafts as reference
  28    material or to cite them other than as "work in progress."
  29
  30    The list of current Internet-Drafts can be accessed at
  31    http://www.ietf.org/ietf/1id-abstracts.txt.
  32
  33    The list of Internet-Draft Shadow Directories can be accessed at
  34    http://www.ietf.org/shadow.html.
  35
  36    This Internet-Draft will expire on April 13, 2007.
  37
  38 Copyright Notice
  39
  40    Copyright (C) The Internet Society (2006).
  41
  42 Abstract
  43
  44    This document defines new naming constraints for reserved Keberos
  45    names.  A reserved name can be either a Kerberos principal name or a
  46    Kerberos realm name.  All reserved names defined in this document are
  47    critical, so if a reserved name is unknown, authentication MUST fail.
  48
  49
  50
  51
  52
  53
  54 Zhu                      Expires April 13, 2007                 [Page 1]
  55 \f
  56 Internet-Draft               Kerberos Naming                October 2006
  57
  58
  59 Table of Contents
  60
  61    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
  62    2.  Conventions Used in This Document . . . . . . . . . . . . . . . 3
  63    3.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
  64      3.1.  Reserved Kerberos Principal Names . . . . . . . . . . . . . 3
  65      3.2.  Reserved Kerberos Realm Names . . . . . . . . . . . . . . . 4
  66    4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
  67    5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 4
  68    6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
  69    7.  Normative References  . . . . . . . . . . . . . . . . . . . . . 5
  70    Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 5
  71    Intellectual Property and Copyright Statements  . . . . . . . . . . 6
  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                      Expires April 13, 2007                 [Page 2]
 111 \f
 112 Internet-Draft               Kerberos Naming                October 2006
 113
 114
 115 1.  Introduction
 116
 117    Occasionally protocol designers need to designate a Kerberos
 118    principal name or a Kerberos realm name to have special meanings,
 119    other than identifying a particular instance.  An example is that the
 120    the anonymous principal name and the anonymous realm name are defined
 121    for the Kerberos anonymity support [ANON].  This anonymity name pair
 122    conveys no more meaning than that the client's identity is not
 123    disclosed.  In the case of the anonymity support, it is critical that
 124    deployed Kerberos implementations that do not support anonymity MUST
 125    fail the authentication if the anonymity name pair is used, therefore
 126    no access is granted accidentally to a principal who's name happens
 127    to match with that of the anonymous identity.
 128
 129    However Kerberos as defined in [RFC4120] does not have such reserved
 130    names.  As such, protocol designers have resolved to use exceedingly-
 131    unlikely-to-have-been-used names to avoid collision.  Even if a
 132    registry were setup to avoid collision for new implementations, there
 133    is no guarantee for deployed implementations to prevent accidental
 134    reuse of names that can lead to access being grantedly unexpectedly.
 135
 136    The Kerberos realm name in [RFC4120] has a reserved name space
 137    although no specific name is defined and the criticality of unknown
 138    reserved realm names is not specified.
 139
 140    This document is to remedy these by defining reserved Kerberos names.
 141    All reserved names defined based on this specification are critical:
 142    Authentication MUST fail if an unknown reserved name is used by
 143    conforming implementations.
 144
 145
 146 2.  Conventions Used in This Document
 147
 148    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 149    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 150    document are to be interpreted as described in [RFC2119].
 151
 152
 153 3.  Definitions
 154
 155    In this section, reserved names are defined for both the kerberos
 156    principal name and the kerberos realm name.
 157
 158 3.1.  Reserved Kerberos Principal Names
 159
 160    A new name type is defined for reserved principal names.  The
 161    Kerberos principal name is defined in Section 6.2 of [RFC4120].
 162
 163
 164
 165
 166 Zhu                      Expires April 13, 2007                 [Page 3]
 167 \f
 168 Internet-Draft               Kerberos Naming                October 2006
 169
 170
 171             KRB_NT_RESERVED                                TBA
 172
 173    The reserved principal name MUST have at least two or more
 174    KerberosString components, and the first component must be the string
 175    literal "RESERVED".
 176
 177    For implementations conforming with this specification,
 178    authentication MUST fail with
 179    KRB_AP_ERR_RESERVED_PRINCIPAL_NAME_UNKNOWN if an unknown reserved
 180    principal name is used.  There is no accompanying error data for this
 181    error.
 182
 183             KRB_AP_ERR_RESERVED_PRINCIPAL_NAME_UNKNOWN     TBA
 184                  -- a reserved Kerberos principal name is unknown
 185
 186 3.2.  Reserved Kerberos Realm Names
 187
 188    Section 6.1 of [RFC4120] defines the "other" style realm name, a new
 189    type RESERVED is defined as a name of type "other", with the NAMETYPE
 190    part filled in with the word "RESERVED".
 191
 192             other: RESERVED:realm-name
 193
 194    This name type is designated for reserved Kerberos realms.
 195
 196    For implementations conforming with this specification,
 197    authentication MUST fail with KRB_AP_ERR_RESERVED_REALM_NAME_UNKNOWN
 198    if an unknown reserved realm name is used.  There is no accompanying
 199    error data for this error.
 200
 201             KRB_AP_ERR_RESERVED_REALM_NAME_UNKNOWN         TBA
 202                  -- a reserved Kerberos realm name is unknown
 203
 204
 205 4.  Security Considerations
 206
 207    If a reserved name is unknown, authentication MUST fail.  Otherwise,
 208    access can be granted unintentionally, resulting in a security
 209    weakness.
 210
 211    Care MUST be taken to avoid accidental reuse of names.
 212
 213
 214 5.  Acknowledgements
 215
 216    The initial document was mostly based on the author's conversation
 217    with Clifford Newman and Sam Hartman.
 218
 219
 220
 221
 222 Zhu                      Expires April 13, 2007                 [Page 4]
 223 \f
 224 Internet-Draft               Kerberos Naming                October 2006
 225
 226
 227 6.  IANA Considerations
 228
 229    This document provides the framework for defining reserved Kerberos
 230    names and Kerberos realms.  A new IANA registry should be created to
 231    contain reserved Kerberos names and Kerberos realms that are defined
 232    based on this document.
 233
 234
 235 7.  Normative References
 236
 237    [ANON]     Zhu, L., Leach, P. and Jaganathan, K., "Kerberos Anonymity
 238               Support", draft-ietf-krb-wg-anon, work in progress.
 239
 240    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 241               Requirement Levels", BCP 14, RFC 2119, March 1997.
 242
 243    [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
 244               RFC 2246, January 1999.
 245
 246    [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
 247               Kerberos Network Authentication Service (V5)", RFC 4120,
 248               July 2005.
 249
 250
 251 Author's Address
 252
 253    Larry Zhu
 254    Microsoft Corporation
 255    One Microsoft Way
 256    Redmond, WA  98052
 257    US
 258
 259    Email: lzhu@microsoft.com
 260
 261
 262
 263
 264
 265
 266
 267
 268
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278
 279 Zhu                      Expires April 13, 2007                 [Page 5]
 280 \f
 281 Internet-Draft               Kerberos Naming                October 2006
 282
 283
 284 Full Copyright Statement
 285
 286    Copyright (C) The Internet Society (2006).
 287
 288    This document is subject to the rights, licenses and restrictions
 289    contained in BCP 78, and except as set forth therein, the authors
 290    retain all their rights.
 291
 292    This document and the information contained herein are provided on an
 293    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 294    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 295    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 296    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 297    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 298    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 299
 300
 301 Intellectual Property
 302
 303    The IETF takes no position regarding the validity or scope of any
 304    Intellectual Property Rights or other rights that might be claimed to
 305    pertain to the implementation or use of the technology described in
 306    this document or the extent to which any license under such rights
 307    might or might not be available; nor does it represent that it has
 308    made any independent effort to identify any such rights.  Information
 309    on the procedures with respect to rights in RFC documents can be
 310    found in BCP 78 and BCP 79.
 311
 312    Copies of IPR disclosures made to the IETF Secretariat and any
 313    assurances of licenses to be made available, or the result of an
 314    attempt made to obtain a general license or permission for the use of
 315    such proprietary rights by implementers or users of this
 316    specification can be obtained from the IETF on-line IPR repository at
 317    http://www.ietf.org/ipr.
 318
 319    The IETF invites any interested party to bring to its attention any
 320    copyrights, patents or patent applications, or other proprietary
 321    rights that may cover technology that may be required to implement
 322    this standard.  Please address the information to the IETF at
 323    ietf-ipr@ietf.org.
 324
 325
 326 Acknowledgment
 327
 328    Funding for the RFC Editor function is provided by the IETF
 329    Administrative Support Activity (IASA).
 330
 331
 332
 333
 334
 335 Zhu                      Expires April 13, 2007                 [Page 6]
 336 \f
 337