third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-extensions-iana-01.txt

   1
   2
   3
   4 NETWORK WORKING GROUP                                        N. Williams
   5 Internet-Draft                                                       Sun
   6 Expires: April 19, 2006                                 October 16, 2005
   7
   8
   9      Namespace Considerations and Registries for GSS-API Extensions
  10             draft-ietf-kitten-gssapi-extensions-iana-01.txt
  11
  12 Status of this Memo
  13
  14    By submitting this Internet-Draft, each author represents that any
  15    applicable patent or other IPR claims of which he or she is aware
  16    have been or will be disclosed, and any of which he or she becomes
  17    aware will be disclosed, in accordance with Section 6 of BCP 79.
  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 Internet-
  22    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 April 19, 2006.
  36
  37 Copyright Notice
  38
  39    Copyright (C) The Internet Society (2005).
  40
  41 Abstract
  42
  43    This document describes the ways in which the GSS-API may be extended
  44    and directs the creation of IANA registries for various GSS-API
  45    namespaces.
  46
  47
  48
  49
  50
  51
  52
  53
  54
  55 Williams                 Expires April 19, 2006                 [Page 1]
  56 \f
  57 Internet-Draft            GSS IANA Instructions             October 2005
  58
  59
  60 Table of Contents
  61
  62    1.  Conventions used in this document . . . . . . . . . . . . . . . 3
  63    2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
  64    3.  Extensions to the GSS-API . . . . . . . . . . . . . . . . . . . 3
  65    4.  Generic GSS-API Namespaces  . . . . . . . . . . . . . . . . . . 3
  66    5.  Language Binding-Specific GSS-API Namespaces  . . . . . . . . . 4
  67    6.  Extension-Specific GSS-API Namespaces . . . . . . . . . . . . . 4
  68    7.  Registration Form(s)  . . . . . . . . . . . . . . . . . . . . . 4
  69    8.  Initial Namespace Registrations . . . . . . . . . . . . . . . . 5
  70    9.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
  71    10. Normative . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
  72        Author's Address  . . . . . . . . . . . . . . . . . . . . . . . 6
  73        Intellectual Property and Copyright Statements  . . . . . . . . 7
  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 Williams                 Expires April 19, 2006                 [Page 2]
 112 \f
 113 Internet-Draft            GSS IANA Instructions             October 2005
 114
 115
 116 1.  Conventions used in this document
 117
 118    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 119    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 120    document are to be interpreted as described in [RFC2119].
 121
 122
 123 2.  Introduction
 124
 125    There is a need for generic and mechanism-specific extensions to the
 126    Generic Security Services Application Programming Interface (GSS-
 127    API).  As such extensions are designed and standardized, both at the
 128    IETF and elsewhere, there is a non-trivial risk of namespace
 129    pollution and conflicts.  To avoid this we set out guidelines for
 130    extending the GSS-API and create IANA registries of GSS-API
 131    namespaces.
 132
 133    The registration of name prefixes and constant value ranges is
 134    allowed so as to save the IANA the trouble of registering every GSS-
 135    API name and constant, and to allow for reservation of portions of
 136    some GSS namespaces for private extensions or extensions which lack
 137    IETF Standards-Track extensions.
 138
 139
 140 3.  Extensions to the GSS-API
 141
 142    Extensions to the GSS-API can be categorized as follows:
 143    o  Generic
 144    o  Implementation-specific
 145    o  Mechanism-specific
 146    o  Language binding-specific
 147    o  Any combination of two or all three of the last three
 148
 149    Extensions to the GSS-API may be purely semantic, without effect on
 150    the GSS-API's namespaces.  Or they may introduce new functions,
 151    constants, types, etc...; these clearly affect the GSS-API
 152    namespaces.
 153
 154    Extensions that affect the GSS-API namespaces should be registered
 155    with the IANA.
 156
 157
 158 4.  Generic GSS-API Namespaces
 159
 160    All the function, constant and type names, as well as all the
 161    constant values specified in the base GSS-API specification for the
 162    basic generic GSS-API namespace.
 163
 164
 165
 166
 167 Williams                 Expires April 19, 2006                 [Page 3]
 168 \f
 169 Internet-Draft            GSS IANA Instructions             October 2005
 170
 171
 172    The generic GSS-API namespaces are:
 173    o  Type names
 174    o  Function names
 175    o  Constant names for each type
 176    o  Constant values for each type
 177    o  Mechanism OIDs
 178    o  Name Type OIDs
 179    o  Mechanism Attribute OIDs (see [EXTENDED-INQUIRY])
 180
 181
 182 5.  Language Binding-Specific GSS-API Namespaces
 183
 184    <Add text; discuss header, module, library, class, method namespaces
 185    and whatever else comes up that is language-specific and appropriate
 186    for registration with the IANA.>
 187
 188
 189 6.  Extension-Specific GSS-API Namespaces
 190
 191    Extensions to the GSS-API may create additional namespaces.
 192    Instructions to the IANA should included for the handling of such
 193    namespaces.
 194
 195
 196 7.  Registration Form(s)
 197
 198    Registrations for GSS-API namespaces SHALL take the following form:
 199
 200    <TBD>
 201
 202    The IANA should create a single GSS-API namespace registry, or
 203    multiple registries, one for symbolic names and one for constant
 204    values, or it may create a registry per-programming language, at its
 205    convenience.
 206
 207    Entries in these registries should consist of all the fields from
 208    their corresponding registration entries.
 209
 210    Entries SHOULD be sorted by object type, proggamming language, symbol
 211    name.
 212
 213    <Add text on guidelines for IANA consideration of registration
 214    applications, particularly with respect to entries lacking normative
 215    references, "magic" entries (e.g., special values of 'time' types
 216    which indicate something other than absolute or relative time, such
 217    as GSS_C_INDEFINITE), expert review requirements (if any) for
 218    registrations lacking normative references, etc....>
 219
 220
 221
 222
 223 Williams                 Expires April 19, 2006                 [Page 4]
 224 \f
 225 Internet-Draft            GSS IANA Instructions             October 2005
 226
 227
 228 8.  Initial Namespace Registrations
 229
 230    <Add registration entries for namespaces (name prefixes) for RFC2743/
 231    RFC2744/RFC2853.>
 232
 233    <Add registration entries for private namespaces (name prefixes) for
 234    implementation- and/or platform-specific extensions.>
 235
 236
 237 9.  Security Considerations
 238
 239    This document has no security considerations.
 240
 241 10.  Normative
 242
 243    [EXTENDED-INQUIRY]
 244               Williams, N., "Extended Generic Security Service Mechanism
 245               Inquiry APIs",
 246               draft-ietf-kitten-extended-mech-inquiry-00.txt (work in
 247               progress).
 248
 249    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 250               Requirement Levels", BCP 14, RFC 2119, March 1997.
 251
 252    [RFC2743]  Linn, J., "Generic Security Service Application Program
 253               Interface Version 2, Update 1", RFC 2743, January 2000.
 254
 255    [RFC2744]  Wray, J., "Generic Security Service API Version 2 :
 256               C-bindings", RFC 2744, January 2000.
 257
 258
 259
 260
 261
 262
 263
 264
 265
 266
 267
 268
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278
 279 Williams                 Expires April 19, 2006                 [Page 5]
 280 \f
 281 Internet-Draft            GSS IANA Instructions             October 2005
 282
 283
 284 Author's Address
 285
 286    Nicolas Williams
 287    Sun Microsystems
 288    5300 Riata Trace Ct
 289    Austin, TX  78727
 290    US
 291
 292    Email: Nicolas.Williams@sun.com
 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 Williams                 Expires April 19, 2006                 [Page 6]
 336 \f
 337 Internet-Draft            GSS IANA Instructions             October 2005
 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 (2005).  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 Williams                 Expires April 19, 2006                 [Page 7]
 392 \f
 393