GSSAPI v2 gss_process_context_token() inconsistency
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

GSSAPI v2 gss_process_context_token() inconsistency



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.

One view is in the draft Update 1 of RFC 2078
(http://www.ietf.org/internet-drafts/draft-ietf-cat-rfc2078bis-04.txt), it
talks a bit vaguely about some other uses for this function outside the v1
handling of gss_delete_sec_context() tokens.

Another view is in the C bindings
(http://www.ietf.org/internet-drafts/draft-ietf-cat-gssv2-cbind-05.txt)
where it says the call is still only for gss_delete_sec_context() tokens
but that implementors are discouraged from having gss_delete_sec_context()
emit any tokens at all.

In a slightly different third view, the v2 RFC 2078
(ftp://ftp.isi.edu/in-notes/rfc2078.txt) mentions that this call is now
"used to process context_tokens received from a peer once a context has
been established" which seems to imply that this call is always necessary
if any of the context routines return tokens.

There are several options to solve this issue. Here's a few that I thought of:

	- Simplify v2 by removing the call entirely. Forces the case to
	  be made for keeping the call around.
	- Change the behavior of gss_process_context_token() for v2. If
	  it's intended to process all context tokens, not just delete,
	  change the C bindings to reflect the new usage. Note that v1
	  users of the v2 library may have minor (no pun intended) side
	  effects because of the behavior change.
	- Invent a new call for the new behavior and update the documents
	  including the C bindings. This would be a nice clean wall between
	  the v1 and v2 worlds.

-craig
CyberSafe Corporation
(425) 837-1070


==========================================================================
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


Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.