idnits 2.17.1 draft-ietf-kitten-gssapi-extensions-iana-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 25, 2009) is 5503 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2853 (Obsoleted by RFC 5653) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETWORK WORKING GROUP N. Williams 3 Internet-Draft Sun 4 Intended status: Standards Track March 25, 2009 5 Expires: September 26, 2009 7 Namespace Considerations and Registries for GSS-API Extensions 8 draft-ietf-kitten-gssapi-extensions-iana-05.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on September 26, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document describes the ways in which the GSS-API may be extended 47 and directs the creation of an IANA registry for various GSS-API 48 namespaces. 50 Table of Contents 52 1. Conventions used in this document . . . . . . . . . . . . 3 53 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Extensions to the GSS-API . . . . . . . . . . . . . . . . 3 55 4. Generic GSS-API Namespaces . . . . . . . . . . . . . . . . 3 56 5. Language Binding-Specific GSS-API Namespaces . . . . . . . 4 57 6. Extension-Specific GSS-API Namespaces . . . . . . . . . . 4 58 7. Registration Form . . . . . . . . . . . . . . . . . . . . 4 59 8. IANA Considerations . . . . . . . . . . . . . . . . . . . 6 60 8.1. Initial Namespace Registrations . . . . . . . . . . . . . 7 61 8.2. Registration Maintenance Guidelines . . . . . . . . . . . 7 62 8.2.1. Sub-Namespace Symbol Pattern Matching . . . . . . . . . . 7 63 8.2.2. Expert Reviews of Individual Submissions . . . . . . . . . 7 64 8.2.3. Change Control . . . . . . . . . . . . . . . . . . . . . . 8 65 9. Security Considerations . . . . . . . . . . . . . . . . . 9 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . 9 67 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 68 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 69 Author's Address . . . . . . . . . . . . . . . . . . . . . 10 71 1. Conventions used in this document 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in [RFC2119]. 77 2. Introduction 79 There is a need for private-use and mechanism-specific extensions to 80 the Generic Security Services Application Programming Interface (GSS- 81 API). As such extensions are designed and standardized (or not), 82 both at the IETF and elsewhere, there is a non-trivial risk of 83 namespace pollution and conflicts. To avoid this we set out 84 guidelines for extending the GSS-API and direct the creation of an 85 IANA registry for GSS-API namespaces. 87 Registrations of individual items and sub-namespaces are allowed. 88 Each sub-namespace may provide different rules for registration, 89 e.g., for mechanism-specific and private-use extensions. 91 3. Extensions to the GSS-API 93 Extensions to the GSS-API can be categorized as follows: 94 o Abstract API extensions 95 o Implementation-specific 96 o Mechanism-specific 97 o Language binding-specific 99 Extensions to the GSS-API may be purely semantic, without effect on 100 the GSS-API's namespaces. Or they may introduce new functions, 101 constants, types, etc...; these clearly affect the GSS-API 102 namespaces. 104 Extensions that affect the GSS-API namespaces should be registered 105 with the IANA as described herein. 107 4. Generic GSS-API Namespaces 109 The abstract API namespaces for the GSS-API are: 110 o Type names 111 o Function names 112 o Constant names for various types 113 o Constant values for various types 114 o Name types (OID, type name and syntaxes) 115 Additionally we have namespaces associates with the OBJECT IDENTIFIER 116 (OID) type. The IANA already maintains a registry of such OIDs: 117 o Mechanism OIDs 118 o Name Type OIDs 120 5. Language Binding-Specific GSS-API Namespaces 122 Language binding specific namespaces include, among others: 123 o Header/interface module names 124 o Object classes and/or types 125 o Methods and/or functions 126 o Constant names 127 o Constant values 129 6. Extension-Specific GSS-API Namespaces 131 Extensions to the GSS-API may create additional namespaces. See 132 Section 8.2. 134 7. Registration Form 136 Registrations for GSS-API namespaces SHALL take the following form: 138 +--------------+---------------------+------------------------------+ 139 | Registration | Possible Values | Description | 140 | Field | | | 141 +--------------+---------------------+------------------------------+ 142 | Registration | 'Instance', | Indicates whether this entry | 143 | type | 'Sub-Namespace' | reserves a given symbol name | 144 | | | (and possibly, constant | 145 | | | value), or whether it | 146 | | | reserves an entire | 147 | | | sub-namespace (the name is a | 148 | | | pattern) or constant value | 149 | | | range. | 150 +--------------+---------------------+------------------------------+ 151 | Bindings | 'Generic', | Indicates the name of the | 152 | | 'C-bindings', | programming language that | 153 | | 'Java', 'C#', | this registration involves, | 154 | | | is an entry for the generic | 156 | | | abstract GSS-API (i.e., not | 157 | | | specific to any programming | 158 | | | language). | 159 +--------------+---------------------+------------------------------+ 160 | Object Type | 'Data-Type', | Indicates the type of the | 161 | | 'Function', | object whose symbolic name | 162 | | 'Method', | or constant value this entry | 163 | | 'Integer', | registers. The possible | 164 | | 'String', 'OID', | values of this field depend | 165 | | 'Context-Flag', | on the programming language | 166 | | 'Name-Type', | in question, therefore they | 167 | | 'Macro', | are not all specified here. | 168 | | 'Header-File-Name', | | 169 | | 'Module-Name', | | 170 | | 'Class', etcetera | | 171 +--------------+---------------------+------------------------------+ 172 | Symbol | | symbol sub-namespace being | 174 | | | registered. See | 175 | | | Section 8.2.1 | 176 +--------------+---------------------+------------------------------+ 177 | Binding of | | the abstract API element of | 181 | | | which it is a binding | 182 | | | (OPTIONAL). | 183 +--------------+---------------------+------------------------------+ 184 | Constant | or | The value of the constant | 185 | Value/Range | | Name/Prefix>. This field is | 187 | | | present only for Instance | 188 | | | and Sub-namespace | 189 | | | registrations of Constant | 190 | | | object types. | 191 +--------------+---------------------+------------------------------+ 192 | Description | | Description of the | 193 | | | registration. Multiple | 194 | | | instances of this field may | 195 | | | result (see Section 8.2.3). | 196 +--------------+---------------------+------------------------------+ 197 | Registration | Values from | Describes the rules for | 198 | Rules | [RFC2434], such as | allocation of items that | 199 | | 'IESG Approval', | fall in this sub-namespace, | 200 | | 'Expert Review', | for entries with | 201 | | 'First Come First | Registration Type of | 202 | | Served', 'Private | Sub-namespace (OPTIONAL). | 203 | | Use', etcetera. | For private use | 204 | | | sub-namespaces the submitter | 205 | | | MUST provide the e-mail | 206 | | | address of a responsible | 207 | | | contact. | 208 | Reference | | Reference to document that | 209 | | | describes the registration, | 210 | | | if any (OPTIONAL). Multiple | 211 | | | instances of this field are | 212 | | | allowed, with one reference | 213 | | | each. | 214 +--------------+---------------------+------------------------------+ 215 | Expert | | field are allowed, with one | 218 | | | expert reviewer | 219 | | | per-instance. | 220 +--------------+---------------------+------------------------------+ 221 | Expert | | that some comments be | 223 | | | included with the | 224 | | | registration, e.g., | 225 | | | regarding security | 226 | | | considerations of the | 227 | | | registered extension. | 228 +--------------+---------------------+------------------------------+ 229 | Status | 'Registered', | Status of the registration. | 230 | | 'Obsoleted' | | 231 +--------------+---------------------+------------------------------+ 232 | Obsoleting | | Reference to document, if | 233 | Reference | | any, that obsoletes this | 234 | | | registration. Multiple | 235 | | | instances of this field are | 236 | | | allowed, with one reference | 237 | | | each. (OPTIONAL) | 238 +--------------+---------------------+------------------------------+ 240 The IANA should create a single GSS-API namespace registry, or 241 multiple registries, one for symbolic names and one for constant 242 values, and/or it may create a registry per-programming language, at 243 its convenience. 245 Entries in these registries should consist of all the fields from 246 their corresponding registration entries. 248 Entries should be sorted by: registration type, progamming language, 249 object type, and symbol name/pattern. 251 8. IANA Considerations 253 This document deals with IANA considerations throughout. 254 Specifically it creates a single registry of various kinds of things, 255 thought the IANA may instead create multiple registries each for one 256 of those kinds of things. Of particular interest may be that IANA 257 will now be the registration authority for the GSS-API name type OID 258 space. 260 8.1. Initial Namespace Registrations 262 Initial registry content corresponding to the items defined in 263 [RFC2743], [RFC2744], [RFC2853], [RFC1964] and [RFC4121] and others 264 will be supplied during the IANA review portion of the RFC publishing 265 process. The KITTEN WG chairs MUST indicate that such content has 266 been reviewed by the WG and that there is WG consensus that the 267 entries are in agreement with those RFCs. 269 8.2. Registration Maintenance Guidelines 271 Standards-Track RFCs can create new items with any non-conflicting 272 Symbol Name/Prefix value for this registry by virtue of IESG approval 273 to publish as a Standards-Track RFC -- that is, without additional 274 expert review. 276 Standards-Track RFCs can mark existing entries as obsolete, and can 277 even create conflicting entries if explicitly stated (the IESG, of 278 course, should review conflicts carefully, and may reject them). 280 IANA shall also consider submissions from individuals, and via 281 Informational and Experimental RFCs, subject to Expert Review. IANA 282 SHALL allow such registrations if a) they are not conflicting, b) 283 provided that the registration is for object types other than 284 Context-Flags, and c) subject to expert review. Guidelines for 285 expert reviews are given below. 287 8.2.1. Sub-Namespace Symbol Pattern Matching 289 Sub-namespace registrations must provide a pattern for matching 290 symbols for which the sub-namespace's registration rules apply. The 291 pattern consists of a string with the following special tokens: 292 o '*', meaning "match any string." 293 o "%m", meaning "match any mechanism family short-hand name." 294 o "%i", meaning "match any implementor vanity short-hand name." 296 For example, "GSS_%m_*" matches "GSS_krb5_foo" since "krb5" is a 297 common short-hand for the Kerberos V GSS-API mechanism [RFC1964]. 298 But "GSS_%m_*" does not match "GSS_foo_bar" unless "foo" is asserted 299 to be a short-hand for some mechanism. 301 8.2.2. Expert Reviews of Individual Submissions 302 Expert review selection SHALL be done as follows. If, at the time 303 that the IANA receives an individual submission for registration in 304 this registry, there is are any IETF Working Groups chartered to 305 produce GSS-API-related documents, then the IANA SHALL ask the chairs 306 of such WGs to be expert reviewers or to name one. If there are no 307 such WGs at that time, then the IANA SHALL ask past chairs of the 308 KITTEN WG and the author/editor of this RFC to act as expert 309 reviewers or name an alternate. 311 Expert reviewers of individual registration submissions with 312 Registration Type == Sub-namespace should check that the registration 313 request has a suitable description (which need not be sufficiently 314 detailsed for others to implement) and that the Symbol Name/Prefix is 315 sufficiently descriptive of the purpose of the sub-namespace or 316 reflective of the name of the submitter or associated company. 318 Expert reviewers of individual registration submissions with 319 Registration Type == Instance should check that the Symbol Name falls 320 under a sub-namespace controlled by the submitter. Registration of 321 such entries which do not fall under such a sub-namespace may be 322 allowed provided that they correspond to long existing non-standard 323 extensions to the GSS-API and this can be easily checked or 324 demonstrated, otherwise IESG Protocol Action is REQUIRED (see 325 previous section). Also, reviewers should check that any 326 registration of constant values have a detailed description that is 327 suitable for other implementors to reproduce, and that they don't 328 conflict with other usages or are otherwise dangerous in the 329 reviewers estimation. 331 Expert reviewers should review impact on mechanisms, security and 332 interoperability, and may reject or annotate registrations which can 333 have mechanism impact that requires IESG protocol action. Consider, 334 for example, new versions of GSS_Init_sec_context() and/or 335 GSS_Accept_sec_context which have new input and/or output parameters 336 which imply changes on the wire or in behaviour that may result in 337 interoperability issues. A reviewer could choose to add notes to the 338 registration describing such issues, or the reviewer might conclude 339 that the danger to Internet interoperability is sufficient to warrant 340 rejecting the registration. 342 8.2.3. Change Control 344 Registered entries may be marked obsoleted using the same expert 345 review process as for registering entries. Obsoleted entries are 346 not, however, to be deleted, but merely marked having Obsoleted 347 Status. Note that entries may be created as obsoleted to record the 348 fact that the given symbol(s) have been used before, even though 349 continued use of them is discouraged. 351 Registered entries may also be updated in two other ways: additional 352 references, obsoleting references, and descriptions may be added. 354 All changes are subject to expert review. The submitter of a change 355 request need not be the same as the original submitter. 357 Registrations may be modified by addtion, but under no circumstance 358 may any fields be modified except for the Status field. 360 The IANA SHALL add a field describing the date that a an addition or 361 modification was made, and a description of the change. 363 9. Security Considerations 365 General security considerations relating to IANA registration 366 services apply; see [RFC2434]. 368 Also, expert reviewers should look for and may document security 369 related issues with submitters' GSS-API extensions, to the best of 370 the reviewers' ability given the information furnished by the 371 submitter. Reviewers may add comments regarding their limited 372 ability to review a submission for security problems if the submitter 373 is unwilling to provide sufficient documentation. 375 10. References 377 10.1. Normative References 379 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 380 Requirement Levels", BCP 14, RFC 2119, March 1997. 382 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 383 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 384 October 1998. 386 10.2. Informative References 388 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 389 RFC 1964, June 1996. 391 [RFC2743] Linn, J., "Generic Security Service Application Program 392 Interface Version 2, Update 1", RFC 2743, January 2000. 394 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 395 C-bindings", RFC 2744, January 2000. 397 [RFC2853] Kabat, J. and M. Upadhyay, "Generic Security Service API 398 Version 2 : Java Bindings", RFC 2853, June 2000. 400 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 401 Version 5 Generic Security Service Application Program 402 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 403 July 2005. 405 Author's Address 407 Nicolas Williams 408 Sun Microsystems 409 5300 Riata Trace Ct 410 Austin, TX 78727 411 US 413 Email: Nicolas.Williams@sun.com