Re: KITTEN: IETF 75 - 76

[Martin Rex <Martin.Rex at sap.com>]

Nicolas Williams wrote:
> 
> On Thu, Aug 20, 2009 at 05:09:19PM +0200, Martin Rex wrote:
> >
> > Thinking about it, I would actually want to add two more function
> > parameters:
> >        OM_uint32    * lifetime,
> >        gss_bufFer_t   descriptive_message,
> > 
> > to allow application writer to show additional information in
> > selection UIs that they show to users.  :)
> 
> What would descriptive_message have?  A description of the
> mechanism/mechanism family?

An implementation specific text provided to (human) end users
that will help them to recognize/distinguish the nature or purpose
of the particular credential.


> 
> What about lifetime?  Why is that necessary?

In order to distinguish valid from expired credentials right away.

The creation (or refresh) of credentials is still a local matter,
and the information that credentials are available in theory, but
unusable because they're expired is quite helpful.


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

If you look at the spec, gss_acquire_cred() and gss_inquire_cred()
can fail with GSS_S_CREDENTIALS_EXPIRED, and when they do, the
caller does not get any information about the credentials at all.

With the new API call, expired credentials still don't have to
be created -- the returned information is about "conceivable"
credentials only, not real ones.


>
> 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!


> 
> > A Kerberos principal is going to be an MN for the rfc1964/rfc4121 mech OID,
> > for the pre-rfc1964 mechoid and for the IAKERB mechoid.
> > 
> > But I would NOT want to require the name to be an MN here!
> 
> How could it be anything but?  Oh sure, for a family of mechanisms the
> name could be one that's imported with GSS_Import_name() and a
> mech-specific name type OID, or GSS_C_NULL_OID, and not canonicalized.
> But such a name would likely not be useful for credential acquisition
> for other mechanisms outside that family.
> 
> > I do not want to require that the returned name is an MN (because this
> > would take away the possibility for the gssapi mechanism to
> > select/negotiate the best common mechanism and _require_ the user to
> > perform an a-priori conscious selection.

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.


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.

Possible namespaces for the above could be NameUserPrincipal,
NameSamCompatible, and even an enterprise name (which is, AFAIK
not an MN), without precluding an aggregate credential that
still allows negotiation of the actual mechanism to be used.


-Martin