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