Re: GSS-APIv2 Extension for Storing Delegated Credentials

[Nicolas Williams <Nicolas.Williams%sun.com@localhost>]

On Wed, Sep 10, 2003 at 05:34:16PM +0200, Daniel Kouril wrote:
> On Mon, Sep 08, 2003 at 08:07:03AM -0700, Nicolas Williams wrote:
> > I just posted the following I-D, which I think the KRB WG and
> > implementors of draft-ietf-secsh-gsskeyex may find interesting:
> > 
> > http://www.ietf.org/internet-drafts/draft-williams-gssapi-store-deleg-creds-00.txt

> I'm without Internet connectivity just now, so I can't read it, but according

I'll e-mail it to you separately.

> to the abstract it seems to address similar area as the "GSS-API Extensions"
> draft by GGF (available from
> http://www.ietf.org/internet-drafts/draft-engert-ggf-gss-extensions-00.txt).
> Perhaps it would make sense to coordinate the effort with GGF?

Unfortunately, the GGF's export-credential-to-environment-variable
proposal has a problem: it imposes the use of environment variables as
the method for referencing credentials stores, as well as the "current"
credential store.

In private exchanges with one of the GGF proposal's co-authors it's also
become clear that the GGF's proposal implicitly deals with creation of
credential stores as well and I think they convinced me that it would be
nice to have a generic interface for acquiring handles to credential
stores and setting the "current" credential store[*] so that
applications can avoid knowledge of mechanism-specific details of how to
create a credential store or set the current credential store.  But I
think such an interface should be described separately from the
GSS_Store_cred() described in my I-D , primarily on account of the
addition of the concept of credential store management to the GSS-API,
which GSS_Store_cred() (and the GSS-APIv2 as it stands) does not
require.

So, as you can see I've had some exchanges with one co-author of the GGF
proposal, some of which was copied to what I think is a GGF mailing
list.

[*]  There's no credential store handle input argument to
     gss_acquire/add_cred() or gss_init/accept_sec_context(), so there
     has to be a current credential store context for their use (it
     could be thread-local, global to a process, global to a login
     session, global to a host - those being platform-specific details).

Cheers,

Nico
--