Subject: Re: Single canonical names

From: Martin Rex <[email-masked]>
Date: Thu, 4 Nov 2004 22:33:09 +0100 (MET)

Nicolas Williams wrote:
> 
> On Mon, Oct 25, 2004 at 04:36:25PM -0400, Sam Hartman wrote:
> > >>>>> "Nicolas" == Nicolas Williams <[email-masked]> writes:
> > 
> >     Nicolas> Also, for default name, think of the MIT krb5 ccache.  It
> >     Nicolas> can store tickets for more than one client principal, but
> >     Nicolas> the ccache file format specifies a default principal name
> >     Nicolas> so that even if one does store tickets for multiple
> >     Nicolas> different client principals it is always clear which to
> >     Nicolas> use when not explicitly requesting one or another name.
> > 
> > Remember the thread on krbdev where we proposed to drop that and use
> > the best match principal for the service in question.
> 
> That does not change the fact that one could (and one implementor has)
> treated Kerberos credentials in that way.  This helps me view the
> Kerberos V mechanism as not so different from x.509 certificate-based
> mechanisms w.r.t. to credentials having multiple names associated with
> them.

As I mentioned in my last Email, a gss-api credential may be composed
of several credentials for seperate mechanisms.  However for a single
mechanism, a GSS-API credential may refer only to one single identity
(principal,name).

It is OK if a gssapi mechanism allows an application to select
a particular credential out of a set, depending on either an explicit
name supplied by the application or a locally configured default
when the application calls gss_acquire_cred().  However when
the gss_acquire_cred() returns, the mechanism does not yet know
to which target the application is going to authenticate, however
the decision to which identity the returned credentials handle
refers must have been made and is irreversible.

A spec weasel might try to loophole the case where gss_init_sec_context()
is called with GSS_S_NO_CREDENTIAL, but an application may prefer to
use seperate calls for the distinct purposes (so that a credential-related
error will be caught and reported before a network connection has been
established -- usually gss_init_sec_context() will be called after
a network connection has been established, and if it fails, the app
will have to close the network connection and leave the server in
the dark why it rattled the door...  And if you really care about
servers, then you shouldn't write clients that behave like that.

-Martin

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 4 Nov 2004 16:16:50 -0600

> mechanism, a GSS-API credential may refer only to one single identity

A given *CREDENTIAL HANDLE*, yes.  But looking a t a very specific kind
of credential, a PKI cert, it's clear that it may respond to several
names.  My point is that it'd be nice if the app could deal with that
and pick one name, rather than leave the selection to a spec or to local
configuration.

One way to do this would be through an abstraction of the "credential
store" -- think of a function to acquire all the credentials that are in
the "curren credential store."

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 4 Nov 2004 16:53:16 -0600

> the "curren credential store."

Sam points out that then one could not distinguish between a pair of
credential handles that correspond to different names of the same
credential, which for a GSS equivalent of the 'klist' command would be a
pretty annoying problem.  An alternative to this interface that we've
discussed has a different problem.  We may need both.

Nico
--