idnits 2.17.1 draft-ietf-kitten-gssapi-extensions-iana-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 (January 13, 2015) is 3388 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 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 2853 (Obsoleted by RFC 5653) Summary: 1 error (**), 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 Cryptonector LLC 4 Intended status: Standards Track A. Melnikov 5 Expires: July 17, 2015 Isode Ltd 6 January 13, 2015 8 Namespace Considerations and Registries for GSS-API Extensions 9 draft-ietf-kitten-gssapi-extensions-iana-10.txt 11 Abstract 13 This document describes the ways in which the GSS-API may be extended 14 and directs the creation of an IANA registry for various GSS-API 15 namespaces. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on July 17, 2015. 34 Copyright Notice 36 Copyright (c) 2015 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Conventions used in this document . . . . . . . . . . . . . . 2 52 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 3. Extensions to the GSS-API . . . . . . . . . . . . . . . . . . 2 54 4. Generic GSS-API Namespaces . . . . . . . . . . . . . . . . . 3 55 5. Language Binding-Specific GSS-API Namespaces . . . . . . . . 3 56 6. Extension-Specific GSS-API Namespaces . . . . . . . . . . . . 4 57 7. Registration Form . . . . . . . . . . . . . . . . . . . . . . 4 58 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 59 8.1. Initial Namespace Registrations . . . . . . . . . . . . . . 7 60 8.1.1. Example registrations . . . . . . . . . . . . . . . . . . 7 61 8.2. Registration Maintenance Guidelines . . . . . . . . . . . . 9 62 8.2.1. Sub-Namespace Symbol Pattern Matching . . . . . . . . . . 10 63 8.2.2. Expert Reviews of Individual Submissions . . . . . 10 64 8.2.3. Change Control . . . . . . . . . . . . . . . . . . . . . 11 65 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 66 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 68 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 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: 95 o Abstract API extensions 96 o Implementation-specific 98 o Mechanism-specific 100 o Language binding-specific 102 Extensions to the GSS-API may be purely semantic, without effect on 103 the GSS-API's namespaces. Or they may introduce new functions, 104 constants, types, etc...; these clearly affect the GSS-API 105 namespaces. 107 Extensions that affect the GSS-API namespaces should be registered 108 with the IANA as described herein. 110 4. Generic GSS-API Namespaces 112 The abstract API namespaces for the GSS-API are: 114 o Type names 116 o Function names 118 o Constant names for various types 120 o Constant values for various types 122 o Name types (OID, type name and syntaxes) 124 Additionally we have namespaces associates with the OBJECT IDENTIFIER 125 (OID) type. The IANA already maintains a registry of such OIDs: 127 o Mechanism OIDs 129 o Name Type OIDs 131 5. Language Binding-Specific GSS-API Namespaces 133 Language binding specific namespaces include, among others: 135 o Header/interface module names 137 o Object classes and/or types 139 o Methods and/or functions 141 o Constant names 143 o Constant values 145 6. Extension-Specific GSS-API Namespaces 147 Extensions to the GSS-API may create additional namespaces. See 148 Section 8.2. 150 7. Registration Form 152 Registrations for GSS-API namespaces SHALL take the following form: 154 +--------------+---------------------+------------------------------+ 155 | Registration | Possible Values | Description | 156 | Field | | | 157 +--------------+---------------------+------------------------------+ 158 | Bindings | 'Generic', | Indicates the name of the | 159 | | 'C-bindings', | programming language that | 160 | | 'Java', 'C#', | this registration involves, | 161 | | | is an entry for the generic | 163 | | | abstract GSS-API (i.e., not | 164 | | | specific to any programming | 165 | | | language). | 166 +--------------+---------------------+------------------------------+ 167 | Registration | 'Instance', 'Sub- | Indicates whether this entry | 168 | type | Namespace' | reserves a given symbol name | 169 | | | (and possibly, constant | 170 | | | value), or whether it | 171 | | | reserves an entire sub- | 172 | | | namespace (the name is a | 173 | | | pattern) or constant value | 174 | | | range. | 175 +--------------+---------------------+------------------------------+ 176 | Object Type | defined by | Indicates the type of the | 177 | | the binding | object whose symbolic name | 178 | | language (for | or constant value this entry | 179 | | example 'Data- | registers. The possible | 180 | | Type', 'Function', | values of this field depend | 181 | | 'Method', | on the programming language | 182 | | 'Integer', | in question, therefore they | 183 | | 'String', 'OID', | are not all specified here. | 184 | | 'Context-Flag', | | 185 | | 'Name-Type', | | 186 | | 'Macro', 'Header- | | 187 | | File-Name', | | 188 | | 'Module-Name', | | 189 | | 'Class') | | 190 +--------------+---------------------+------------------------------+ 191 | Symbol | | symbol sub-namespace being | 193 | | | registered. See Section | 194 | | | 8.2.1 | 195 +--------------+---------------------+------------------------------+ 196 | Binding of | | the abstract API element of | 200 | | | which it is a binding | 201 | | | (OPTIONAL). | 202 +--------------+---------------------+------------------------------+ 203 | Constant | or | The value of the constant | 204 | Value/Range | | Name/Prefix>. This field is | 206 | | | present only for Instance | 207 | | | and Sub-namespace | 208 | | | registrations of Constant | 209 | | | object types. | 210 +--------------+---------------------+------------------------------+ 211 | Description | | Description of the | 212 | | | registration. Multiple | 213 | | | instances of this field may | 214 | | | result (see Section 8.2.3). | 215 +--------------+---------------------+------------------------------+ 216 | Registration | to an | Describes the rules for | 217 | Rules | IANA registration | allocation of items that | 218 | | Policy defined in | fall in this sub-namespace, | 219 | | [RFC5226] (or an | for entries with | 220 | | RFC that updates | Registration Type of Sub- | 221 | | it), for instance | namespace (OPTIONAL). For | 222 | | 'IESG Approval', | private use sub-namespaces | 223 | | 'Expert Review', | the submitter MUST provide | 224 | | 'First Come First | the e-mail address of a | 225 | | Served', 'Private | responsible contact. If | 226 | | Use'. | this field is not specified | 227 | | | for a sub-namespace, the | 228 | | | default registration rules | 229 | | | specified in Section 8.2 | 230 | | | apply. | 231 +--------------+---------------------+------------------------------+ 232 | Reference | | Reference to a document that | 233 | | | describes the registration, | 234 | | | if any (OPTIONAL). Multiple | 235 | | | instances of this field are | 236 | | | allowed, with one reference | 237 | | | each. | 238 +--------------+---------------------+------------------------------+ 239 | Expert | | field are allowed, with one | 242 | | | expert reviewer per- | 243 | | | instance. Leave this field | 244 | | | blank when requesting a | 245 | | | registration. It will be | 246 | | | filled in by the Expert who | 247 | | | reviews the registration. | 248 +--------------+---------------------+------------------------------+ 249 | Expert | | that some comments be | 251 | | | included with the | 252 | | | registration, e.g., | 253 | | | regarding security | 254 | | | considerations of the | 255 | | | registered extension. | 256 +--------------+---------------------+------------------------------+ 257 | Status | 'Registered' or | Status of the registration. | 258 | | 'Obsoleted' | | 259 +--------------+---------------------+------------------------------+ 260 | Obsoleting | | Reference to a document, if | 261 | Reference | | any, that obsoletes this | 262 | | | registration. Multiple | 263 | | | instances of this field are | 264 | | | allowed, with one reference | 265 | | | each. (OPTIONAL) | 266 +--------------+---------------------+------------------------------+ 268 The IANA should create a single GSS-API namespace registry, or 269 multiple registries, one for symbolic names and one for constant 270 values, and/or it may create a registry per-programming language, at 271 its convenience. 273 Entries in these registries should consist of all the fields from 274 their corresponding registration entries. 276 Entries should be sorted by: programming language, registration type, 277 object type, and symbol name/pattern. 279 8. IANA Considerations 281 This document deals with IANA considerations throughout. 282 Specifically it creates a single registry of various kinds of things, 283 though the IANA may instead create multiple registries, each for one 284 of those kinds of things. Of particular interest may be that IANA 285 will now be the registration authority for the GSS-API name type OID 286 space. 288 8.1. Initial Namespace Registrations 290 Initial registry content corresponding to the items defined in 291 [RFC2743], [RFC2744], [RFC2853], [RFC1964] and [RFC4121] and others 292 will be supplied during the IANA review portion of the RFC publishing 293 process. [[Note to RFC Editor: Delete the following sentence before 294 publication:]] The KITTEN WG chairs MUST indicate that such content 295 has been reviewed by the WG and that there is WG consensus that the 296 entries are in agreement with those RFCs. 298 8.1.1. Example registrations 300 In order to sanity check recommended IANA registration templates, 301 this section registers several entries. 303 +--------------------+----------------------------------------------+ 304 | Registration Field | Possible Values | 305 +--------------------+----------------------------------------------+ 306 | Bindings | C-bindings | 307 +--------------------+----------------------------------------------+ 308 | Registration type | Instance | 309 +--------------------+----------------------------------------------+ 310 | Object Type | Function | 311 +--------------------+----------------------------------------------+ 312 | Symbol Name | gss_init_sec_context | 313 +--------------------+----------------------------------------------+ 314 | Binding of | GSS_Init_sec_context | 315 +--------------------+----------------------------------------------+ 316 | Constant | N/A | 317 | Value/Range | | 318 +--------------------+----------------------------------------------+ 319 | Description | Create a security context by initiator | 320 +--------------------+----------------------------------------------+ 321 | Registration Rules | N/A | 322 +--------------------+----------------------------------------------+ 323 | Reference | RFC 2744 | 324 +--------------------+----------------------------------------------+ 325 | Expert Reviewer | Kitten WG | 326 +--------------------+----------------------------------------------+ 327 | Expert Review | | 328 | Notes | | 329 +--------------------+----------------------------------------------+ 330 | Status | Registered | 331 +--------------------+----------------------------------------------+ 332 | Obsoleting | N/A | 333 | Reference | | 334 +--------------------+----------------------------------------------+ 335 +--------------------+----------------------------------------------+ 336 | Registration Field | Possible Values | 337 +--------------------+----------------------------------------------+ 338 | Bindings | C-bindings | 339 +--------------------+----------------------------------------------+ 340 | Registration type | Instance | 341 +--------------------+----------------------------------------------+ 342 | Object Type | Function | 343 +--------------------+----------------------------------------------+ 344 | Symbol Name | gss_accept_sec_context | 345 +--------------------+----------------------------------------------+ 346 | Binding of | GSS_Accept_sec_context | 347 +--------------------+----------------------------------------------+ 348 | Constant | N/A | 349 | Value/Range | | 350 +--------------------+----------------------------------------------+ 351 | Description | Accept a security context from initiator | 352 +--------------------+----------------------------------------------+ 353 | Registration Rules | N/A | 354 +--------------------+----------------------------------------------+ 355 | Reference | RFC 2744 | 356 +--------------------+----------------------------------------------+ 357 | Expert Reviewer | Kitten WG | 358 +--------------------+----------------------------------------------+ 359 | Expert Review | | 360 | Notes | | 361 +--------------------+----------------------------------------------+ 362 | Status | Registered | 363 +--------------------+----------------------------------------------+ 364 | Obsoleting | N/A | 365 | Reference | | 366 +--------------------+----------------------------------------------+ 367 +--------------------+----------------------------------------------+ 368 | Registration Field | Possible Values | 369 +--------------------+----------------------------------------------+ 370 | Bindings | C-bindings | 371 +--------------------+----------------------------------------------+ 372 | Registration type | Instance | 373 +--------------------+----------------------------------------------+ 374 | Object Type | Context-Flag | 375 +--------------------+----------------------------------------------+ 376 | Symbol Name | GSS_C_DELEG_FLAG | 377 +--------------------+----------------------------------------------+ 378 | Binding of | deleg_state or deleg_req_flag | 379 +--------------------+----------------------------------------------+ 380 | Constant | 1 | 381 | Value/Range | | 382 +--------------------+----------------------------------------------+ 383 | Description | On output (if set): Delegated credentials | 384 | | are available via the delegated_cred_handle | 385 | | parameter of GSS_Accept_sec_context. On | 386 | | input (if set): With the call to | 387 | | GSS_Init_sec_context, delegate credentials | 388 | | to the acceptor. | 389 +--------------------+----------------------------------------------+ 390 | Registration Rules | N/A | 391 +--------------------+----------------------------------------------+ 392 | Reference | RFC 2744 | 393 +--------------------+----------------------------------------------+ 394 | Expert Reviewer | Kitten WG | 395 +--------------------+----------------------------------------------+ 396 | Expert Review | | 397 | Notes | | 398 +--------------------+----------------------------------------------+ 399 | Status | Registered | 400 +--------------------+----------------------------------------------+ 401 | Obsoleting | N/A | 402 | Reference | | 403 +--------------------+----------------------------------------------+ 405 8.2. Registration Maintenance Guidelines 407 Standards-Track RFCs can create new items with any non-conflicting 408 Symbol Name/Prefix value for this registry by virtue of IESG approval 409 to publish as a Standards-Track RFC -- that is, without additional 410 expert review. 412 Standards-Track RFCs can mark existing entries as obsolete, and can 413 even create conflicting entries if explicitly stated (the IESG, of 414 course, should review conflicts carefully, and may reject them). 416 IANA shall also consider submissions from individuals, and via 417 Informational and Experimental RFCs, subject to Expert Review. IANA 418 SHALL allow such registrations if a) they are not conflicting, b) 419 provided that the registration is for object types other than 420 Context-Flags, and c) subject to expert review. Guidelines for 421 expert reviews are given below. 423 8.2.1. Sub-Namespace Symbol Pattern Matching 425 Sub-namespace registrations must provide a pattern for matching 426 symbols for which the sub-namespace's registration rules apply. The 427 pattern consists of a string with the following special tokens: 429 o '*', meaning "match any string." 431 o "%m", meaning "match any mechanism family short-hand name." 433 o "%i", meaning "match any implementor vanity short-hand name." 435 For example, "GSS_%m_*" matches "GSS_krb5_foo" since "krb5" is a 436 common short-hand for the Kerberos V GSS-API mechanism [RFC1964]. 437 But "GSS_%m_*" does not match "GSS_foo_bar" unless "foo" is asserted 438 to be a short-hand for some mechanism. 440 8.2.2. Expert Reviews of Individual Submissions 442 [[The following paragraph should be deleted from the document before 443 publication, as it will not age well. It should be moved to the 444 shepherding write-up.]] 446 Expert review selection SHALL be done as follows. If, at the time 447 that the IANA receives an individual submission for registration in 448 this registry, there are any IETF Working Groups chartered to produce 449 GSS-API-related documents, then the IANA SHALL ask the chairs of such 450 WGs to be expert reviewers or to name one. If there are no such WGs 451 at that time, then the IANA SHALL ask past chairs of the KITTEN WG 452 and the author/editor of this RFC to act as expert reviewers or name 453 an alternate. 455 Expert reviewers of individual registration submissions with 456 Registration Type == Sub-namespace should check that the registration 457 request has a suitable description (which doesn't need to be 458 sufficiently detailed for others to implement) and that the Symbol 459 Name/Prefix is sufficiently descriptive of the purpose of the sub- 460 namespace or reflective of the name of the submitter or associated 461 company. 463 Expert reviewers of individual registration submissions with 464 Registration Type == Instance should check that the Symbol Name falls 465 under a sub-namespace controlled by the submitter. Registration of 466 such entries which do not fall under such a sub-namespace may be 467 allowed provided that they correspond to long existing non-standard 468 extensions to the GSS-API and this can be easily checked or 469 demonstrated, otherwise IESG Protocol Action is REQUIRED (see 470 previous section). Also, reviewers should check that any 471 registration of constant values have a detailed description that is 472 suitable for other implementors to reproduce, and that they don't 473 conflict with other usages or are otherwise dangerous in the 474 reviewers estimation. 476 Expert reviewers should review impact on mechanisms, security and 477 interoperability, and may reject or annotate registrations which can 478 have mechanism impact that requires IESG protocol action. Consider, 479 for example, new versions of GSS_Init_sec_context() and/or 480 GSS_Accept_sec_context which have new input and/or output parameters 481 which imply changes on the wire or in behaviour that may result in 482 interoperability issues. A reviewer could choose to add notes to the 483 registration describing such issues, or the reviewer might conclude 484 that the danger to Internet interoperability is sufficient to warrant 485 rejecting the registration. 487 8.2.3. Change Control 489 Registered entries may be marked obsoleted using the same expert 490 review process as for registering new entries. Obsoleted entries are 491 not, however, to be deleted, but merely marked having Obsoleted 492 Status. Note that entries may be created as obsoleted to record the 493 fact that the given symbol(s) have been used before, even though 494 continued use of them is discouraged. 496 Registered entries may also be updated in two other ways: additional 497 references, obsoleting references, and descriptions may be added. 499 All changes are subject to expert review, except for changes to 500 registrations in a sub-namespace which are subject to the rules of 501 the relevant sub-namespace. The submitter of a change request need 502 not be the same as the original submitter. 504 Registrations may be modified by addition, but under no circumstance 505 may any fields be modified except for the Status field or Contact 506 Address, or to correct for transcription errors in filing or 507 processing registration requests. 509 The IANA SHALL add a field describing the date that a an addition or 510 modification was made, and a description of the change. 512 9. Security Considerations 514 General security considerations relating to IANA registration 515 services apply; see [RFC5226]. 517 Also, expert reviewers should look for and may document security 518 related issues with submitters' GSS-API extensions, to the best of 519 the reviewers' ability given the information furnished by the 520 submitter. Reviewers may add comments regarding their limited 521 ability to review a submission for security problems if the submitter 522 is unwilling to provide sufficient documentation. 524 10. References 526 10.1. Normative References 528 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 529 Requirement Levels", BCP 14, RFC 2119, March 1997. 531 [RFC2743] Linn, J., "Generic Security Service Application Program 532 Interface Version 2, Update 1", RFC 2743, January 2000. 534 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 535 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 536 May 2008. 538 10.2. Informative References 540 [RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 541 1964, June 1996. 543 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 544 C-bindings", RFC 2744, January 2000. 546 [RFC2853] Kabat, J. and M. Upadhyay, "Generic Security Service API 547 Version 2 : Java Bindings", RFC 2853, June 2000. 549 [RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos 550 Version 5 Generic Security Service Application Program 551 Interface (GSS-API) Mechanism: Version 2", RFC 4121, July 552 2005. 554 Authors' Addresses 556 Nicolas Williams 557 Cryptonector LLC 559 Email: nico@cryptonector.com 560 Alexey Melnikov 561 Isode Ltd 562 5 Castle Business Village 563 36 Station Road 564 Hampton, Middlesex TW12 2BX 565 UK 567 Email: Alexey.Melnikov@isode.com