Re: draft-williams-gssapi-store-deleg-creds-00.txt
Nicolas Williams <[email protected]> Thu, 20 May 2004 10:22:47 -0500
| Newsgroups | gmane.ietf.cat |
|---|---|
| Message-ID | <[email protected]> |
On Thu, May 20, 2004 at 10:41:25AM -0400, Dinara Suleymanova wrote:
> Have you already had this I-D before? I found that it was expired in April.
> If you had an expired I-D, please correct the version to a -01 and resubmit.
> If you have any questions please contact me.
Ooops, sorry, I meant to make it -00... -01 was the result of my
private versioning...
> Thanks.
>
> Dinara
>
> At 04:09 PM 5/19/2004, Nicolas Williams wrote:
>
> >INTERNET-DRAFT Nicolas Williams
> > Sun Microsystems
> > September 2003
> >
> >
> >
> > GSS-APIv2 Extension for Storing Delegated Credentials
> > <draft-williams-gssapi-store-deleg-creds-00.txt>
> >
> >
> >
> >
> >Status of this Memo
> >
> > This document is an Internet-Draft and is in full conformance with
> > all provisions of Section 10 of RFC2026 [RFC2026].
> >
> > 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 draft expires on January 30th, 2004. Please send comments to
> > the authors.
> >
> >
> >Copyright Notice
> >
> > Copyright (C) The Internet Society (2003). All Rights Reserved.
> >
> >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.
> >
> >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].
> >
> >N. Williams [Page 1]
> >
> >DRAFT GSS_Store_cred() Expires March 2004
> >
> >
> >Table of Contents
> >
> > 1 Introduction
> > 2 GSS_Store_cred()
> > 2.1 C-Bindings for GSS_Store_cred()
> > 3 Examples
> > 4 Security Considerations
> > 5 References
> > 5.1 Normative References
> > 6 Author's Address
> >
> >1 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.
> >
> > [NOTE: 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.
> >
> > Note to the RFC editor: please remove this note before
> > publication.]
> >
> > 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 - which is precisely the raison d'etre of credential
> > delegation. But 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
> >
> >N. Williams [Page 2]
> >
> >DRAFT GSS_Store_cred() Expires March 2004
> >
> > replace the process image obliterates the delegated credentials
> > handle.
> >
> > [NOTE: Delegated credentials are practically unusable on Unix
> > implementations of Secure Shell (SSHv2) servers, except where
> > there are extended interfaces for dealing with delegated
> > credentials, which to date have always been
> > mechanism-specific interfaces.
> >
> > Note to the RFC editor: please remove this note before
> > publication.]
> >
> > 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()."
> >
> > [NOTE: Simon Wilkinson's patches to OpenSSH for GSS-API sport a
> > simple internal interface for storing delegated credentials
> > in users' credential store - this internal interface wraps
> > around two mechanism specific internal interfaces for storing
> > GSI and Kerberos V credentials.
> >
> > Simon's code shows that:
> >
> > a) a generic method is needed for making delegated
> > credentials available for indirect use through acquisition
> > (as opposed to just using the actual delegated cred
> > handle)
> >
> > b) it is possible to design and implement such a generic
> > method for storing delegated credentials.
> >
> > No new concepts are added to the GSS-API by this document,
> > but the implicit existence of a credential store in the
> > background is made explicit, and a deficiency of the GSS-API
> > is corrected.
> >
> > Compare this to the GGF proposal which includes a credential
> > import/export facility (like the existing context import/
> > export facility), but with an option to export as
> > "environment variables," meaning something like "store these
> > input creds in some new credential store and then tell me the
> > name of that credential store through some output environment
> > variable"[*]. Thus, the GGF export-cred-to-environment-
> > variable proposal adds knowledge of environment variables to
> > the GSS-API, which this proposal does not. Note that a
> > credential import/export facility along the lines of the
> > existing context import/export facility may be useful and
> > complements the GSS_Store_cred() interface; in fact, with
> > GSS_Store_cred() it should be possible to remove the
> > 'option_req' input parameter and export-to-env-var features
> >
> >N. Williams [Page 3]
> >
> >DRAFT GSS_Store_cred() Expires March 2004
> >
> > of the GGF's GSS_Export_cred() credential export proposal.
> >
> > [*] For the exact semantics see section 1.2, paragraph 6 of
> > draft-engert-ggf-gss-extensions-00.txt
> >
> > One side effect of GSS_Store_cred(), however, is that it
> > allows applications that can switch their current credential
> > store to move credentials from one store to the other; this
> > is a direct result of making it possible to store a
> > credential given a GSS-API credential handle. Perhaps there
> > should be some text allowing, or recommending, that
> > implementations of GSS_Store_cred() allow only the storage of
> > credentials acquired through credential delegation.
> >
> > Note to the RFC editor: please remove this note before
> > publication.]
> >
> >2 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)
> >
> >
> >N. Williams [Page 4]
> >
> >DRAFT GSS_Store_cred() Expires March 2004
> >
> > 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.
> >
> > 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().
> >
> >N. Williams [Page 5]
> >
> >DRAFT GSS_Store_cred() Expires March 2004
> >
> >
> >2.1 C-Bindings for GSS_Store_cred()
> >
> > 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,
> > 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)
> >
> > The two boolean arguments, 'overwrite_cred' and 'default_cred' are
> > typed as OM_uint32; 0 corresponds to FALSE, non-zero values
> > correspond to TRUE.
> >
> >3 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.
> > */
> > 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 ...
> >
> >4 Security Considerations
> >
> >
> >N. Williams [Page 6]
> >
> >DRAFT GSS_Store_cred() Expires March 2004
> >
> > 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()).
> >
> >5 References
> >
> >5.1 Normative References
> >
> > [RFC2026]
> > S. Bradner, RFC2026: "The Internet Standard Process - Revision
> > 3," October 1996, Obsoletes - RFC 1602, Status: Best Current
> > Practice.
> >
> > [RFC2119]
> > S. Bradner, RFC2119 (BCP14): "Key words for use in RFCs to
> > Indicate Requirement Levels," March 1997, Status: Best Current
> > Practice.
> >
> > [RFC2743]
> > J. Linn, RFC2743: "Generic Security Service Application Program
> > Interface Version 2, Update 1," January 2000, Status: Proposed
> > Standard.
> >
> > [RFC2744]
> > J. Wray, RFC2744: "Generic Security Service API Version 2 :
> > C-bindings," January 2000, Status: Proposed Standard.
> >
> >6 Author's Address
> >
> > Nicolas Williams
> > Sun Microsystems
> > 5300 Riata Trace Ct
> > Austin, TX 78727
> > Email: [email protected]
> >
> >Full Copyright Statement
> >
> > Copyright (C) The Internet Society (2003). All Rights Reserved.
> >
> > This document and translations of it may be copied and furnished to
> > others, and derivative works that comment on or otherwise explain it
> > or assist in its implementation may be prepared, copied, published
> > and distributed, in whole or in part, without restriction of any
> > kind, provided that the above copyright notice and this paragraph are
> > included on all such copies and derivative works. However, this
> > document itself may not be modified in any way, such as by removing
> > the copyright notice or references to the Internet Society or other
> > Internet organizations, except as needed for the purpose of
> >
> >N. Williams [Page 7]
> >
> >DRAFT GSS_Store_cred() Expires March 2004
> >
> > developing Internet standards in which case the procedures for
> > copyrights defined in the Internet Standards process must be
> > followed, or as required to translate it into languages other than
> > English.
> >
> > The limited permissions granted above are perpetual and will not be
> > revoked by the Internet Society or its successors or assigns.
> >
> > This document and the information contained herein is provided on an
> > "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
> > TASK FORCE DISCLAIMS 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.
> >
> >Acknowledgement
> >
> > Funding for the RFC Editor function is currently provided by the
> > Internet Society.
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >N. Williams [Page 8]
>
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
This message was posted through the Stanford campus mailing list
server. If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to [email protected]