idnits 2.17.1 draft-ietf-kitten-gssapi-extensions-iana-03.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 349. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 360. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 367. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 373. 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 24, 2008) is 5876 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 25, 2008 March 24, 2008 6 Namespace Considerations and Registries for GSS-API Extensions 7 draft-ietf-kitten-gssapi-extensions-iana-03.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 25, 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(s) . . . . . . . . . . . . . . . . . . . 4 53 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 6 54 8.1. Initial Namespace Registrations . . . . . . . . . . . . . . 6 55 8.2. Registration Maintenance Guidelines . . . . . . . . . . . . 6 56 8.2.1. Expert Reviews of Individual Submissions . . . . . . . . . 7 57 9. Security Considerations . . . . . . . . . . . . . . . . . . 7 58 10. References . . . . . . . . . . . . . . . . . . . . . . . . 8 59 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 60 10.2. Informative References . . . . . . . . . . . . . . . . . . 8 61 Author's Address . . . . . . . . . . . . . . . . . . . . . 8 62 Intellectual Property and Copyright Statements . . . . . . 9 64 1. Conventions used in this document 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in [RFC2119]. 70 2. Introduction 72 There is a need for private-use and mechanism-specific extensions to 73 the Generic Security Services Application Programming Interface (GSS- 74 API). As such extensions are designed and standardized (or not), 75 both at the IETF and elsewhere, there is a non-trivial risk of 76 namespace pollution and conflicts. To avoid this we set out 77 guidelines for extending the GSS-API and direct the creation of an 78 IANA registry for GSS-API namespaces. 80 Registrations of individual items and sub-namespaces are allowed. 81 Each sub-namespace may provide different rules for registration, 82 e.g., for mechanism-specific and private-use extensions. All 83 Standards-Track uses of the GSS-API namespaces will be registered as 84 part of the RFC publication process. See Section 8.2. 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 each type 108 o Constant values for each type 109 o Name types (OID, type name and syntaxes) 111 Additionally we have namespaces associates with the OBJECT IDENTIFIER 112 (OID) type: 113 o Mechanism OIDs 114 o Name Type OIDs 116 5. Language Binding-Specific GSS-API Namespaces 118 Language binding specific namespaces include: 119 o Header/interface module names 120 o Object classes and/or types 121 o Methods and/or functions 122 o Constant names 123 o Constant values 125 6. Extension-Specific GSS-API Namespaces 127 Extensions to the GSS-API may create additional namespaces. See 128 Section 8.2. 130 7. Registration Form(s) 132 Registrations for GSS-API namespaces SHALL take the following form: 134 +----------------+--------------------+-----------------------------+ 135 | Registration | Possible Values | Description | 136 | Field | | | 137 +----------------+--------------------+-----------------------------+ 138 | Registration | 'Instance', | Indicates whether this | 139 | type | 'Sub-Namespace' | entry reserves a given | 140 | | | symbol name (and possibly, | 141 | | | constant value), or whether | 142 | | | it reserves an entire | 143 | | | sub-namespace (the name is | 144 | | | a "prefix") or constant | 145 | | | value range. | 146 +----------------+--------------------+-----------------------------+ 147 | Bindings | 'Generic', | Indicates the name of the | 148 | | 'C-bindings', | programming language that | 149 | | 'Java', 'C#', | this registration involves, | 150 | | | is an entry for the generic | 152 | | | abstract GSS-API (i.e., not | 153 | | | specific to any programming | 154 | | | language). | 155 +----------------+--------------------+-----------------------------+ 156 | Object Type | 'Data-Type', | Indicates the type of the | 157 | | 'Function', | object(s) whose symbolic | 158 | | 'Method', | name or constant value this | 159 | | 'Integer', | entry registers. The | 160 | | 'String', 'OID', | possible values of this | 161 | | 'Context Flag', | field depend on the | 162 | | 'Name Type', | programming language in | 163 | | 'Header File | question, therefore they | 164 | | Name', etcetera | are not all specified here. | 165 +----------------+--------------------+-----------------------------+ 166 | Symbol | | values being registered. | 168 +----------------+--------------------+-----------------------------+ 169 | Binding of | | names the abstract API | 173 | | | element of which it is a | 174 | | | binding (OPTIONAL). | 175 +----------------+--------------------+-----------------------------+ 176 | Constant | | The value(s) of the | 177 | Value/Range(s) | or | | 179 | | | (OPTIONAL). | 180 +----------------+--------------------+-----------------------------+ 181 | Description | | Description of object(s) | 182 | | | being registered. | 183 +----------------+--------------------+-----------------------------+ 184 | Registration | Values from | Describes the rules for | 185 | Rules | [RFC2434], such as | allocation of items that | 186 | | 'IESG Approval', | fall in this sub-namespace, | 187 | | 'Expert Review', | for entries with Rgistratio | 188 | | 'First Come First | Type of Sub-namespace | 189 | | Served', 'Private | (OPTIONAL). For private use | 190 | | Use', etcetera. | sub-namespaces the | 191 | | | submitter MUST provide the | 192 | | | e-mail address of a | 193 | | | responsible contact. | 194 +----------------+--------------------+-----------------------------+ 195 | Reference | | Reference to document that | 196 | | | describes the object(s) | 197 | | | being registered, if any | 198 | | | (OPTIONAL). | 199 +----------------+--------------------+-----------------------------+ 200 | Expert | | | 203 +----------------+--------------------+-----------------------------+ 204 | Status | 'Standards-Track', | Status of the registration. | 205 | | 'Informational', | | 206 | | 'Experimental', | | 207 | | 'Obsolete', | | 208 | | 'Other' | | 209 +----------------+--------------------+-----------------------------+ 211 The IANA should create a single GSS-API namespace registry, or 212 multiple registries, one for symbolic names and one for constant 213 values, and/or it may create a registry per-programming language, at 214 its convenience. 216 Entries in these registries should consist of all the fields from 217 their corresponding registration entries. 219 Entries should be sorted by: registration type, progamming language, 220 object type, and symbol name/prefix. 222 8. IANA Considerations 224 This document deals with IANA considerations throughout. 225 Specifically it creates a single registry of various kinds of things, 226 thought the IANA may instead create multiple registries each for one 227 of those kinds of things. Of particular interest may be that IANA 228 will now be the registration authority for the GSS-API name type OID 229 space. 231 8.1. Initial Namespace Registrations 233 Initial registry content corresponding to the items defined in 234 [RFC2743], [RFC2744], [RFC2853], [RFC1964] and [RFC4121] and others 235 will be supplied during the IANA review portion of the RFC publishing 236 process. The KITTEN WG chairs MUST indicate that such content has 237 been reviewed by the WG and that there is WG consensus that the 238 entries are in agreement with those RFCs. 240 8.2. Registration Maintenance Guidelines 242 Standards-Track RFCs can create new items with any non-conflicting 243 Symbol Name/Prefix value for this registry by virtue of IESG approval 244 to publish as a Standards-Track RFC. The status of such entries 245 SHALL initially be as specified by the RFC (defaulting to 'Standards- 246 Track'). 248 Standards-Track RFCs can mark existing entries as obsolete or 249 historic, and can even create conflicting entries if explicitly 250 stated (the IESG, of course, should review conflicts very carefully). 252 IANA shall also consider submissions from individuals, and via 253 Informational and Experimental RFCs, subject to Expert Review. IANA 254 SHALL allow such registrations if a) they are not conflicting, and b) 255 if expert review passes. Guidelines for expert reviews are given 256 below. The Status of any such registrations SHALL agree with the 257 Status of the source RFC, or, for individual registrations, 'Other'. 259 8.2.1. Expert Reviews of Individual Submissions 261 Expert review selection SHALL be as follows. If, at the time that 262 the IANA receives an individual submission for registration in this 263 registry, there is are any IETF Working Groups chartered to produce 264 GSS-API-related documents, then the IANA SHALL ask the chairs of such 265 WGs to be expert reviewers or to name one. If there are no such WGs 266 at that time, then the IANA SHALL ask past chairs of the KITTEN WG 267 and the author/editor of this RFC to act as expert reviewers or name 268 an alternate. 270 Expert reviewers of individual registration submissions with 271 Registration Type == Sub-namespace should check that the registration 272 request has a suitable description (which need not be sufficiently 273 detailsed for others to implement) and that the Symbol Name/Prefix is 274 sufficiently descriptive of the purpose of the sub-namespace or the 275 name of the submitter or associated company. 277 Expert reviewers of individual registration submissions with 278 Registration Type == Instance should check that the Symbol Name falls 279 under a sub-namespace controlled by the submitter and that the Status 280 of the submission is "Informational." Registration of such entries 281 which do not fall under such a sub-namespace may be allowed provided 282 that they correspond to long existing non-standard extensions to the 283 GSS-API and this can be easily checked or demonstrated, otherwise 284 IESG Protocol Action is REQUIRED (see previous section). Also, 285 reviewers should check that any registration of constant values for 286 types which have Standard-Track status have a detailed description 287 that is suitable for other implementors to reproduce, and that they 288 don't conflict with other usages or are otherwise dangerous in the 289 reviewers estimation. 291 9. Security Considerations 293 This document has no security considerations. 295 10. References 297 10.1. Normative References 299 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 300 Requirement Levels", BCP 14, RFC 2119, March 1997. 302 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 303 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 304 October 1998. 306 10.2. Informative References 308 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", 309 RFC 1964, June 1996. 311 [RFC2743] Linn, J., "Generic Security Service Application Program 312 Interface Version 2, Update 1", RFC 2743, January 2000. 314 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 315 C-bindings", RFC 2744, January 2000. 317 [RFC2853] Kabat, J. and M. Upadhyay, "Generic Security Service API 318 Version 2 : Java Bindings", RFC 2853, June 2000. 320 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 321 Version 5 Generic Security Service Application Program 322 Interface (GSS-API) Mechanism: Version 2", RFC 4121, 323 July 2005. 325 Author's Address 327 Nicolas Williams 328 Sun Microsystems 329 5300 Riata Trace Ct 330 Austin, TX 78727 331 US 333 Email: Nicolas.Williams@sun.com 335 Full Copyright Statement 337 Copyright (C) The IETF Trust (2008). 339 This document is subject to the rights, licenses and restrictions 340 contained in BCP 78, and except as set forth therein, the authors 341 retain all their rights. 343 This document and the information contained herein are provided on an 344 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 345 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 346 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 347 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 348 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 349 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 351 Intellectual Property 353 The IETF takes no position regarding the validity or scope of any 354 Intellectual Property Rights or other rights that might be claimed to 355 pertain to the implementation or use of the technology described in 356 this document or the extent to which any license under such rights 357 might or might not be available; nor does it represent that it has 358 made any independent effort to identify any such rights. Information 359 on the procedures with respect to rights in RFC documents can be 360 found in BCP 78 and BCP 79. 362 Copies of IPR disclosures made to the IETF Secretariat and any 363 assurances of licenses to be made available, or the result of an 364 attempt made to obtain a general license or permission for the use of 365 such proprietary rights by implementers or users of this 366 specification can be obtained from the IETF on-line IPR repository at 367 http://www.ietf.org/ipr. 369 The IETF invites any interested party to bring to its attention any 370 copyrights, patents or patent applications, or other proprietary 371 rights that may cover technology that may be required to implement 372 this standard. Please address the information to the IETF at 373 ietf-ipr@ietf.org. 375 Acknowledgment 377 Funding for the RFC Editor function is provided by the IETF 378 Administrative Support Activity (IASA).