idnits 2.17.1 draft-ietf-kitten-gssapi-v3-guide-to-01.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 on line 367. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 344. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 351. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 357. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (October 16, 2005) is 6764 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) -- Missing reference section? 'RFC2119' on line 316 looks like a reference -- Missing reference section? 'RFC2743' on line 319 looks like a reference -- Missing reference section? 'RFC2744' on line 322 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 10 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: April 19, 2006 October 16, 2005 6 Guide to the GSS-APIv3 7 draft-ietf-kitten-gssapi-v3-guide-to-01.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 April 19, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 Extensions to the GSS-APIv2 are needed for a number of reasons. This 41 documents describes the extensions being proposed, the resons, 42 possible future directions, and portability, IANA and security 43 considerations. This document does not define any protocol or 44 interface and is purely informational. 46 Table of Contents 48 1. Conventions used in this document . . . . . . . . . . . . . . 3 49 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 3. A Pseudo-Mechanism OID for the GSS-API Itself . . . . . . . . 6 51 4. Mechanism Attribute Inquiry Facilities . . . . . . . . . . . . 7 52 5. Security Context Extensibility Extensions . . . . . . . . . . 8 53 6. Credential Extensibility Extensions . . . . . . . . . . . . . 9 54 7. Credential Export/Import . . . . . . . . . . . . . . . . . . . 10 55 8. GSS_Store_cred() . . . . . . . . . . . . . . . . . . . . . . . 11 56 9. Pseudo-Mechanism Stacking . . . . . . . . . . . . . . . . . . 12 57 10. Naming Extensions . . . . . . . . . . . . . . . . . . . . . . 13 58 11. Additional Name Types . . . . . . . . . . . . . . . . . . . . 14 59 12. GSS_Pseudo_random() . . . . . . . . . . . . . . . . . . . . . 15 60 13. Channel Bindings Specifications . . . . . . . . . . . . . . . 16 61 14. Semantic and Miscallaneous Extensions . . . . . . . . . . . . 17 62 15. Portability Considerations . . . . . . . . . . . . . . . . . . 18 63 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 64 17. Security Considerations . . . . . . . . . . . . . . . . . . . 20 65 18. Normative . . . . . . . . . . . . . . . . . . . . . . . . . . 20 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 21 67 Intellectual Property and Copyright Statements . . . . . . . . 22 69 1. Conventions used in this document 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in [RFC2119]. 75 2. Introduction 77 [NOTE: the references section is current fairly empty; the various 78 KITTEN WG work items will be added to this I-D in a subsequent 79 revision.] 81 Since the advent of the GSS-APIv2 it has come to be used in a number 82 of Internet (and other) protocols and a number of implementations 83 exist. In that time implementors and protocol designers have come to 84 understand both, the GSS-API's strengths, and its shortcommings; we 85 believe now that a number of extensions to the GSS-API are needed. 86 Here these proposed extensions, forming what we may call the GSS-API 87 version 3, are described at a high-level.; 89 Some of these extensions are intended to facilitate further 90 extensions, so that further major revisions to the GSS-API may not be 91 necessary. Others are intended to fill voids in the the GSS-APIv2. 93 The extensions being proposed are: 95 A pseudo-mechanism OID for the GSS-API itself 97 Mechanism attribute inquiry facilities 99 Security context extensibility extensions 101 Credential extensibility extensions 103 Credential export/import 105 GSS_Store_cred(), for making delegated credentials available for 106 acquisition 108 Pseudo-mechanism stacking 110 Naming extensions, to facilitate authorization by identifiers 111 other than names 113 Additional name types, specifically domain-based naming 115 A pseudo-random function interface 117 Channel bindings specifications 119 Semantic extensions relating to thread- and/or fork-safety 121 [Have I missed anything? I have a feeling I have. Re-keying?] 122 ... 124 Additionally, because we foresee future minor extensions, including, 125 specifically, extensions which may impact the various namespaces 126 associated with APIs (symbol names, constant values, class names, 127 etc...) we also propose the establishment of IANA registries for 128 these namespaces. 130 3. A Pseudo-Mechanism OID for the GSS-API Itself 132 A mechanism OID is assigned to identify and refer to the GSS-API 133 iself. This is necessary to enable the use of extended inquiry 134 interfaces to inquire about features of a GSS-API implementation 135 specifically, apart from actual mechanisms. 137 But also, this OID is needed for better error handling, so that minor 138 status codes produced in generic contexts that lack a mechanism OID 139 can be distinguished from minor status codes for a "default" 140 mechanism and properly displayed. 142 4. Mechanism Attribute Inquiry Facilities 144 In the course of designing a pseudo-mechanism stacking facility, as 145 well as while considering the impact of all of these extensions on 146 portability, a need for interfaces through which to discover or 147 inquire by features provided by GSS-API mechanisms was discovered. 149 The proposed mechanism attribute inquiry interfaces consist of: 151 GSS_Inquire_mech_attrs_for_mech() 153 GSS_Indicate_mechs_by_mech_attrs() 155 GSS_Display_mech_attr() 157 These extensions facilitate portability by allowing GSS-APIv3 158 applications to discover the features provided by a given 159 implementation of the GSS-API or any mechanisms. These extensions 160 are also useful in facilitating stackable pseudo-mechanisms. 162 5. Security Context Extensibility Extensions 164 In order to facilitate future security context options we introduce a 165 GSS_Create_sec_context() interface that creates a security context 166 object, for use with extensions and with GSS_Init_sec_context(), 167 GSS_Accept_sec_context(), and GSS_Inquire_sec_context(). Such 168 security contexts are in a non-established state until they are 169 established through the use of GSS_Init_sec_context() or 170 GSS_Accept_sec_context(). 172 6. Credential Extensibility Extensions 174 In order to facilitate future extensions to GSS credentials we 175 introduce a GSS_Create_credential(), similar to 176 GSS_Create_sec_context(), interface that creates an "empty" 177 credential. 179 7. Credential Export/Import 181 To allow for passing of credentials between different "session 182 contexts," between different hosts, or for storage of post-dated 183 credentials, we introduce a credential export/import facility, much 184 like the security context export/import facility of the GSS-APIv2. 186 Together with credential extensibility and other extensions this 187 facility may allow for: 189 Credential delegation at any time 191 Post-dated credentials, and storage of the such for subsequent 192 use. 194 ...? 196 8. GSS_Store_cred() 198 This extension fills a void in the GSS-APIv2 where delegated 199 credentials could not be used except in the context of the same 200 process that received them. With this extension acceptor 201 applications can now make delegated credentials available for use, 202 with GSS_Acquire_cred() et. al., in other process contexts. 204 [Manipulation of "credential stores" is (may be?) out of scope for 205 this document.] 207 9. Pseudo-Mechanism Stacking 209 A number of pseudo-mechanisms are being proposed which are designed 210 to "stack" atop other mechanisms. The possiblities are many, 211 including: a compression mechanism, a perfect forward security 212 mechanism, an many others. 214 The GSS-APIv2 only had concrete mechanisms and one pseudo-mechanism 215 (SPNEGO) available. With this proposal the mechanism taxonomy is 216 quite expanded: 218 Concrete mechanisms (e.g., the Kerberos V mechanism) 220 Composite mechanisms (a concrete mechanism composed with one or 221 more stackable pseudo-mechanisms) 223 Stackable pseudo-mechanisms 225 Other pseudo-mechanisms (e.g., SPNEGO, the GSS-API itself) 227 Although composed mechanisms may be made available for use by GSS- 228 APIv2 applications without any further extensions, use of stackable 229 pseudo-mechanisms can complicate mechanism negotiation; additionally, 230 discovery of mechanisms appropriate for use in one or another context 231 would require hard-coding information about them in GSS-APIv2 232 applications. Extensions to the GSS-APIv2 could facilitate use of 233 composite. 235 The mechanism attribute inquiry facilities, together with the 236 forllowing additional interfaces, provide for a complete interface to 237 mechanism composition and for managing the complexity of mechanism 238 negotiation: 240 GSS_Compose_oid() 242 GSS_Decompose_oid() 244 GSS_Release_oid() 246 GSS_Indicate_negotiable_mechs() 248 GSS_Negotiate_mechs() 250 10. Naming Extensions 252 Some applications make use of exported names, as produced by 253 GSS_Export_name(), to create/manage/evaluate access control lists; we 254 call this name-based authorization. 256 Exported names typically encode names that are meant for display to 257 humans, not internal identifiers. 259 In practice this creates a number of problems. E.g., the referential 260 integrity of such access control lists is hard to maintain as 261 principals are added, removed, renamed or old principal names reused. 263 Additionally, some mechanisms may lack a notion of a "canonical" name 264 for some or all of their principals. Such mechanisms cannot be used 265 by applications that rely on name-based authorization. 267 269 11. Additional Name Types 271 273 12. GSS_Pseudo_random() 275 277 13. Channel Bindings Specifications 278 14. Semantic and Miscallaneous Extensions 280 The GSS-APIv2 specifications say nothing about the thread-safety, 281 much less the fork-safety, of the GSS-API. Thread-safety and fork- 282 safety are, after all, platform- and/or language-specific matters. 283 But as support for multi-threading spreads the matter of thread- 284 safety cannot be avoided. The matter of fork-safety is specific to 285 platforms that provide a "fork()" function, or similar. 287 289 291 15. Portability Considerations 293 The potential for additional generic, mechanism-specific, language 294 binding-specific and, most importantly, semantic extensions to the 295 GSS-APIv3 may create application portability problems. The mechanism 296 attribute inquiry facilities of the GSS-APIv3 and the pseudo- 297 mechanism OID for the GSS-API itself double as a run-time facility 298 for discovery of feature availability. Run-time feature discovery 299 facilities, in turn, can be used at application build-time as well by 300 building small applications to display the available features. 302 <...> 304 16. IANA Considerations 306 310 17. Security Considerations 312 <...> 314 18. Normative 316 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 317 Requirement Levels", BCP 14, RFC 2119, March 1997. 319 [RFC2743] Linn, J., "Generic Security Service Application Program 320 Interface Version 2, Update 1", RFC 2743, January 2000. 322 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 323 C-bindings", RFC 2744, January 2000. 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 Intellectual Property Statement 337 The IETF takes no position regarding the validity or scope of any 338 Intellectual Property Rights or other rights that might be claimed to 339 pertain to the implementation or use of the technology described in 340 this document or the extent to which any license under such rights 341 might or might not be available; nor does it represent that it has 342 made any independent effort to identify any such rights. Information 343 on the procedures with respect to rights in RFC documents can be 344 found in BCP 78 and BCP 79. 346 Copies of IPR disclosures made to the IETF Secretariat and any 347 assurances of licenses to be made available, or the result of an 348 attempt made to obtain a general license or permission for the use of 349 such proprietary rights by implementers or users of this 350 specification can be obtained from the IETF on-line IPR repository at 351 http://www.ietf.org/ipr. 353 The IETF invites any interested party to bring to its attention any 354 copyrights, patents or patent applications, or other proprietary 355 rights that may cover technology that may be required to implement 356 this standard. Please address the information to the IETF at 357 ietf-ipr@ietf.org. 359 Disclaimer of Validity 361 This document and the information contained herein are provided on an 362 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 363 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 364 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 365 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 366 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 367 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 369 Copyright Statement 371 Copyright (C) The Internet Society (2005). This document is subject 372 to the rights, licenses and restrictions contained in BCP 78, and 373 except as set forth therein, the authors retain all their rights. 375 Acknowledgment 377 Funding for the RFC Editor function is currently provided by the 378 Internet Society.