Subject: acquire_cred/add_cred with name

From: Martin Rex <[email-masked]>
Date: Wed, 3 Dec 1997 19:48:15 +0100 (MEZ)

I'm (still) unhappy with the comment in C-Bindings regarding the behaviour
of gss_acquire_cred()/gss_add_cred() when combining GSS_C_BOTH or
GSS_C_INITIATE with an explicit name:

   7.2.  gss_acquire_cred

   Some implementations may therefore not support the acquisition of
   GSS_C_INITIATE or GSS_C_BOTH credentials via gss_acquire_cred for any
   name other than an empty name.

   7.3.  gss_add_cred

   Some implementations may therefore not support the acquisition of
   GSS_C_INITIATE or GSS_C_BOTH credentials via gss_add_cred.

I'd like to see a *requirement* to support not only the empty name,
but also all explicit names that a mechanism returns from inquire_cred()
or the local side from inquire_context().

In our application I have to be able to create an equivalent security
context (a clone clone for all exposed characteristics except lifetime)
for the following two reasons:

   - security context refresh

   - parallelizing independent tasks while retaining sequencing
     protection (in our case, we're processing them in different
     processes, but multiplex them over the same transport channel).

This is done at the lower protocol levels, not at the application
level where the initial authentication is performed.  In order to
offer this service, only security contexts that have the exact same
characteristics are acceptable.  To minimize side-effects, I inquire
the existing context and create a new context by using that information
to acquire_cred and init/accept_sec_context().  

If someone implements a new (or changes an existing) GSS-API mechanism 
to manage multiple independent credentials and giving the user a choice
to change the meaning of the "default" to whatever he likes whenever
he likes, then it is necessary for an application to specify explicitly
which credentials are to be used to implement things like security
context refresh.

-Martin