Re: GSSAPI v2 gss_process_context_token() inconsistency

[Martin Rex <martin.rex at sap-ag.de>]

Craig Hotchkiss wrote:
> 
> This call seems to have an inherent problem in that the behavior from v1
> has changed but the function name remains the same. Since it's impossible
> in the library to determine which version the user is attempting to
> leverage, it's impossible to behave differently which makes life difficult
> for implementors of GSSAPI libraries that are trying to be v1 and v2
> compliant.
> 
> The differing behaviors are that both RFC 2078 and Update 1 allude to a new
> use for this call -- to handle all context tokens in v2, not just the
> delete_sec type from v1. However, the C Bindings do not reflect the new v2
> usage which casts some doubt to my interpretation.

That's not quite the intention as far as I understand.
gss_process_context_token() is supposed to consume all context level
tokens after either context-establishment calls gss_init_sec_context()
and gss_accept_sec_context() has already returned GSS_S_COMPLETE.
For a context establishment that needs an odd number of message exchanges
(1, 3, (2n-1)) the last context-level token is normally created on the
initiator side and returned from gss_init_sec_context() along with
GSS_S_COMPLETE.

When the acceptor then does it's final call to gss_accept_sec_context()
it expects to see GSS_S_COMPLETE and no more context level tokens.
But in some cases the context establishment may fail on this final
step, and it is now permitted to gssapi mechanim implementations
to return a context-level token along with a fatal routine error
to propagate the error back to the initiator at the gssapi level.

However it depends on the application whether it actually transfers
this token back, or if it simply releases and ignores it, and propagates
an error at the application level (or simply drops the connection).
When the application transfers such a final and unexpected token,
the initiator may no longer pass it to gss_init_sec_context(),
because this call had returned GSS_S_COMPLETE on the previous iteration.

This is where gss_process_context_token() gets called and what is
documented in RFC2078 / bis.  Passing regular context establishment
tokens to gss_process_context_token() results in undefined behaviour.

I don't think that it is hard to implement this "change", since
the existance of a context-level error propagation token is
gssapi mechanism specific -- i.e. if it is not defined in the
mechanism specification then it is not permitted for this
mechanism because it would impair interoperability.


This misalignment was #9 on my list of "pending alignment issues
of C-Bindings with rfc2078bis" in a message to
the CAT mailing list on May, 1st, 1998

-Martin

==========================================================================
This message was posted through the Stanford campus mailing list
server.  If you wish to unsubscribe from this mailing list, send the
message body of "unsubscribe ietf-cat-wg" to majordomo at lists.stanford.edu