Subject: RE: some gssapi error handling clarifications

From: "John Wray, Digital DPE, 508/486-5210 30-Oct-1997 0908" <[email-masked]>
Date: Thu, 30 Oct 97 09:22:26 EST

Martin writes:

>- what is supposed to happen when an application calls
>  gss_accept_sec_context() or gss_init_sec_context() with the
>  handle of an already fully established security context.
>
>  I'd like to require the gssapi mechanism to return an error,
>  and I think this should go into the documentation.
>  GSS_S_FAILURE is the closest among the currently defined
>  major status codes -- should there be a new one?

I'd be quite happy with GSS_S_FAILURE, unless this situation is considered
common enough to warrant its own specific error code.

>- what is supposed to happen when an application calls
>  gss_accept_sec_context() or gss_init_sec_context() and supplies
>  an explicit credentials handle on the first call, and
>  GSS_C_NO_CREDENTIAL or a different credential for the
>  continuation call(s)?
>
>  I'd like to require the gssapi mechanism to notice and error
>  for at least the two obvious cases:
>
>   - the gss_cred_id_t changes between initial and continuation calls.
>
>   - the non-NULL gss_cred_id_t has been released between calls.
>     (well, at least for the language environments where 
>      and cases when this is **easy** to recognize).
>
>  or do folks feel that the existence of GSS_S_DEFECTIVE_CREDENTIALS
>  makes consistency checks on the credentials an implicit compliance
>  requirement? (I don't think so).

I agree with you that the specs don't currently require consistency checks on
all calls.  However, I don't see this as a problem.  In particular, I'd expect
that a mechanism might copy everything it needs from the credential into the
context on the first call to gss_init/accept_sec_context, and ignore the
cred_handle parameter on subsequent calls.  I don't think we should prohibit
this behavior by forcing consistency checks on each call by mechanisms that
wouldn't otherwise perform them.  A mechanism that does use the cred_handle on
subsequent calls should do whatever it feels is necessary to assure itself that
the referenced credential is still "substantially equivalent" to the one
presented originally (for example, it's conceivable that the credential's
expiration time might have been extended by a non-GSSAPI operation between
context calls, but I wouldn't think this should cause context establishment to
fail), and can return GSS_S_DEFECTIVE_CREDENTIAL if it isn't.

John

---

From: Martin Rex <[email-masked]>
Date: Thu, 30 Oct 1997 20:50:46 +0100 (MEZ)

> common enough to warrant its own specific error code.

It *shouldn't* be a common situation.  :-)
GSS_S_FAILURE is fine with me.

> wouldn't otherwise perform them.

I'd like to *require* a check on the handle value.
I'd like to *recommend* further sanity checks.
Although certain mechanisms may not actually access app-supplied
credentials on continuation calls, they should still do sanity check
on the handle.  This is primarily to ensure application portability.
Most of the time application programmers will check their implementation
only against the specific mechanism they have handy before they ship.

If we want to allow plug and play or to SPNEGOtiate gssapi mechanisms,
then we should try to catch as many *obvious* application bugs as possible.

>
>                                  A mechanism that does use the cred_handle on
> subsequent calls should do whatever it feels is necessary to assure itself
> that the referenced credential is still "substantially equivalent" to the one

Creation and refresh of credentials is a local matter.  The mechanism
should try to deliver a robust service especially for external events
(outside of the application's use of gssapi).

Your example touches one of these robustness issues.  Yes, when an
external event outside of the gssapi-calls changes the characteristic
of the object described by the credential handle, then it may be
necessary to copy information from the credential into the context
during the initial call to init_sec_context() or accept_sec_context()
in order to provide a robust service.  The verification of the handle
handle VALUE should still be done to detect application misbehaviour.

-Martin