Re: KITTEN: IETF 75 - 76

[Nicolas Williams <Nicolas.Williams at sun.com>]

On Thu, Aug 20, 2009 at 08:00:30PM +0200, Martin Rex wrote:
> Nicolas Williams wrote:
> > What about lifetime?  Why is that necessary?
> 
> In order to distinguish valid from expired credentials right away.

That only requires a boolean :)

> > Sure, we could put all outputs of GSS_Inquire_cred*() here.
> 
> I see a difference here.  GSS_Inquire_cred() is about _real_ credential
> handles.  The new API call is about _conceivable_ credentials which
> the mechanism does not actually need to create.

Do you mean that, for example, if you have expired Kerberos creds then
this function could still return the principal name associated with
them, even though the creds are expired?  Or that if you have no creds,
not even expired ones, but the mechanisms could derive a principal
name(s) from your local user ID, then this function could return that?

> > Heck, cred_usage seems a lot more useful that lifetime in this context.
> 
> Now that you mention it -- I would like a cred_usage INPUT parameter here!

I thought so :)

> > > But I would NOT want to require the name to be an MN here!
> > [...]
> On a Windows platform, there might be a multi-mechanism offering
> ntlm _and_ Kerberos 5.  In theory these use distinct namespaces,
> in practice, a mapping is possible if they both refer to an
> account in a W2K+ Active Directory.

That's not true in all configurations, but OK.  I'd be OK with that
provided that there was some name mapping function that, given an MN,
returns a generic NAME object that the MN can be "canonicalized" to.

> Do we want an API call that can only enumerate credentials for
> individual mechanisms, or more appropriately, an API call that can
> enumerate aggregate credentials with names from distinct namespaces.

I want an API that is mechanism/mechanism-family specific, at least as
an option.

Nico
--