[15762] in Kerberos_V5_Development

home help back first fref pref prev next nref lref last post

Re: [Ietf-krb-wg] RFC 4121 - Context Deletion Tokens

daemon@ATHENA.MIT.EDU (Martin Rex)
Thu May 6 13:17:47 2010

From: Martin Rex <mrex@sap.com>
Message-Id: <201005061706.o46H6IXU001505@fs4113.wdf.sap.corp>
To: srinivas.cheruku@gmail.com (Srinivas Cheruku)
Date: Thu, 6 May 2010 19:06:18 +0200 (MEST)
In-Reply-To: <4be2aa2b.8e83e30a.683c.37db@mx.google.com> from "Srinivas
	Cheruku" at May 6, 10 05:08:12 pm
MIME-Version: 1.0
Cc: ietf-krb-wg@anl.gov, krbdev@mit.edu
Reply-To: mrex@sap.com
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu

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
_______________________________________________
krbdev mailing list             krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

home help back first fref pref prev next nref lref last post