Subject: [kitten] Delayed credential resolution in GSSAPI

From: [email-masked]
Date: Mon, 21 Mar 2011 11:36:22 -0400 (EDT)

GSSAPI has the concept of a default credential.  You can use it by
passing GSS_C_NO_CREDENTIAL to init/accept_sec_context, and you can
acquire a handle to one by passing GSS_C_NO_NAME to acquire_cred.

It is sometimes advantageous not to decide right away on an identity
for the default credential (or even for non-default credentials, but I
won't cover that case here).  When accepting, you might want to
determine the server identity based on the initiator tokens; this
behavior is sanctioned in RFC 2743 section 1.1.1.3.  When initiating,
you might have multiple identities available and might want to choose
one based on the target name or other information.

The GSSAPI allows callers to query the name of a credential.  For an
initiator cred, RFC 2744 section 5.5 mandates that the returned name
(if canonicalized to an MN) match the src_name seen by any acceptor.
For an acceptor cred, I'm not sure if RFC 2743 or 2744 lay down any
specific rules beyond that some name be returned.

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?