1 2 3NETWORK WORKING GROUP N. Williams 4Internet-Draft Sun 5Expires: December 30, 2004 July 2004 6 7 8 Namespace Considerations and Registries for GSS-API Extensions 9 draft-williams-gssapi-extensions-iana-00.txt 10 11Status of this Memo 12 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 and any of which I become aware will be disclosed, in accordance with 16 RFC 3668. 17 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 22 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 27 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 30 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 33 34 This Internet-Draft will expire on December 30, 2004. 35 36Copyright Notice 37 38 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 40Abstract 41 42 This document describes the ways in which the GSS-API may be extended 43 and directs the creation of IANA registries for GSS-API namespaces 44 that may be affected by any extensions. 45 46 47 48 49 50 51 52 53 54 55Williams Expires December 30, 2004 [Page 1] 56 57Internet-Draft GSS-API Namespace Considerations July 2004 58 59 60Table of Contents 61 62 1. Conventions used in this document . . . . . . . . . . . . . . 3 63 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Extensions to the GSS-API . . . . . . . . . . . . . . . . . . 5 65 4. Generic GSS-API Namespaces . . . . . . . . . . . . . . . . . . 6 66 5. Language Binding-Specific GSS-API Namespaces . . . . . . . . . 7 67 6. Extension-Specific GSS-API Namespaces . . . . . . . . . . . . 8 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 70 9. Normative . . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10 72 Intellectual Property and Copyright Statements . . . . . . . . 11 73 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 111Williams Expires December 30, 2004 [Page 2] 112 113Internet-Draft GSS-API Namespace Considerations July 2004 114 115 1161. 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 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167Williams Expires December 30, 2004 [Page 3] 168 169Internet-Draft GSS-API Namespace Considerations July 2004 170 171 1722. Introduction 173 174 There is a need for generic and mechanism-specific extensions to the 175 Generic Security Services Application Programming Interface 176 (GSS-API). As such extensions are designed and standardized, both at 177 the IETF and elsewhere, there is a non-trivial risk of namespace 178 pollution and conflicts. To avoid this we set out guidelines for 179 extending the GSS-API and create IANA registries of GSS-API 180 namespaces. 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223Williams Expires December 30, 2004 [Page 4] 224 225Internet-Draft GSS-API Namespace Considerations July 2004 226 227 2283. Extensions to the GSS-API 229 230 Extensions to the GSS-API can be categorized as follows: 231 o Generic 232 o Implementation-specific 233 o Mechanism-specific 234 o Language binding-specific 235 o Any combination of two or all three of the last three 236 237 Extensions to the GSS-API may be purely semantic, without effect on 238 the GSS-API's namespaces. Or they may introduce new functions, 239 constants, types, etc...; these clearly affect the GSS-API 240 namespaces. 241 242 Extensions that affect the GSS-API namespaces should be registered 243 with the IANA< along with their specific effects on the GSS-API 244 namespaces. 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279Williams Expires December 30, 2004 [Page 5] 280 281Internet-Draft GSS-API Namespace Considerations July 2004 282 283 2844. Generic GSS-API Namespaces 285 286 All the function, constant and type names, as well as all the 287 constant values specified in the base GSS-API specification for the 288 basic generic GSS-API namespace. 289 290 The generic GSS-API namespaces are: 291 o Type names 292 o Function names 293 o Constant names for each type 294 o Constant values for each type 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 335Williams Expires December 30, 2004 [Page 6] 336 337Internet-Draft GSS-API Namespace Considerations July 2004 338 339 3405. Language Binding-Specific GSS-API Namespaces 341 342 <Add text; discuss header, module, library, class namespaces and 343 whatever else comes up that is language-specific and appropriate for 344 registration with the IANA.> 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391Williams Expires December 30, 2004 [Page 7] 392 393Internet-Draft GSS-API Namespace Considerations July 2004 394 395 3966. Extension-Specific GSS-API Namespaces 397 398 Extensions to the GSS-API may create additional namespaces. IANA 399 registries SHOULD be created for any such new namespaces. 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447Williams Expires December 30, 2004 [Page 8] 448 449Internet-Draft GSS-API Namespace Considerations July 2004 450 451 4527. IANA Considerations 453 454 The following registries should be established upon publication of 455 this document as an RFC: 456 o GSS-API Type Name Registry 457 o GSS-API Function Name Registry 458 o GSS-API Constant Name Registry 459 o GSS-API Constant Value Registry 460 o GSS-API Class/Header/Library/Module Name Registry 461 462 Entries in these registries should consist of: 463 o Namespace name 464 o Symbol name or prefix, OR value or value range. 465 o [optional] Reference to normative reference for the registration. 466 o [optional] Programming language 467 o [optional] Entry sub-type (e.g., "header name") 468 o [optional] Mechanism OID(s) and/or OID prefix(es) associated with 469 the entry 470 o [optional] Magic 471 o [optional] Expert Review (body or people who reviewed the 472 registration) 473 o [optional] Description (in English) 474 475 <Add text on guidelines for IANA consideration of registration 476 applications, particularly with respect to entries w/o normative 477 references, "magic" entries (e.g., special values of 'time' types 478 which indicate something other than absolute or relative time, such 479 as GSS_C_INDEFINITE), expert review requirements for registrations w/ 480 o normative references, etc....> 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503Williams Expires December 30, 2004 [Page 9] 504 505Internet-Draft GSS-API Namespace Considerations July 2004 506 507 5088. Security Considerations 509 510 This document has no security considerations. 511 5129 Normative 513 514 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 515 Requirement Levels", BCP 14, RFC 2119, March 1997. 516 517 [RFC2743] Linn, J., "Generic Security Service Application Program 518 Interface Version 2, Update 1", RFC 2743, January 2000. 519 520 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 521 C-bindings", RFC 2744, January 2000. 522 523 524Author's Address 525 526 Nicolas Williams 527 Sun Microsystems 528 5300 Riata Trace Ct 529 Austin, TX 78727 530 US 531 532 EMail: Nicolas.Williams@sun.com 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559Williams Expires December 30, 2004 [Page 10] 560 561Internet-Draft GSS-API Namespace Considerations July 2004 562 563 564Intellectual Property Statement 565 566 The IETF takes no position regarding the validity or scope of any 567 Intellectual Property Rights or other rights that might be claimed to 568 pertain to the implementation or use of the technology described in 569 this document or the extent to which any license under such rights 570 might or might not be available; nor does it represent that it has 571 made any independent effort to identify any such rights. Information 572 on the procedures with respect to rights in RFC documents can be 573 found in BCP 78 and BCP 79. 574 575 Copies of IPR disclosures made to the IETF Secretariat and any 576 assurances of licenses to be made available, or the result of an 577 attempt made to obtain a general license or permission for the use of 578 such proprietary rights by implementers or users of this 579 specification can be obtained from the IETF on-line IPR repository at 580 http://www.ietf.org/ipr. 581 582 The IETF invites any interested party to bring to its attention any 583 copyrights, patents or patent applications, or other proprietary 584 rights that may cover technology that may be required to implement 585 this standard. Please address the information to the IETF at 586 ietf-ipr@ietf.org. 587 588 589Disclaimer of Validity 590 591 This document and the information contained herein are provided on an 592 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 593 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 594 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 595 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 596 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 597 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 598 599 600Copyright Statement 601 602 Copyright (C) The Internet Society (2004). This document is subject 603 to the rights, licenses and restrictions contained in BCP 78, and 604 except as set forth therein, the authors retain all their rights. 605 606 607Acknowledgment 608 609 Funding for the RFC Editor function is currently provided by the 610 Internet Society. 611 612 613 614 615Williams Expires December 30, 2004 [Page 11] 616 617 618