x

git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@24171 ec53bebd-3082-4978-b11e-865c3cabbd6b
2008-12-11 05:11:55 +00:00
parent 8eb10d7b45
commit fc27e9b239
1 changed files with 673 additions and 0 deletions
--- a/doc/standardisation/draft-ietf-kitten-gssapi-store-cred-02.txt
+++ b/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]
+
+