Subject: Re: [kitten] Delayed credential resolution in GSSAPI

From: Martin Rex <[email-masked]>
Date: Fri, 1 Apr 2011 19:58:36 +0200 (MEST)

[email-masked] wrote:
> 
> My questions for the working group are these:
> 
> 1. Suppose I implement delayed resolution for the default initiator
> credential.  If the app inquires the name of the cred, my
> understanding is that I should pick a default identity and constrain
> the cred to only act as that identity.  (So, by asking the question in
> advance of calling gss_init_sec_context, you may change the answer.)
> Does that seem correct?
> 
> 2. We already implement delayed resolution for the default acceptor
> cred.  If the app inquires the name of the cred, we should determine a
> name (currently we return GSS_C_NO_NAME, which is probably wrong).  Is
> it enough that this name by *a* name which an initiator could use to
> authenticate to the service, or should the credential also be
> constrained to *only* accept tokens authenticating to that name?

Since it's me who is relying on this behaviour and has brought
up this question for MIT Kerberos ...

I just came across the following words in rfc2743 (GSS-API high-level):

  http://tools.ietf.org/html/rfc2743#page-39

   If credential acquisition is time-consuming for a mechanism, the
   mechanism may choose to delay the actual acquisition until the
   credential is required (e.g. by GSS_Init_sec_context() or
   GSS_Accept_sec_context()).  Such mechanism-specific implementation
   decisions should be invisible to the calling application; thus a call
   of GSS_Inquire_cred() immediately following the call of
   GSS_Acquire_cred() must return valid credential data, and may
   therefore incur the overhead of a deferred credential acquisition.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Fri, 1 Apr 2011 20:05:49 +0200 (MEST)

Another quote (sorry for the seperate message):

>    therefore incur the overhead of a deferred credential acquisition.

The above was from "2.1.4: GSS_Add_cred call" (but refers to acquire_cred),
and the following is from "2.1.1:  GSS_Acquire_cred call", from within
the second paragraph from the bottom of page 33.

  http://tools.ietf.org/html/rfc2743#page-33

                    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 GSS_C_NO_NAME, or a name
   resulting from applying GSS_Inquire_context() to an active context,
   or a name resulting from applying GSS_Inquire_cred() against a
   credential handle corresponding to default behavior. 

-Martin