idnits 2.17.1 draft-ietf-kitten-gssapi-v3-guide-to-00.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 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 340. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 317. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 324. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 330. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 346), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 (January 25, 2005) is 7031 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 289 looks like a reference -- Missing reference section? 'RFC2743' on line 292 looks like a reference -- Missing reference section? 'RFC2744' on line 295 looks like a reference Summary: 6 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: July 26, 2005 January 25, 2005 6 Guide to the GSS-APIv3 7 draft-ietf-kitten-gssapi-v3-guide-to-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 and any of which I become aware will be disclosed, in accordance with 14 RFC 3668. 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 19 Internet-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 July 26, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). All Rights Reserved. 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 . . . . . . . . 5 51 4. Mechanism Attribute Inquiry Facilities . . . . . . . . . . . . 6 52 5. Security Context Extensibility Extensions . . . . . . . . . . 7 53 6. Credential Extensibility Extensions . . . . . . . . . . . . . 8 54 7. Credential Export/Import . . . . . . . . . . . . . . . . . . . 9 55 8. GSS_Store_cred() . . . . . . . . . . . . . . . . . . . . . . . 10 56 9. Pseudo-Mechanism Stacking . . . . . . . . . . . . . . . . . . 11 57 10. Naming Extensions . . . . . . . . . . . . . . . . . . . . . . 12 58 11. Additional Name Types . . . . . . . . . . . . . . . . . . . . 13 59 12. GSS_Pseudo_random() . . . . . . . . . . . . . . . . . . . . . 14 60 13. Channel Bindings Specifications . . . . . . . . . . . . . . . 15 61 14. Semantic and Miscallaneous Extensions . . . . . . . . . . . . 16 62 15. Portability Considerations . . . . . . . . . . . . . . . . . . 17 63 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 64 17. Security Considerations . . . . . . . . . . . . . . . . . . . 19 65 18. Normative . . . . . . . . . . . . . . . . . . . . . . . . . . 19 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19 67 Intellectual Property and Copyright Statements . . . . . . . . 20 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: 94 A pseudo-mechanism OID for the GSS-API itself 95 Mechanism attribute inquiry facilities 96 Security context extensibility extensions 97 Credential extensibility extensions 98 Credential export/import 99 GSS_Store_cred(), for making delegated credentials available for 100 acquisition 101 Pseudo-mechanism stacking 102 Naming extensions, to facilitate authorization by identifiers 103 other than names 104 Additional name types, specifically domain-based naming 105 A pseudo-random function interface 106 Channel bindings specifications 107 Semantic extensions relating to thread- and/or fork-safety 108 [Have I missed anything? I have a feeling I have. Re-keying?] 109 ... 111 Additionally, because we foresee future minor extensions, including, 112 specifically, extensions which may impact the various namespaces 113 associated with APIs (symbol names, constant values, class names, 114 etc...) we also propose the establishment of IANA registries for 115 these namespaces. 117 3. A Pseudo-Mechanism OID for the GSS-API Itself 119 A mechanism OID is assigned to identify and refer to the GSS-API 120 iself. This is necessary to enable the use of extended inquiry 121 interfaces to inquire about features of a GSS-API implementation 122 specifically, apart from actual mechanisms. 124 But also, this OID is needed for better error handling, so that minor 125 status codes produced in generic contexts that lack a mechanism OID 126 can be distinguished from minor status codes for a "default" 127 mechanism and properly displayed. 129 4. Mechanism Attribute Inquiry Facilities 131 In the course of designing a pseudo-mechanism stacking facility, as 132 well as while considering the impact of all of these extensions on 133 portability, a need for interfaces through which to discover or 134 inquire by features provided by GSS-API mechanisms was discovered. 136 The proposed mechanism attribute inquiry interfaces consist of: 137 GSS_Inquire_mech_attrs_for_mech() 138 GSS_Indicate_mechs_by_mech_attrs() 139 GSS_Display_mech_attr() 141 These extensions facilitate portability by allowing GSS-APIv3 142 applications to discover the features provided by a given 143 implementation of the GSS-API or any mechanisms. These extensions 144 are also useful in facilitating stackable pseudo-mechanisms. 146 5. Security Context Extensibility Extensions 148 In order to facilitate future security context options we introduce a 149 GSS_Create_sec_context() interface that creates a security context 150 object, for use with extensions and with GSS_Init_sec_context(), 151 GSS_Accept_sec_context(), and GSS_Inquire_sec_context(). Such 152 security contexts are in a non-established state until they are 153 established through the use of GSS_Init_sec_context() or 154 GSS_Accept_sec_context(). 156 6. Credential Extensibility Extensions 158 In order to facilitate future extensions to GSS credentials we 159 introduce a GSS_Create_credential(), similar to 160 GSS_Create_sec_context(), interface that creates an "empty" 161 credential. 163 7. Credential Export/Import 165 To allow for passing of credentials between different "session 166 contexts," between different hosts, or for storage of post-dated 167 credentials, we introduce a credential export/import facility, much 168 like the security context export/import facility of the GSS-APIv2. 170 Together with credential extensibility and other extensions this 171 facility may allow for: 172 Credential delegation at any time 173 Post-dated credentials, and storage of the such for subsequent 174 use. 175 ...? 177 8. GSS_Store_cred() 179 This extension fills a void in the GSS-APIv2 where delegated 180 credentials could not be used except in the context of the same 181 process that received them. With this extension acceptor 182 applications can now make delegated credentials available for use, 183 with GSS_Acquire_cred() et. al., in other process contexts. 185 [Manipulation of "credential stores" is (may be?) out of scope for 186 this document.] 188 9. Pseudo-Mechanism Stacking 190 A number of pseudo-mechanisms are being proposed which are designed 191 to "stack" atop other mechanisms. The possiblities are many, 192 including: a compression mechanism, a perfect forward security 193 mechanism, an many others. 195 The GSS-APIv2 only had concrete mechanisms and one pseudo-mechanism 196 (SPNEGO) available. With this proposal the mechanism taxonomy is 197 quite expanded: 198 Concrete mechanisms (e.g., the Kerberos V mechanism) 199 Composite mechanisms (a concrete mechanism composed with one or 200 more stackable pseudo-mechanisms) 201 Stackable pseudo-mechanisms 202 Other pseudo-mechanisms (e.g., SPNEGO, the GSS-API itself) 204 Although composed mechanisms may be made available for use by 205 GSS-APIv2 applications without any further extensions, use of 206 stackable pseudo-mechanisms can complicate mechanism negotiation; 207 additionally, discovery of mechanisms appropriate for use in one or 208 another context would require hard-coding information about them in 209 GSS-APIv2 applications. Extensions to the GSS-APIv2 could facilitate 210 use of composite. 212 The mechanism attribute inquiry facilities, together with the 213 forllowing additional interfaces, provide for a complete interface to 214 mechanism composition and for managing the complexity of mechanism 215 negotiation: 216 GSS_Compose_oid() 217 GSS_Decompose_oid() 218 GSS_Release_oid() 219 GSS_Indicate_negotiable_mechs() 220 GSS_Negotiate_mechs() 222 10. Naming Extensions 224 Some applications make use of exported names, as produced by 225 GSS_Export_name(), to create/manage/evaluate access control lists; we 226 call this name-based authorization. 228 Exported names typically encode names that are meant for display to 229 humans, not internal identifiers. 231 In practice this creates a number of problems. E.g., the referential 232 integrity of such access control lists is hard to maintain as 233 principals are added, removed, renamed or old principal names reused. 235 Additionally, some mechanisms may lack a notion of a "canonical" name 236 for some or all of their principals. Such mechanisms cannot be used 237 by applications that rely on name-based authorization. 239 241 11. Additional Name Types 243 245 12. GSS_Pseudo_random() 247 249 13. Channel Bindings Specifications 250 14. Semantic and Miscallaneous Extensions 252 The GSS-APIv2 specifications say nothing about the thread-safety, 253 much less the fork-safety, of the GSS-API. Thread-safety and 254 fork-safety are, after all, platform- and/or language-specific 255 matters. But as support for multi-threading spreads the matter of 256 thread-safety cannot be avoided. The matter of fork-safety is 257 specific to platforms that provide a "fork()" function, or similar. 259 261 263 15. Portability Considerations 265 The potential for additional generic, mechanism-specific, language 266 binding-specific and, most importantly, semantic extensions to the 267 GSS-APIv3 may create application portability problems. The mechanism 268 attribute inquiry facilities of the GSS-APIv3 and the 269 pseudo-mechanism OID for the GSS-API itself double as a run-time 270 facility for discovery of feature availability. Run-time feature 271 discovery facilities, in turn, can be used at application build-time 272 as well by building small applications to display the available 273 features. 275 <...> 277 16. IANA Considerations 279 283 17. Security Considerations 285 <...> 287 18 Normative 289 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 290 Requirement Levels", BCP 14, RFC 2119, March 1997. 292 [RFC2743] Linn, J., "Generic Security Service Application Program 293 Interface Version 2, Update 1", RFC 2743, January 2000. 295 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 296 C-bindings", RFC 2744, January 2000. 298 Author's Address 300 Nicolas Williams 301 Sun Microsystems 302 5300 Riata Trace Ct 303 Austin, TX 78727 304 US 306 EMail: Nicolas.Williams@sun.com 308 Intellectual Property Statement 310 The IETF takes no position regarding the validity or scope of any 311 Intellectual Property Rights or other rights that might be claimed to 312 pertain to the implementation or use of the technology described in 313 this document or the extent to which any license under such rights 314 might or might not be available; nor does it represent that it has 315 made any independent effort to identify any such rights. Information 316 on the procedures with respect to rights in RFC documents can be 317 found in BCP 78 and BCP 79. 319 Copies of IPR disclosures made to the IETF Secretariat and any 320 assurances of licenses to be made available, or the result of an 321 attempt made to obtain a general license or permission for the use of 322 such proprietary rights by implementers or users of this 323 specification can be obtained from the IETF on-line IPR repository at 324 http://www.ietf.org/ipr. 326 The IETF invites any interested party to bring to its attention any 327 copyrights, patents or patent applications, or other proprietary 328 rights that may cover technology that may be required to implement 329 this standard. Please address the information to the IETF at 330 ietf-ipr@ietf.org. 332 Disclaimer of Validity 334 This document and the information contained herein are provided on an 335 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 336 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 337 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 338 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 339 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 340 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 342 Copyright Statement 344 Copyright (C) The Internet Society (2005). This document is subject 345 to the rights, licenses and restrictions contained in BCP 78, and 346 except as set forth therein, the authors retain all their rights. 348 Acknowledgment 350 Funding for the RFC Editor function is currently provided by the 351 Internet Society.