Re: GGF's extensions to GSS in Public Comment

--6c2NcOVqGQ03X4Wi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Mon, Apr 05, 2004 at 07:39:05PM -0500, Nicolas Williams wrote:
> On Mon, Apr 05, 2004 at 01:46:46PM -0500, Von Welch wrote:
> > If so, I'd be interested in seeing your second draft. I think I can
> > see the benefits of your approach, but need see how the rubber and
> > road meet.
> 
> I'll send you a draft draft privately.

Or publically.  Attached.

I've not yet updated my I-D template, and this draft I-D needs more
text, particularly an intro.

Cheers,

Nico
-- 

--6c2NcOVqGQ03X4Wi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename="draft-williams-gssapi-cred-store-00.txt-formatted"


INTERNET-DRAFT                                          Nicolas Williams
                                                        Sun Microsystems
                                                          September 2003
                                                              April 2004



           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.


Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   The details of Generic Security Service (GSS) credential store
   management vary by platform and even by GSS mechanism.  This document
   defines a small extension to the GSS-API which facilitates the use of
   delegated GSS credentials by GSS applications running on multi-user
   platforms.

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].

Table of Contents

N. Williams							[Page 1]

DRAFT		GSS Credential Store API		Expires October 2004


   1.     Introduction                 pg. 3
   2.     GSS_Get_current_cred_store() pg. 3
   3.     GSS_Set_current_cred_store() pg. 3
   4.     C-Bindings                   pg. 4
   5.     Examples                     pg. 4
   6.     Security Considerations      pg. 4
   7.     Acknowledgements             pg. 4
   8.     References                   pg. 5
   8.1.   Informative References       pg. 5
   8.2.   Normative References         pg. 5
   9.     Author's Address             pg. 5


N. Williams							[Page 2]

DRAFT		GSS Credential Store API		Expires October 2004


1.    Introduction

   [Text needed on what is a "credential store" and what is a "current
   credential store,: and their relation to the callers' current
   execution context.]

   [See [gss_store_cred].]

2.    GSS_Get_current_cred_store()

   Inputs:

   o <none>

   Outputs:

   o major_status INTEGER,

   o minor_status INTEGER,

   o cred_store_handle CREDENTIAL STORE HANDLE

   Return status codes:

   o GSS_S_COMPLETE indicates that there is a credential store or that
   one can be created, when GSS_Store_cred() is called, for the current
   execution context of the caller.

   o GSS_S_UNAVAILABLE indicates that no credential store exists for the
   current execution context of the caller.

   o GSS_S_FAILURE indicates that an unspecified failure has occurred.

   This function returns a credential store handle that refers to the
   credential store from which credentials would be acquired given the
   current execution context of the caller.

   Credential store handles may not remain accessible when the caller
   switches the user of the execution context.

3.    GSS_Set_current_cred_store()

   Inputs:

   o cred_store_handle CREDENTIAL STORE HANDLE,

   Outputs:

   o major_status INTEGER,

   o minor_status INTEGER

N. Williams							[Page 3]

DRAFT		GSS Credential Store API		Expires October 2004


   Return status codes:

   o GSS_S_COMPLETE indicates that the given credential store will be
   used by subsequent GSS-API credential acquisition or storage made in
   the same execution context as that of the caller to
   GSS_Set_current_cred_store().  If the given store handle is
   GSS_C_NO_STORE then either a default or new (which is a
   platform-specific matter) credential store will be created and set as
   the current credential store.

   o GSS_S_BAD_STORE indicates that the given credential store handle
   is not recognized or refers to a credential store that no longer
   exists or is otherwise corrupt.

   o GSS_S_UNAVAILABLE indicates that the current credential store for
   the current execution context could not be set, possibly due to lack
   of resources.

   o GSS_S_FAILURE indicates that a generic failure has occurred.

   This function changes the credential store for the current execution
   context.

   Calls to this function MAY have platform-specific side effects (e.g.,
   setting environment variables, setting a process' "pag," etc...), but
   an implementation of it MUST NOT change the user context of the
   application, a restriction applicable only on multi-user platforms.

   The current credential store may change or become unavailable when
   the caller switches the user of the execution context.

4.    C-Bindings

   [...]

5.    Examples

   [...]

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()).

7.    Acknowledgements


N. Williams							[Page 4]

DRAFT		GSS Credential Store API		Expires October 2004

   [...]

8.    References

8.1.    Informative References

   [gss_store_cred]
      N. Williams, draft-williams-gssapi-store-deleg-creds-00:
      "GSS-APIv2 Extension for Storing Delegated Credentials," September
      2003, Status: Internet-Draft.

8.2.    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.

9.    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 (2004).  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 5]

DRAFT		GSS Credential Store API		Expires October 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 6]

--6c2NcOVqGQ03X4Wi--
-++**==--++**==--++**==--++**==--++**==--++**==--++**==
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]