Subject: KITTEN: IETF 75 - 76

From: Shawn M Emery <[email-masked]>
Date: Sun, 16 Aug 2009 00:26:34 -0600

Folks,

As our AD (Tim) had mentioned at the last session, we should gage 
interest in the working group going forward by polling the members to 
see what items they would be willing to work on between now and IETF 76 
(starting November 8).  Tim would like one or two new drafts to be 
created as an indicator.

Love had given a set of new work items that would be of interest, as 
follows:

    1. initialization/new credentials
    2. listing/iterating credentials
    3. exporting/importing credentials
    4. error message reporting
    5. asynchronous calls

...along with Alexey's recent request for policy/encryption strength.

We are looking for authors and editors for any of these new items or 
something else that you would like to see developed within KITTEN.

-- 
Shawn.

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 16 Aug 2009 11:32:13 +0100

> Folks,

Hi Shawn,

> see what items they would be willing to work on between now and IETF 
> 76 (starting November 8).  Tim would like one or two new drafts to be 
> created as an indicator.
>

I agree this is an issue, current APIs are awkward/insufficient in this 
area.

>    3. exporting/importing credentials

I think Leif has expressed interest in (3) before.

>    4. error message reporting

The last 2 are generally required for use by modern applications.

> something else that you would like to see developed within KITTEN.

I can't volunteer to edit anything at the moment, but I will review and 
comment.

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 16 Aug 2009 18:51:22 -0500

>    3. exporting/importing credentials

(1) is a complex matter as it requires interaction with users and needs
to cover such things as principal name, password, new password, PIN, PIN
change and other prompts.  A design is certainly possible.

(2) is really listing of principal names for which the caller has
credentials (we can already list mechanisms for which the caller has
credentials).  This is likely a difficult thing to design since we will
want to be able to control what principals GSS_Accept_sec_context() can
accept sec contexts for, and that means a significant revamp of the
semantics of CREDENTIAL HANDLEs _or_ a replacement for
GSS_Accept_sec_context().

>    4. error message reporting

Yes.  (I still believe in the "PGSSAPI" idea where, in the C bindings,
we change the semantics and type of the minor_status argument, though in
a binary backwards compatible way.  I can expand if desired.)

>    5. asynchronous calls

Developers can use threads to work around the lack of these, so it seems
to me that these should be a lower priority.

> ...along with Alexey's recent request for policy/encryption strength.

Yes.  This should be, IMO, a high priority.

> something else that you would like to see developed within KITTEN.

I'll edit, but I need co-authors who'll contribute text, API designs,
and energy to the list.

Nico
--

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Mon, 17 Aug 2009 18:49:37 +0200

> GSS_Accept_sec_context().

accept sec context is not really intresting since it doesn't make  
thinks not work. init sec context however it mostly useless since the  
consumers don't know about what credentials they have.

have a list of mechs there is credentials for is also mostly useless,  
i have [email-masked] (Kerberos), SU.SE\lha (NTLM), KTH.SE (Kerberos) E.KTH.SE 
  (sasl-digest-md5),  
[email-masked]:EA35DAB08BD8EC833C160FAFCDF03E4B13F72D6B (Kerberos) any  
many other, knowing that I have some Kerberos credentals is mostly  
useless.

Its not even possible to build ui to do specific selection, or  
selection other then providing a text field that you can do  
gss_import_name(GSS_C_NT_USER) on and hope that it work.

> a binary backwards compatible way.  I can expand if desired.)

Lets redo the api, ISC is broken as it since there is no way to add  
new tokens.

> to me that these should be a lower priority.

I disagree, threads consume lots of resources that and are very  
complicated to use.

> Yes.  This should be, IMO, a high priority.

And not over engineered. Let's solve the SASL problem and nothing more.

> I'll edit, but I need co-authors who'll contribute text, API designs,

Love

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 17 Aug 2009 12:26:32 -0500

On Mon, Aug 17, 2009 at 06:49:37PM +0200, Love Hörnquist Åstrand wrote:
> >credentials).  This is likely a difficult thing to design since we
> >will want to be able to control what principals
> >GSS_Accept_sec_context()  can accept sec contexts for, and that means
> >a significant revamp of the semantics of CREDENTIAL HANDLEs _or_ a
> >replacement for GSS_Accept_sec_context().
> 

Acceptors with creds for multiple principals have little choice but to
use GSS_C_NO_CREDENTIAL and check the resulting security context to see
if the acceptor principal (and mech, and, if we ever add it, QoP policy)
is acceptable to the app.  That's lame.  I'd rather be able to acquire a
CREDENTIAL HANDLE for all the principals I'm willing to accept sec
contexts for and then use that.

The GSS-API concept of CREDENTIAL HANDLEs is a set of credentials for
the same principal, but different mechanisms.  Changing this to allow it
to be a set of credentials for any {mechanism, principal} seems...
difficult, but perhaps fun anyways.

> i have [email-masked] (Kerberos), SU.SE\lha (NTLM), KTH.SE (Kerberos)
> E.KTH.SE (sasl-digest-md5),

Yes, this problem affects initiators too.  If you want to solve the
Identity Selection problem _above_ the GSS-API (and I agree that the
solutions do belong outside the GSS-API), then you need to solve the
CREDENTIAL HANDLE issue first.

[For the benefit of lurkers: in practice though you always have a
"default" principal, and you have to be able to choose a principal to
use in any given context.  The Identity Selection problem is not as easy
to solve as simply letting CREDENTIAL HANDLEs be sets of creds for any
{mech, princ}, but that is a very helpful first step.]

> Lets redo the api, ISC is broken as it since there is no way to add  

ISC?

I don't want to re-design the API from scratch if we can avoid it.
Moreover, all of the enhancements we're discussing are incremental,
_except_ for this one and the multi-princ credentials one; this one fits
right in as proposed above, and we can solve the multi-princ credentials
problem incrementally too.  If we had more problems to fix that are not
incremental then I'd agree on a whole re-design.

Also, I don't agree that there's no way to add new token types, if
that's what you meant.  You could add support for new tokens (e.g.,
re-key tokens, default QoP cipher change, ...) as follows:

a) provide a way to indicate that the app supports the new thing (this
   could be a credential handle property, but it could also be done
   using the PGSSAPI proposal);
b) provide new functions to output the new token types;
c) provide new major status codes (for existing per-msg token generating
   functions) indicating that the caller must first engage in some other
   type of token exchange (e.g., re-key);
d) provide new major status codes (for existing per-msg token consuming
   functions) indicating that an input token is of the wrong type (so
   the caller may then call the correct function with it).

(a) and (b) are the bare minimum that must be done, but you need (c) if
you want async re-keys (i.e., if you want the mech to decide when a
re-key is needed).  (d) is not strictly needed: app protocols have to be
revised anyways to use new token types, so we can expect apps to
identify token types.

> I disagree, threads consume lots of resources that and are very  

I agree that async versions are desirable.  I believe the other items on
Shawn's list are more important though, that's all.

> And not over engineered. Let's solve the SASL problem and nothing more.

I agree.  I want nothing to do with, for example, a language for
expressing cryptographic quality of protection policies.  I want only a
way to obtain non-hard-coded, context-specific policies.  The key is
context-specific (because the Kerberos mech can use any enctype in a
context-specific way -- you can't tell which it is just from the mech's
OID, unlike SCRAM).  (A context-specific SSF number is acceptable to
me as a way to support SASL.)

Nico
--

---

From: Leif Johansson <[email-masked]>
Date: Tue, 18 Aug 2009 00:13:28 +0200

> I think Leif has expressed interest in (3) before.

That was exporting unfinished contexts actually - slightly different.

> The last 2 are generally required for use by modern applications.

hmm, is asynchronous calls related to exportable contexts perhaps...?

	Cheers Leif

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 17 Aug 2009 17:25:01 -0500

> That was exporting unfinished contexts actually - slightly different.

Oh yes, that too (that's trivial, of course, though exporting non-fully
established contexts has to be allowed to fail).

> hmm, is asynchronous calls related to exportable contexts perhaps...?

No.  Think of how gss_init_sec_context() and gss_accept_sec_context()
can go off and do things like: DNS lookups, TGS exchanges, certificate
validation (including OSCP and/or CRL checking), ...  All those tasks
must complete before those functions can return, but each of those tasks
can take a long time to complete or fail to complete.

I.e., we want versions of gss_init/accept_sec_context() that will do as
much work as they can, then return without necessarily completing their
work, instead returning some completion event object so the application
can wait for completion in its event loop.

The basic problem here are is that async APIs tend to be very
OS-specific.  But I think we can still have an OS-agnostic design IF we
can rely on background threads (i.e., on a multi-threaded process
model).  Relying on bg-threads might not be feasible on systems where a
multi-threaded process model can't be relied upon (well, on such systems
the async functions can just always operate synchronously when called in
a single-threaded process).

Nico
--

---

From: Martin Rex <[email-masked]>
Date: Tue, 18 Aug 2009 01:02:07 +0200 (MEST)

> That was exporting unfinished contexts actually - slightly different.

exporting&importing unfinished security contexts will usually
break the gssapi architecture.

The context establishement calls take a number of arguments
that must be the same for the initial and all iteration calls,
and it is an implementation issue at which point which of these
parameters is accessed.

Fully established security contexts do not normally need access to
credentials (the gss_cred_id_t that was provided to gss_init_sec_context
or gss_accept_sec_context can be released when the security context
establishment has completed or failed).

During security context establishment, access to credentials might
be necessary at various stages, and the caller would have to
make sure the parameters during each iteration call are the same
as during the first call.

Credentials that are stored on a hardware token are often not
transferable, and also may require a serialization of the access.

> hmm, is asynchronous calls related to exportable contexts perhaps...?

What exactly do you mean by asynchronous calls??

GSS-API does not include message transport, so all calls are
by definition asynchronous.

Or were you thinking about the Kerberos 5 gssapi mechanisms communication
with the KDC during gss_init_sec_context() (and possibly during
gss_acquire_cred for some newer implementations)?

-Martin

---

From: Martin Rex <[email-masked]>
Date: Tue, 18 Aug 2009 01:10:08 +0200 (MEST)

> a single-threaded process).

To me that sounds like barking up the wrong tree.

If an application does not want to get blocked, it should use
seperate threads for the UI and other events that it does want
to do in parallel.  The application should take care about
and have control over each an every thread in a process.
Having service APIs create additional threads invisible to
the application will open a huge can of worms.

Maybe you want an API to specify timeouts after which a
gssapi call should give up and return an error?  Ideally,
that should already be configurable in an implementation specific
fashion (but often is not).

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 17 Aug 2009 18:14:30 -0500

> break the gssapi architecture.

We've had this argument.

> and it is an implementation issue at which point which of these

I don't see how this is an issue.  The implementation can make sure that
the exported partially established sec context encodes these arguments
so they can be checked later after importing.

> transferable, and also may require a serialization of the access.

None of that means that we can't have a partially established security
context export/import facility that is allowed to fail when
non-extractable keys in tokens are involved.  (Alternatively, export
might succeed and the exported sec context token might just have enough
information to either re-establish logged-in access to the token, or
call back into a service in the process that "exported" the sec context;
import could still fail, obviously.)

We can agree that GSS_Export_sec_context() either MUST NOT succeed for
partially established security contexts, or that it is OPTIONAL for it
to succeed in the case of partially established security contexts.  In
the former case we can then introduce a new function that does support
this feature, with all the above caveats.  We should stop having this
argument now.

> gss_acquire_cred for some newer implementations)?

The latter.  And no, gss_acquire_cred() cannot do this (because what
matters, in the krb5 case, is the target name passed to
gss_init_sec_context()).  And it's not just about Kerberos.  PKIX-based
mechanisms, such as PKU2U (or SPKM-*) may need to talk to third-parties
in either the initiator, acceptor, or both cases (e.g., to validate
certificates).  In both cases (Kerberos and PKIX) we have not only
message exchanges with KDCs, OCSP Responders, and/or CRL servers, but
also potentially DNS lookups (of KDC/OCSP/CRL server names).  All of
these are potentially very slow, particularly in failure cases (network
partitions, ...).  Single-threaded, async I/O style programs that would
normally remain responsive have to block in these functions, or else
they must create background threads in which to do the
gss_init/accept_sec_context() calls (in which case they'd be... creating
async versions of gss_init/accept_sec_context(), which proves the point
that they are doable).

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 17 Aug 2009 18:21:06 -0500

> the application will open a huge can of worms.

Of course that can be done, and that was my first response to Love.
However, implementors can well do better, in terms of efficiency, if
there are actual standard async variants of these.

To see why consider this: default stack sizes for threads can be quite
sizeable (e.g., 1MB in Solaris 32-bit, or 2MB in 64-bit).  An
application might have no idea how much stack space
gss_init/accept_sec_context() might need.

To be fair, a mechglue implementor who does the background thread thing
wouldn't necessarily know either, but chances are they will (one way or
another).  A mechglue and mechanism implementation where both support
the async functions might not even need anything more than a thread to
run a small I/O event loop, with tiny stack needs since all it'd do is
wait for I/O and call the application callback (which should probably
post an event to the application I/O loop).

> fashion (but often is not).

That's not enough.  Nor is it necessary in the case where mechglue and
mechanisms support thread cancellation.  Of course, that's a very
OS-specific feature that the C bindings don't remotely address.  So yes,
a timeout parameter would be nice, but it's still not enough.

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Tue, 18 Aug 2009 10:59:59 -0700

> CREDENTIAL HANDLE issue first.

The credential handle problem is already solved for init sec context,  
if you just can get hold of them.

GSS-API is part of the identity selection problem since its the holder  
of credentials.

The application/framework will need to drive authentication and select/ 
try credentials as it seems approproate and remember what of them was  
useful.

This would work today, if it was possible to get initial credentials  
and list existing/configured credentials

Love

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Tue, 18 Aug 2009 11:05:03 -0700

> ISC?

init sec context.

> I don't want to re-design the API from scratch if we can avoid it.

if we are doing an async api, its redoing the api.

> incremental then I'd agree on a whole re-design.

I find PGSSAPI very distasteful.

> re-key tokens, default QoP cipher change, ...) as follows:

There is no way to add more input variables to ISC.

ISC have been extended to day, for example for NFS. you have to  
acquire a special NFS credentials, modify the credential to select  
what enctypes the kernel supports, and then call ISC. This doesn't  
work for credential when you talk to different servers that have  
diffrent properties, like TLS channel bindings.

I'm not worried about rekeying, if you want to tackle that we are  
redoing the whole gss-api model.

Love

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Tue, 18 Aug 2009 11:06:41 -0700

> me as a way to support SASL.)

OM_uint32
gss_context_sasl_ssf(OM_uint32  *minor, gss_ctx_id_t ctx, OM_uint32  
*ssf);

Love

---

From: Love Hörnquist Åstrand <[email-masked]>
Date: Tue, 18 Aug 2009 11:09:39 -0700

> difficult, but perhaps fun anyways.

I don't care about this now, its not a problem I ever run in to.

In fact, I mostly run into the problem that app developer specify a  
credential handle, and for that reason the application doesn't work  
with aliases and other mechs that the app author though about.

Love

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 19 Aug 2009 11:32:15 -0500

> if you just can get hold of them.

True.

> and list existing/configured credentials

Sure.  An iterator following the same design principles as
gss_display_status() would look like:

OM_unit32 gss_list_default_cred_names(
	OM_uint32 *minor_status,
	gss_name_t  *name,
	int	    *more
);

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 19 Aug 2009 11:40:11 -0500

> I find PGSSAPI very distasteful.

If we could go back in time and make that first argument to all GSS
functions be an opaque pointer, a handle to an abstract app/lib context,
that'd be OK, yes?

I'm proposing that we do just that, only without the time travel part,
and with just a bit of backwards compatibility in the mechglue to detect
old apps / old mechs that expect that argument to be a OM_uint32 *.

That bit of backwards compatibility would be quite isolated, and it'd be
very similar to existing code in MIT krb5 to intern handles (in order to
distinguish between old apps and new ones, properly obtained handles
would have to be interned).

> There is no way to add more input variables to ISC.

Indeed.

> diffrent properties, like TLS channel bindings.

Yes.

> redoing the whole gss-api model.

Not really.  The SSPI does it, and the SSPI is very similar to the
GSS-API.  Re-keying would be an incremental change, not a fundamental
one (but it would require updates to app protocols in order for them to
be able to use it).  For SASL re-keying would be much more intrusive .
No, I don't care about re-keying.

---

From: Martin Rex <[email-masked]>
Date: Wed, 19 Aug 2009 21:23:58 +0200 (MEST)

> OM_unit32 gss_list_default_cred_names(

That call looks somewhat restricted to me.

How about something like this:

OM_uint32 gss_list_default_cred_names(
	OM_uint32    * minor_status,
	gss_name_t   * name,
	gss_OID_set  * mech_oids,
	int          * is_default,
	OM_uint32    * cred_context
);

That would also match what you have to feed into an
explicit call to gss_acquire_cred() in order to reliably
get a credentials handle for exactly and each one listed.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Wed, 19 Aug 2009 21:58:58 +0200 (MEST)

> No, I don't care about re-keying.

Re-keying will require re-design of the API.

I'm not aware about rekeying being available in SSPI.

It must be availabe in some way for schannel, because IIS is
able to perform renegotiation in order to request a client cert
after having looked at the URL -- but I do not think it exists
for NTLM or Kerberos 5 SSPs.  If I'm wrong, do you have an URL
to the Microsoft documentation describing how it works?

In traditional GSS-API it is not possible to modify a security
context once it has been established.  And a communication might
go entirely unidirectional after security context establishment
for the rest of its lifetime (e.g. the data channel of an FTP
with GSS-API extensions).

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 19 Aug 2009 15:29:14 -0500

> That call looks somewhat restricted to me.

It is.  It should be sufficient however.  (Here name would be an MN.)

If you care about specific mechs you could then call gss_add_cred() with
each name output by gss_list_default_cred_names() and inquire the
result.

> 	OM_uint32    * minor_status,

What's "cred_context"?  Would that correspond to the 'more' argument in
my variant?

But yes, it'd be quite useful (though not strictly necessary) to output
a mech OID set and is_default.  As long as only mech OIDs that are all
in the same family (and therefore have the same MN/exported name token
forms) are allowed to appear in mech_oids.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 19 Aug 2009 15:30:56 -0500

> Re-keying will require re-design of the API.

I don't agree.  It should be an incremental change to the API, though
requiring changes to app protocols.

> I'm not aware about rekeying being available in SSPI.

It is, when used for TLS.

> context once it has been established.  And a communication might

That's not a problem.

> with GSS-API extensions).

That's an app protocol problem (see previous caveats that re-keying
_obviously_ would require app protocol changes).

---

From: Martin Rex <[email-masked]>
Date: Thu, 20 Aug 2009 00:11:05 +0200 (MEST)

Nicolas Williams wrote:
> 
> >                                        And a communication might 

When I built our application framing protocol for exchanging GSS-API
protected data in 1996, I added a capability for security context
refresh into that framing protocol in order to support security
context refresh for the Kerberos 5 gssapi mechanism, because rfc1964
compliant Kerberos 5 mechanisms expire their security contexts.

(Microsoft tried it during W2K beta3 to enforce security context
 expiration in their Kerberos 5 SSP, but it created operational 
 problems which none of their apps was able to cope with, that
 they reverted that change in W2K rc1).

When the security context lifetime drops below a certain threshold,
my app will poll the validity of the credentials to check whether
they are valid longer than the remaining security context lifetime,
it will then periodically attempt to refresh the security context
prior to sending protected messages on a security context that
is close to expiration.  When the establishment of a new security
context succeeds (same target and src_name), then the old security
context is deleted and the new one is used for the protection
of future messages.

Technically, this has always been possible with all existing gssapi
mechanisms at the application level.  Just that hardly anyone seems
to be doing it.

The issues one has to deal with are:
Unavailability of credentials, credentials expiration, failure
to establish a new security context (the previous one is still around),
not getting into a deadly embrace when the server wants the client
to do a refresh, but the client is unable (or unwilling) to comply.

Stuffing parts of that below gssapi will significantly increase
the complexity of a gssapi mechanis, the gss-api semantics,
need additional API-calls -- while still requiring significant
changes/support from the application side.

IMHO -- if the functionality is needed, it can be, and should be
built at the application level entirely -- and it will work
just fine with all existing gssapi mechanisms.

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 19 Aug 2009 17:14:41 -0500

> just fine with all existing gssapi mechanisms.

I agree.  No one is actually proposing to add re-keying to the GSS-API,
so let's not bother.

One might argue that with sundry extensions the GSS-API would be a
useful API for using TLS, much as with the SSPI, therefore we should add
support for re-keying and other TLS-isms.  No one is proposing that
either, but if some one did propose it and intended to implement, then
I'd probably support such a proposal.

---

From: Martin Rex <[email-masked]>
Date: Thu, 20 Aug 2009 17:09:19 +0200 (MEST)

> It is.  It should be sufficient however.  (Here name would be an MN.)

An MN means that it refers to a singular identity/name in one
particular namespace, it does _not_ imply a single mechanism (oid) only.

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!

> each name output by gss_list_default_cred_names() and inquire the

gss_add_cred() is completely broken by design (unfortunately it was
too late in the process when I complained about this brokenness).

gss_add_cred() can only add components, and it begins either with
a default credential (one that gss_acquire_cred() would create when
given a GSS_C_NO_OID_SET list of mechanism OIDs), or with an
explicitly supplied credential.

So if you want to create a credential with a single mech_oid,
you can NOT use gss_add_cred() for that purpose, you MUST use
gss_acquire_cred() with a gss_OID_set containing that one mech_oid
instead.

> What's "cred_context"?  Would that correspond to the 'more' argument in

Yup.  similar to rfc-2744 definition of gss_display_status, where
there is a "OM_uint32 * message context" parameter. 

> forms) are allowed to appear in mech_oids.

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.

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

-Martin

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 20 Aug 2009 10:36:38 -0500

> particular namespace, it does _not_ imply a single mechanism (oid) only.

I made that clear further down where I referred to mech families.

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

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

I don't follow this.

> selection UIs that they show to users.  :)

What would descriptive_message have?  A description of the
mechanism/mechanism family?

What about lifetime?  Why is that necessary?  Sure, we could put all
outputs of GSS_Inquire_cred*() here.  Heck, cred_usage seems a lot more
useful that lifetime in this context.

---

From: Martin Rex <[email-masked]>
Date: Thu, 20 Aug 2009 20:00:30 +0200 (MEST)

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

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

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 20 Aug 2009 13:27:21 -0500

> In order to distinguish valid from expired credentials right away.

That only requires a boolean :)

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

> Now that you mention it -- I would like a cred_usage INPUT parameter here!

I thought so :)

> > [...]

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.

> enumerate aggregate credentials with names from distinct namespaces.

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

Nico
--