diff options
Diffstat (limited to 'third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-store-cred-02.txt')
-rw-r--r-- | third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-store-cred-02.txt | 673 |
1 files changed, 673 insertions, 0 deletions
diff --git a/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-store-cred-02.txt b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-store-cred-02.txt new file mode 100644 index 00000000000..80125f96060 --- /dev/null +++ b/third_party/heimdal/doc/standardisation/draft-ietf-kitten-gssapi-store-cred-02.txt @@ -0,0 +1,673 @@ + + + +NETWORK WORKING GROUP N. Williams +Internet-Draft Sun +Intended status: Informational October 19, 2006 +Expires: April 22, 2007 + + + GSS-API Extension for Storing Delegated Credentials + draft-ietf-kitten-gssapi-store-cred-02.txt + +Status of this Memo + + By submitting this Internet-Draft, each author represents that any + applicable patent or other IPR claims of which he or she is aware + have been or will be disclosed, and any of which he or she becomes + aware will be disclosed, in accordance with Section 6 of BCP 79. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on April 22, 2007. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + + + + + + + + + + + + + + +Williams Expires April 22, 2007 [Page 1] + +Internet-Draft GSS_Store_cred() October 2006 + + +Abstract + + This document defines a new function for the GSS-API which allows + applications to store delegated (and other) credentials in the + implicit GSS-API credential store. This is needed for GSS-API + applications to use delegated credentials as they would use other + credentials. + + +Table of Contents + + 1. Conventions used in this document . . . . . . . . . . . . . . 3 + 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. GSS_Store_cred() . . . . . . . . . . . . . . . . . . . . . . . 5 + 4. C-Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 6. Security considerations . . . . . . . . . . . . . . . . . . . 9 + 7. Normative References . . . . . . . . . . . . . . . . . . . . . 10 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11 + Intellectual Property and Copyright Statements . . . . . . . . 12 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Williams Expires April 22, 2007 [Page 2] + +Internet-Draft GSS_Store_cred() October 2006 + + +1. Conventions used in this document + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Williams Expires April 22, 2007 [Page 3] + +Internet-Draft GSS_Store_cred() October 2006 + + +2. Introduction + + The GSS-API [RFC2743] clearly assumes that credentials exist in an + implicit store whence they can be acquired using GSS_Acquire_cred() + and GSS_Add_cred() or through use of the default credential. + Multiple credential stores may exist on a given host, but only one + store may be accessed by GSS_Acquire_cred() and GSS_Add_cred() at any + given time. + + This assumption can be seen in sections 1.1.1.2 and 1.1.1.3 of + [RFC2743] as well as in section 3.5 of [RFC2744]. + + Applications may be able to change the credential store from which + credentials can be acquired, either by changing user contexts (where + the applications have the privilege to do so) or by other means + (where a user may have multiple credential stores). + + Some GSS-API acceptor applications always change user contexts, after + accepting a GSS-API security context and making appropriate + authorization checks, to the user context corresponding to the + initiator principal name or to a context requested by the initiator. + The means by which credential stores are managed are generally beyond + the scope of the GSS-API. + + In the case of delegated credential handles however, such credentials + do not exist in the acceptor's credential store or in the credential + stores of the user contexts to which the acceptor application might + change. The GSS-API provides no mechanism by which delegated + credential handles can be made available for acquisition through + GSS_Acquire_cred()/GSS_Add_cred(). The GSS-API also does not provide + any credential import/export interfaces like the GSS-API context + import/export interfaces. + + Thus acceptors are limited to making only direct use of delegated + credential handles and only with GSS_Init_sec_context(), + GSS_Inquire_cred*() and GSS_Release_cred(). This limitation is + particularly onerous on Unix systems where a call to exec() to + replace the process image obliterates any delegated credentials + handle that may exist in that process. + + In order to make delegated credentials generally as useful as + credentials that can be acquired with GSS_Acquire_cred() and + GSS_Add_cred() a primitive is needed which allows storing of + credentials in the implicit credential store. This primitive we call + "GSS_Store_cred()." + + + + + + +Williams Expires April 22, 2007 [Page 4] + +Internet-Draft GSS_Store_cred() October 2006 + + +3. GSS_Store_cred() + + Inputs: + + o input_cred_handle CREDENTIAL HANDLE, -- credential to store; MUST + NOT be GSS_C_NO_CREDENTIAL + + o cred_usage INTEGER -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY, + 2=ACCEPT-ONLY + + o desired_mech_element OBJECT IDENTIFIER, -- if GSS_C_NULL_OID then + store all the elements of the input_cred_handle, otherwise store + only the element of the corresponding mechanism + + o overwrite_cred BOOLEAN, -- if TRUE replace any credential for the + same principal in the credential store + + o default_cred BOOLEAN -- if TRUE make the stored credential + available as the default credential (for acquisition with + GSS_C_NO_NAME as the desired name or for use as + GSS_C_NO_CREDENTIAL) + + Outputs: + + o major_status INTEGER, + + o minor_status INTEGER, + + o mech_elements_stored SET OF OBJECT IDENTIFIER, -- the set of + mechanism OIDs for which credential elements were successfully + stored + + o cred_usage_stored INTEGER -- like cred_usage, but indicates what + kind of credential was stored (useful when the cred_usage input + parameter is set to INITIATE-AND-ACCEPT) + + Return major_status codes: + + o GSS_S_COMPLETE indicates that the credentials were successfully + stored. + + o GSS_S_CREDENTIALS_EXPIRED indicates that the input credentials had + expired or expired before they could be stored. + + o GSS_S_NO_CRED indicates that no input credentials were given. + + o GSS_S_UNAVAILABLE indicates that the credential store is not + available. + + + +Williams Expires April 22, 2007 [Page 5] + +Internet-Draft GSS_Store_cred() October 2006 + + + o GSS_S_DUPLICATE_ELEMENT indicates that an element of the input + credential could not be stored because a credential for the same + principal exists in the current credential store and the + overwrite_cred input argument was FALSE. + + o GSS_S_FAILURE indicates that the credential could not be stored + for some other reason. The minor status code may provide more + information if a non-GSS_C_NULL_OID desired_mech_element was + given. + + GSS_Store_cred() is used to store, in the current credential store, a + given credential that has either been acquired from a different + credential store or been accepted as a delegated credential. + + Specific mechanism elements of a credential can be stored one at a + time by specifying a non-GSS_C_NULL_OID mechanism OID as the + desired_mech_element input argument, in which case the minor status + output SHOULD have a mechanism-specific value when the major status + is not GSS_S_COMPLETE. + + The initiator, acceptor or both usages of the input credential may be + stored as per the cred_usage input argument. + + The credential elements that were actually stored, when the major + status is GSS_S_COMPLETE, are indicated through the cred_usage_stored + and mech_elements_stored function outputs. + + If credentials already exist in the current store for the principal + of the input_cred_handle, then those credentials are not replaced + with the input credentials unless the overwrite_cred input argument + is TRUE. + + Finally, if the current credential store has no default credential + (that is, no credential that could be acquired for GSS_C_NO_NAME) or + if the default_cred input argument is TRUE, and the input credential + can be successfully stored, then the input credential will be + available for acquisition with GSS_C_NO_NAME as the desired name + input to GSS_Acquire_cred() or GSS_Add_cred() as well as for use as + GSS_C_NO_CREDENTIAL for the cred_handle inputs to GSS_Inquire_cred(), + GSS_Inquire_cred_by_mech(), GSS_Init_sec_context() and + GSS_Accept_sec_context(). + + + + + + + + + + +Williams Expires April 22, 2007 [Page 6] + +Internet-Draft GSS_Store_cred() October 2006 + + +4. C-Bindings + + The C-bindings for GSS_Store_cred() make use of types from and are + designed based on the style of the GSS-APIv2 C-Bindings [RFC2744]. + + + OM_uint32 gss_store_cred( + OM_uint32 *minor_status, + gss_cred_id_t input_cred_handle, + gss_cred_usage_t cred_usage, + const gss_OID desired_mech, + OM_uint32 overwrite_cred, + OM_uint32 default_cred, + gss_OID_set *elements_stored, + gss_cred_usage_t *cred_usage_stored) + + + Figure 1 + + The two boolean arguments, 'overwrite_cred' and 'default_cred' are + typed as OM_uint32; 0 corresponds to FALSE, non-zero values + correspond to TRUE. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Williams Expires April 22, 2007 [Page 7] + +Internet-Draft GSS_Store_cred() October 2006 + + +5. Examples + + The intended usage of GSS_Store_cred() is to make delegated + credentials available to child processes of GSS-API acceptor + applications. Example pseudo-code: + + + /* + * <GSS_Accept_sec_context() loop resulting in GSS_S_COMPLETE, + * an initiator name (hereafter, "src_name") and a delegated + * credential handle (hereafter "deleg_cred").> + * + * <"requested_username" is a username derived from the + * initiator name or explicitly requested by the initiator + * application.> + */ + ... + + if (authorize_gss_client(src_name, requested_username)) { + /* + * For Unix-type platforms this may mean calling setuid() and + * it may or may not also mean setting/unsetting such + * environment variables as KRB5CCNAME and what not -- all + * OS-specific details. + */ + if (change_user_context(requested_username)) + (void) gss_store_creds(&minor_status, deleg_cred, + GSS_C_INITIATE, actual_mech, + 0, 1, NULL, NULL); + } + else ... + } + else ... + + + + + + + + + + + + + + + + + + +Williams Expires April 22, 2007 [Page 8] + +Internet-Draft GSS_Store_cred() October 2006 + + +6. Security considerations + + Acceptor applications MUST only store delegated credentials into + appropriate credential stores and only after proper authorization of + the authenticated initiator principal to the requested service(s). + + Acceptor applications that have no use for delegated credentials MUST + release them (such acceptor applications that use the GSS-API + C-Bindings may simply provide a NULL value for the + delegated_cred_handle argument to gss_accept_sec_context()). + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Williams Expires April 22, 2007 [Page 9] + +Internet-Draft GSS_Store_cred() October 2006 + + +7. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2743] Linn, J., "Generic Security Service Application Program + Interface Version 2, Update 1", RFC 2743, January 2000. + + [RFC2744] Wray, J., "Generic Security Service API Version 2 : + C-bindings", RFC 2744, January 2000. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Williams Expires April 22, 2007 [Page 10] + +Internet-Draft GSS_Store_cred() October 2006 + + +Author's Address + + Nicolas Williams + Sun Microsystems + 5300 Riata Trace Ct + Austin, TX 78727 + US + + Email: Nicolas.Williams@sun.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Williams Expires April 22, 2007 [Page 11] + +Internet-Draft GSS_Store_cred() October 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + +Acknowledgment + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + +Williams Expires April 22, 2007 [Page 12] + + |