![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
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.