[Ietf-krb-wg] RFC 4121 - Context Deletion Tokens
mrex at sap.com
Thu May 6 13:06:18 EDT 2010
Srinivas Cheruku wrote:
> So, in GSSAPi v2, the delete_sec_context() should be called by peers
> - Maybe this is the reason why RFC 4121 states the same.
> Does this mean that the application should have its own way of ending a
> session and no GSS is involved in doing so?
Personally, I think so.
IIRC, FTP with GSS-API extension is using an empty protected message
to "securely" convey the end of the data transfer.
I argued for deprecating the context deletion token in GSS-API v2,
because in a lot of layered software architectures it is somewhat
difficult to indicate both, a fatal error and the need to transport
a token to the peer. Most software, when encountering a fatal error,
will just close the network connection.
In layered software, it is much easier to deal with app-level
concious termination "handshake" of a communication that is
error-free at the transport (protection) layer.
It is also very app-specific how to cope with a communication
failure (e.g. lost network connectivity) at some point in the
middle of a communication, and which stuff to commit/save and
which stuff to roll-back.
> So, why MIT code is still generating context deletion token
> with TOK_ID 0x0405?
Backwards interop, I assume. That token is likely ignored (and hopefully
passed to gss_release_buffer()) by the calling application.
More information about the krbdev