idnits 2.17.1 draft-ietf-kitten-gssapi-extensions-iana-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 424. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 435. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 442. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 448. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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, 2008) is 5874 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 (~~), 2 warnings (==), 8 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 Expires: September 26, 2008 March 25, 2008 6 Namespace Considerations and Registries for GSS-API Extensions 7 draft-ietf-kitten-gssapi-extensions-iana-04.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on September 26, 2008. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2008). 38 Abstract 40 This document describes the ways in which the GSS-API may be extended 41 and directs the creation of an IANA registry for various GSS-API 42 namespaces. 44 Table of Contents 46 1. Conventions used in this document . . . . . . . . . . . . 3 47 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 48 3. Extensions to the GSS-API . . . . . . . . . . . . . . . . 3 49 4. Generic GSS-API Namespaces . . . . . . . . . . . . . . . . 3 50 5. Language Binding-Specific GSS-API Namespaces . . . . . . . 4 51 6. Extension-Specific GSS-API Namespaces . . . . . . . . . . 4 52 7. Registration Form . . . . . . . . . . . . . . . . . . . . 4 53 8. IANA Considerations . . . . . . . . . . . . . . . . . . . 6 54 8.1. Initial Namespace Registrations . . . . . . . . . . . . . 7 55 8.2. Registration Maintenance Guidelines . . . . . . . . . . . 7 56 8.2.1. Sub-Namespace Symbol Pattern Matching . . . . . . . . . . 7 57 8.2.2. Expert Reviews of Individual Submissions . . . . . . . . . 7 58 8.2.3. Change Control . . . . . . . . . . . . . . . . . . . . . . 8 59 9. Security Considerations . . . . . . . . . . . . . . . . . 9 60 10. References . . . . . . . . . . . . . . . . . . . . . . . . 9 61 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 62 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 63 Author's Address . . . . . . . . . . . . . . . . . . . . . 10 64 Intellectual Property and Copyright Statements . . . . . . 11 66 1. Conventions used in this document 68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 70 document are to be interpreted as described in [RFC2119]. 72 2. Introduction 74 There is a need for private-use and mechanism-specific extensions to 75 the Generic Security Services Application Programming Interface (GSS- 76 API). As such extensions are designed and standardized (or not), 77 both at the IETF and elsewhere, there is a non-trivial risk of 78 namespace pollution and conflicts. To avoid this we set out 79 guidelines for extending the GSS-API and direct the creation of an 80 IANA registry for GSS-API namespaces. 82 Registrations of individual items and sub-namespaces are allowed. 83 Each sub-namespace may provide different rules for registration, 84 e.g., for mechanism-specific and private-use extensions. 86 3. Extensions to the GSS-API 88 Extensions to the GSS-API can be categorized as follows: 89 o Abstract API extensions 90 o Implementation-specific 91 o Mechanism-specific 92 o Language binding-specific 94 Extensions to the GSS-API may be purely semantic, without effect on 95 the GSS-API's namespaces. Or they may introduce new functions, 96 constants, types, etc...; these clearly affect the GSS-API 97 namespaces. 99 Extensions that affect the GSS-API namespaces should be registered 100 with the IANA as described herein. 102 4. Generic GSS-API Namespaces 104 The abstract API namespaces for the GSS-API are: 105 o Type names 106 o Function names 107 o Constant names for various types 108 o Constant values for various types 109 o Name types (OID, type name and syntaxes) 110 Additionally we have namespaces associates with the OBJECT IDENTIFIER 111 (OID) type. The IANA already maintains a registry of such OIDs: 112 o Mechanism OIDs 113 o Name Type OIDs 115 5. Language Binding-Specific GSS-API Namespaces 117 Language binding specific namespaces include, among others: 118 o Header/interface module names 119 o Object classes and/or types 120 o Methods and/or functions 121 o Constant names 122 o Constant values 124 6. Extension-Specific GSS-API Namespaces 126 Extensions to the GSS-API may create additional namespaces. See 127 Section 8.2. 129 7. Registration Form 131 Registrations for GSS-API namespaces SHALL take the following form: 133 +--------------+---------------------+------------------------------+ 134 | Registration | Possible Values | Description | 135 | Field | | | 136 +--------------+---------------------+------------------------------+ 137 | Registration | 'Instance', | Indicates whether this entry | 138 | type | 'Sub-Namespace' | reserves a given symbol name | 139 | | | (and possibly, constant | 140 | | | value), or whether it | 141 | | | reserves an entire | 142 | | | sub-namespace (the name is a | 143 | | | pattern) or constant value | 144 | | | range. | 145 +--------------+---------------------+------------------------------+ 146 | Bindings | 'Generic', | Indicates the name of the | 147 | | 'C-bindings', | programming language that | 148 | | 'Java', 'C#', | this registration involves, | 149 | | | is an entry for the generic | 151 | | | abstract GSS-API (i.e., not | 152 | | | specific to any programming | 153 | | | language). | 154 +--------------+---------------------+------------------------------+ 155 | Object Type | 'Data-Type', | Indicates the type of the | 156 | | 'Function', | object whose symbolic name | 157 | | 'Method', | or constant value this entry | 158 | | 'Integer', | registers. The possible | 159 | | 'String', 'OID', | values of this field depend | 160 | | 'Context-Flag', | on the programming language | 161 | | 'Name-Type', | in question, therefore they | 162 | | 'Macro', | are not all specified here. | 163 | | 'Header-File-Name', | | 164 | | 'Module-Name', | | 165 | | 'Class', etcetera | | 166 +--------------+---------------------+------------------------------+ 167 | Symbol | | symbol sub-namespace being | 169 | | | registered. See | 170 | | | Section 8.2.1 | 171 +--------------+---------------------+------------------------------+ 172 | Binding of | | the abstract API element of | 176 | | | which it is a binding | 177 | | | (OPTIONAL). | 178 +--------------+---------------------+------------------------------+ 179 | Constant | or | The value of the constant | 180 | Value/Range | | Name/Prefix>. This field is | 182 | | | present only for Instance | 183 | | | and Sub-namespace | 184 | | | registrations of Constant | 185 | | | object types. | 186 +--------------+---------------------+------------------------------+ 187 | Description | | Description of the | 188 | | | registration. Multiple | 189 | | | instances of this field may | 190 | | | result (see Section 8.2.3). | 191 +--------------+---------------------+------------------------------+ 192 | Registration | Values from | Describes the rules for | 193 | Rules | [RFC2434], such as | allocation of items that | 194 | | 'IESG Approval', | fall in this sub-namespace, | 195 | | 'Expert Review', | for entries with | 196 | | 'First Come First | Registration Type of | 197 | | Served', 'Private | Sub-namespace (OPTIONAL). | 198 | | Use', etcetera. | For private use | 199 | | | sub-namespaces the submitter | 200 | | | MUST provide the e-mail | 201 | | | address of a responsible | 202 | | | contact. | 203 | Reference | | Reference to document that | 204 | | | describes the registration, | 205 | | | if any (OPTIONAL). Multiple | 206 | | | instances of this field are | 207 | | | allowed, with one reference | 208 | | | each. | 209 +--------------+---------------------+------------------------------+ 210 | Expert | | field are allowed, with one | 213 | | | expert reviewer | 214 | | | per-instance. | 215 +--------------+---------------------+------------------------------+ 216 | Expert | | that some comments be | 218 | | | included with the | 219 | | | registration, e.g., | 220 | | | regarding security | 221 | | | considerations of the | 222 | | | registered extension. | 223 +--------------+---------------------+------------------------------+ 224 | Status | 'Registered', | Status of the registration. | 225 | | 'Obsoleted' | | 226 +--------------+---------------------+------------------------------+ 227 | Obsoleting | | Reference to document, if | 228 | Reference | | any, that obsoletes this | 229 | | | registration. Multiple | 230 | | | instances of this field are | 231 | | | allowed, with one reference | 232 | | | each. (OPTIONAL) | 233 +--------------+---------------------+------------------------------+ 235 The IANA should create a single GSS-API namespace registry, or 236 multiple registries, one for symbolic names and one for constant 237 values, and/or it may create a registry per-programming language, at 238 its convenience. 240 Entries in these registries should consist of all the fields from 241 their corresponding registration entries. 243 Entries should be sorted by: registration type, progamming language, 244 object type, and symbol name/pattern. 246 8. IANA Considerations 248 This document deals with IANA considerations throughout. 249 Specifically it creates a single registry of various kinds of things, 250 thought the IANA may instead create multiple registries each for one 251 of those kinds of things. Of particular interest may be that IANA 252 will now be the registration authority for the GSS-API name type OID 253 space. 255 8.1. Initial Namespace Registrations 257 Initial registry content corresponding to the items defined in 258 [RFC2743], [RFC2744], [RFC2853], [RFC1964] and [RFC4121] and others 259 will be supplied during the IANA review portion of the RFC publishing 260 process. The KITTEN WG chairs MUST indicate that such content has 261 been reviewed by the WG and that there is WG consensus that the 262 entries are in agreement with those RFCs. 264 8.2. Registration Maintenance Guidelines 266 Standards-Track RFCs can create new items with any non-conflicting 267 Symbol Name/Prefix value for this registry by virtue of IESG approval 268 to publish as a Standards-Track RFC -- that is, without additional 269 expert review. 271 Standards-Track RFCs can mark existing entries as obsolete, and can 272 even create conflicting entries if explicitly stated (the IESG, of 273 course, should review conflicts carefully, and may reject them). 275 IANA shall also consider submissions from individuals, and via 276 Informational and Experimental RFCs, subject to Expert Review. IANA 277 SHALL allow such registrations if a) they are not conflicting, b) 278 provided that the registration is for object types other than 279 Context-Flags, and c) subject to expert review. Guidelines for 280 expert reviews are given below. 282 8.2.1. Sub-Namespace Symbol Pattern Matching 284 Sub-namespace registrations must provide a pattern for matching 285 symbols for which the sub-namespace's registration rules apply. The 286 pattern consists of a string with the following special tokens: 287 o '*', meaning "match any string." 288 o "%m", meaning "match any mechanism family short-hand name." 289 o "%i", meaning "match any implementor vanity short-hand name." 291 For example, "GSS_%m_*" matches "GSS_krb5_foo" since "krb5" is a 292 common short-hand for the Kerberos V GSS-API mechanism [RFC1964]. 293 But "GSS_%m_*" does not match "GSS_foo_bar" unless "foo" is asserted 294 to be a short-hand for some mechanism. 296 8.2.2. Expert Reviews of Individual Submissions 297 Expert review selection SHALL be done as follows. If, at the time 298 that the IANA receives an individual submission for registration in 299 this registry, there is are any IETF Working Groups chartered to 300 produce GSS-API-related documents, then the IANA SHALL ask the chairs 301 of such WGs to be expert reviewers or to name one. If there are no 302 such WGs at that time, then the IANA SHALL ask past chairs of the 303 KITTEN WG and the author/editor of this RFC to act as expert 304 reviewers or name an alternate. 306 Expert reviewers of individual registration submissions with 307 Registration Type == Sub-namespace should check that the registration 308 request has a suitable description (which need not be sufficiently 309 detailsed for others to implement) and that the Symbol Name/Prefix is 310 sufficiently descriptive of the purpose of the sub-namespace or 311 reflective of the name of the submitter or associated company. 313 Expert reviewers of individual registration submissions with 314 Registration Type == Instance should check that the Symbol Name falls 315 under a sub-namespace controlled by the submitter. Registration of 316 such entries which do not fall under such a sub-namespace may be 317 allowed provided that they correspond to long existing non-standard 318 extensions to the GSS-API and this can be easily checked or 319 demonstrated, otherwise IESG Protocol Action is REQUIRED (see 320 previous section). Also, reviewers should check that any 321 registration of constant values have a detailed description that is 322 suitable for other implementors to reproduce, and that they don't 323 conflict with other usages or are otherwise dangerous in the 324 reviewers estimation. 326 Expert reviewers should review impact on mechanisms, security and 327 interoperability, and may reject or annotate registrations which can 328 have mechanism impact that requires IESG protocol action. Consider, 329 for example, new versions of GSS_Init_sec_context() and/or 330 GSS_Accept_sec_context which have new input and/or output parameters 331 which imply changes on the wire or in behaviour that may result in 332 interoperability issues. A reviewer could choose to add notes to the 333 registration describing such issues, or the reviewer might conclude 334 that the danger to Internet interoperability is sufficient to warrant 335 rejecting the registration. 337 8.2.3. Change Control 339 Registered entries may be marked obsoleted using the same expert 340 review process as for registering entries. Obsoleted entries are 341 not, however, to be deleted, but merely marked having Obsoleted 342 Status. Note that entries may be created as obsoleted to record the 343 fact that the given symbol(s) have been used before, even though 344 continued use of them is discouraged. 346 Registered entries may also be updated in two other ways: additional 347 references, obsoleting references, and descriptions may be added. 349 All changes are subject to expert review. The submitter of a change 350 request need not be the same as the original submitter. 352 Registrations may be modified by addtion, but under no circumstance 353 may any fields be modified except for the Status field. 355 The IANA SHALL add a field describing the date that a an addition or 356 modification was made, and a description of the change. 358 9. Security Considerations 360 General security considerations relating to IANA registration 361 services apply; see [RFC2434]. 363 Also, expert reviewers should look for and may document security 364 related issues with submitters' GSS-API extensions, to the best of 365 the reviewers' ability given the information furnished by the 366 submitter. Reviewers may add comments regarding their limited 367 ability to review a submission for security problems if the submitter 368 is unwilling to provide sufficient documentation. 370 10. References 372 10.1. Normative References 374 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 375 Requirement Levels", BCP 14, RFC 2119, March 1997. 377 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 378 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 379 October 1998. 381 10.2. Informative References 383 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 384 RFC 1964, June 1996. 386 [RFC2743] Linn, J., "Generic Security Service Application Program 387 Interface Version 2, Update 1", RFC 2743, January 2000. 389 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 390 C-bindings", RFC 2744, January 2000. 392 [RFC2853] Kabat, J. and M. Upadhyay, "Generic Security Service API 393 Version 2 : Java Bindings", RFC 2853, June 2000. 395 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 396 Version 5 Generic Security Service Application Program 397 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 398 July 2005. 400 Author's Address 402 Nicolas Williams 403 Sun Microsystems 404 5300 Riata Trace Ct 405 Austin, TX 78727 406 US 408 Email: Nicolas.Williams@sun.com 410 Full Copyright Statement 412 Copyright (C) The IETF Trust (2008). 414 This document is subject to the rights, licenses and restrictions 415 contained in BCP 78, and except as set forth therein, the authors 416 retain all their rights. 418 This document and the information contained herein are provided on an 419 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 420 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 421 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 422 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 423 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 424 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 426 Intellectual Property 428 The IETF takes no position regarding the validity or scope of any 429 Intellectual Property Rights or other rights that might be claimed to 430 pertain to the implementation or use of the technology described in 431 this document or the extent to which any license under such rights 432 might or might not be available; nor does it represent that it has 433 made any independent effort to identify any such rights. Information 434 on the procedures with respect to rights in RFC documents can be 435 found in BCP 78 and BCP 79. 437 Copies of IPR disclosures made to the IETF Secretariat and any 438 assurances of licenses to be made available, or the result of an 439 attempt made to obtain a general license or permission for the use of 440 such proprietary rights by implementers or users of this 441 specification can be obtained from the IETF on-line IPR repository at 442 http://www.ietf.org/ipr. 444 The IETF invites any interested party to bring to its attention any 445 copyrights, patents or patent applications, or other proprietary 446 rights that may cover technology that may be required to implement 447 this standard. Please address the information to the IETF at 448 ietf-ipr@ietf.org. 450 Acknowledgment 452 Funding for the RFC Editor function is provided by the IETF 453 Administrative Support Activity (IASA).