Re: RFC 4121 - Context Deletion Tokens

Srinivas Cheruku wrote:
> 
> So, in GSSAPi v2, the delete_sec_context() should be called by peers
> independently 
> 
> - 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.

-Martin
_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg <at> lists.anl.gov
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg