idnits 2.17.1 draft-ietf-kitten-gssapi-store-cred-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 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 305. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 282. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 289. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 295. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 311), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 2 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (February 14, 2005) is 7010 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 254 looks like a reference -- Missing reference section? 'RFC2743' on line 257 looks like a reference -- Missing reference section? 'RFC2744' on line 260 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 NETWORK WORKING GROUP N. Williams 2 Internet-Draft Sun 3 Expires: August 15, 2005 February 14, 2005 5 GSS-API Extension for Storing Delegated Credentials 6 draft-ietf-kitten-gssapi-store-cred-00.txt 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 and any of which I become aware will be disclosed, in accordance with 13 RFC 3668. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 15, 2005. 33 Copyright Notice 35 Copyright (C) The Internet Society (2005). All Rights Reserved. 37 Abstract 39 This document defines a new function for the GSS-API which allows 40 applications to store delegated (and other) credentials in the 41 implicit GSS-API credential store. This is needed for GSS-API 42 applications to use delegated credentials as they would use other 43 credentials. 45 Table of Contents 47 1. Conventions used in this document . . . . . . . . . . . . . . 3 48 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 49 3. GSS_Store_cred() . . . . . . . . . . . . . . . . . . . . . . . 5 50 4. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . 7 51 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 52 6. Security considerations . . . . . . . . . . . . . . . . . . . 9 53 7. Normative . . . . . . . . . . . . . . . . . . . . . . . . . . 9 54 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 9 55 Intellectual Property and Copyright Statements . . . . . . . . 10 57 1. Conventions used in this document 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in [RFC2119]. 63 2. Introduction 65 The GSS-API [RFC2743] clearly assumes that credentials exist in an 66 implicit store whence they can be acquired using GSS_Acquire_cred() 67 and GSS_Add_cred() or through use of the default credential. 68 Multiple credential stores may exist on a given host, but only one 69 store may be accessed by GSS_Acquire_cred() and GSS_Add_cred() at any 70 given time. 72 This assumption can be seen in sections 1.1.1.2 and 1.1.1.3 of 73 [RFC2743] as well as in section 3.5 of [RFC2744]. 75 Note to the RFC editor: please remove this note before publication.] 77 Applications may be able to change the credential store from which 78 credentials can be acquired, either by changing user contexts (where 79 the applications have the privilege to do so) or by other means 80 (where a user may have multiple credential stores). 82 Some GSS-API acceptor applications always change user contexts, after 83 accepting a GSS-API security context and making appropriate 84 authorization checks, to the user context corresponding to the 85 initiator principal name or to a context requested by the initiator. 86 The means by which credential stores are managed are generally beyond 87 the scope of the GSS-API. 89 In the case of delegated credential handles however, such credentials 90 do not exist in the acceptor's credential store or in the credential 91 stores of the user contexts to which the acceptor application might 92 change - which is precisely the raison d'etre of credential 93 delegation. But the GSS-API provides no mechanism by which delegated 94 credential handles can be made available for acquisition through 95 GSS_Acquire_cred()/GSS_Add_cred(). The GSS-API also does not provide 96 any credential import/export interfaces like the GSS-API context 97 import/export interfaces. 99 Thus acceptors are limited to making only direct use of delegated 100 credential handles and only with GSS_Init_sec_context(), 101 GSS_Inquire_cred*() and GSS_Release_cred(). This limitation is 102 particularly onerous on Unix systems where a call to exec() to 103 replace the process image obliterates the delegated credentials 104 handle. 106 In order to make delegated credentials generally as useful as 107 credentials that can be acquired with GSS_Acquire_cred() and 108 GSS_Add_cred() a primitive is needed which allows storing of 109 credentials in the implicit credential store. This primitive we call 110 "GSS_Store_cred()." 112 3. GSS_Store_cred() 114 Inputs: 115 o input_cred_handle CREDENTIAL HANDLE, -- credential to store; MUST 116 NOT be GSS_C_NO_CREDENTIAL 117 o cred_usage INTEGER -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY, 118 2=ACCEPT-ONLY 119 o desired_mech_element OBJECT IDENTIFIER, -- if GSS_C_NULL_OID then 120 store all the elements of the input_cred_handle, otherwise store 121 only the element of the corresponding mechanism 122 o overwrite_cred BOOLEAN, -- if TRUE replace any credential for the 123 same principal in the credential store 124 o default_cred BOOLEAN -- if TRUE make the stored credential 125 available as the default credential (for acquisition with 126 GSS_C_NO_NAME as the desired name or for use as 127 GSS_C_NO_CREDENTIAL) 129 Outputs: 130 o major_status INTEGER, 131 o minor_status INTEGER, 132 o mech_elements_stored SET OF OBJECT IDENTIFIER, -- the set of 133 mechanism OIDs for which credential elements were successfully 134 stored 135 o cred_usage_stored INTEGER -- like cred_usage, but indicates what 136 kind of credential was stored (useful when the cred_usage input 137 parameter is set to INITIATE-AND-ACCEPT) 139 Return major_status codes: 140 o GSS_S_COMPLETE indicates that the credentials were successfully 141 stored. 142 o GSS_S_CREDENTIALS_EXPIRED indicates that the input credentials had 143 expired or expired before they could be stored. 144 o GSS_S_NO_CRED indicates that no input credentials were given. 145 o GSS_S_UNAVAILABLE indicates that the credential store is not 146 available. 147 o GSS_S_DUPLICATE_ELEMENT indicates that an element of the input 148 credential could not be stored because a credential for the same 149 principal exists in the current credential store and the 150 overwrite_cred input argument was FALSE. 151 o GSS_S_FAILURE indicates that the credential could not be stored 152 for some other reason. The minor status code may provide more 153 information if a non-GSS_C_NULL_OID desired_mech_element was 154 given. 156 GSS_Store_cred() is used to store, in the current credential store, a 157 given credential that has either been acquired from a different 158 credential store or been accepted as a delegated credential. 160 Specific mechanism elements of a credential can be stored one at a 161 time by specifying a non-GSS_C_NULL_OID mechanism OID as the 162 desired_mech_element input argument, in which case the minor status 163 output SHOULD have a mechanism-specific value when the major status 164 is not GSS_S_COMPLETE. 166 The initiator, acceptor or both usages of the input credential may be 167 stored as per the cred_usage input argument. 169 The credential elements that were actually stored, when the major 170 status is GSS_S_COMPLETE, are indicated through the cred_usage_stored 171 and mech_elements_stored function outputs. 173 If credentials already exist in the current store for the principal 174 of the input_cred_handle, then those credentials are not replaced 175 with the input credentials unless the overwrite_cred input argument 176 is TRUE. 178 Finally, if the current credential store has no default credential 179 (that is, no credential that could be acquired for GSS_C_NO_NAME) or 180 if the default_cred input argument is TRUE, and the input credential 181 can be successfully stored, then the input credential will be 182 available for acquisition with GSS_C_NO_NAME as the desired name 183 input to GSS_Acquire_cred() or GSS_Add_cred() as well as for use as 184 GSS_C_NO_CREDENTIAL for the cred_handle inputs to GSS_Inquire_cred(), 185 GSS_Inquire_cred_by_mech(), GSS_Init_sec_context() and 186 GSS_Accept_sec_context(). 188 4. C-Bindings 190 The C-bindings for GSS_Store_cred() make use of types from and are 191 designed based on the style of the GSS-APIv2 C-Bindings [RFC2744]. 193 OM_uint32 gss_store_cred( 194 OM_uint32 *minor_status, 195 gss_cred_id_t input_cred, 196 gss_cred_usage_t cred_usage, 197 const gss_OID desired_mech, 198 OM_uint32 overwrite_cred, 199 OM_uint32 default_cred, 200 gss_OID_set *elements_stored, 201 gss_cred_usage_t *cred_usage_stored) 203 Figure 1 205 The two boolean arguments, 'overwrite_cred' and 'default_cred' are 206 typed as OM_uint32; 0 corresponds to FALSE, non-zero values 207 correspond to TRUE. 209 5. Examples 211 The intended usage of GSS_Store_cred() is to make delegated 212 credentials available to child processes of GSS-API acceptor 213 applications. Example pseudo-code: 215 /* 216 * 219 * 220 * <"requested_username" is a username derived from the 221 * initiator name or explicitly requested by the initiator 222 * application.> 223 */ 224 ... 226 if (authorize_gss_client(src_name, requested_username)) { 227 /* 228 * For Unix-type platforms this may mean calling setuid() and 229 * it may or may not also mean setting/unsetting such 230 * environment variables as KRB5CCNAME and what not. 231 */ 232 if (change_user_context(requested_username)) 233 (void) gss_store_creds(&minor_status, deleg_cred, 234 GSS_C_INITIATE, actual_mech, 235 0, 1, NULL, NULL); 236 } 237 else ... 238 } 239 else ... 241 6. Security considerations 243 Acceptor applications MUST only store delegated credentials into 244 appropriate credential stores and only after proper authorization of 245 the authenticated initiator principal to the requested service(s). 247 Acceptor applications that have no use for delegated credentials MUST 248 release them (such acceptor applications that use the GSS-API 249 C-Bindings may simply provide a NULL value for the 250 delegated_cred_handle argument to gss_accept_sec_context()). 252 7 Normative 254 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 255 Requirement Levels", BCP 14, RFC 2119, March 1997. 257 [RFC2743] Linn, J., "Generic Security Service Application Program 258 Interface Version 2, Update 1", RFC 2743, January 2000. 260 [RFC2744] Wray, J., "Generic Security Service API Version 2 : 261 C-bindings", RFC 2744, January 2000. 263 Author's Address 265 Nicolas Williams 266 Sun Microsystems 267 5300 Riata Trace Ct 268 Austin, TX 78727 269 US 271 EMail: Nicolas.Williams@sun.com 273 Intellectual Property Statement 275 The IETF takes no position regarding the validity or scope of any 276 Intellectual Property Rights or other rights that might be claimed to 277 pertain to the implementation or use of the technology described in 278 this document or the extent to which any license under such rights 279 might or might not be available; nor does it represent that it has 280 made any independent effort to identify any such rights. Information 281 on the procedures with respect to rights in RFC documents can be 282 found in BCP 78 and BCP 79. 284 Copies of IPR disclosures made to the IETF Secretariat and any 285 assurances of licenses to be made available, or the result of an 286 attempt made to obtain a general license or permission for the use of 287 such proprietary rights by implementers or users of this 288 specification can be obtained from the IETF on-line IPR repository at 289 http://www.ietf.org/ipr. 291 The IETF invites any interested party to bring to its attention any 292 copyrights, patents or patent applications, or other proprietary 293 rights that may cover technology that may be required to implement 294 this standard. Please address the information to the IETF at 295 ietf-ipr@ietf.org. 297 Disclaimer of Validity 299 This document and the information contained herein are provided on an 300 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 301 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 302 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 303 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 304 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 305 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 307 Copyright Statement 309 Copyright (C) The Internet Society (2005). This document is subject 310 to the rights, licenses and restrictions contained in BCP 78, and 311 except as set forth therein, the authors retain all their rights. 313 Acknowledgment 315 Funding for the RFC Editor function is currently provided by the 316 Internet Society.