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

[Martin Rex]

Srinivas Cheruku wrote:
> 
> >  >
> >  > 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.
>  
> [Srinivas Cheruku] So, sending empty protected message is not a standard
> according GSSAPI V2 and is still supported by some apps.

It is one possible means for an application to signal "end of transmission"
at the application layer securely.  This can be accomplished with
*any* app-specific distinct protected message.

Since applications have to deal with network errors and defective peer
applications anyways, dealing with "closure" at the application level
is pretty trivial and straightforward -- or unnecessary.

> How does SAP
> software e.g. SAPGui and SAP Sever deal with context deletion tokens e.g.
> how will SAP signal ending the session - using GSS-API token or its own way?

Exactly the same way as when not using SNC.  It is an application-
specific decision which _may_ involve application-specific signaling
in some situations.

Most environments that use GSS-API are not capable of dealing
with context deletion tokens.  A context deletion token is a
context-level token, and will have to be passed to
gss_process_context_token() by the receipient. A context deletion
token MUST NOT be passed to message protection functions.


> 
> >  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.
> 
> [Srinivas Cheruku] Sorry, but I still didn't understand the logic behind
> deprecating context deletion token in GSS-API v2. Yes, I understand that
> most of the software when encountering fatal error will just close the
> network connection. But still I think that it would be good to support
> context deletion token so that when all goes well, the peer can signal
> context deletion when required. Maybe I am not looking at the big picture?

If you add gss-api protection in a fairly minimalistic fashion
such as in the FTP Security Extensions for the Data Channel (rfc-2228),
then having to deal with an explicit context deletion token would
significantly increase complexity.

If you add gss-api protection to a more powerful application level
communcation, then their either already is an application level
signaling for end-of-communication or it can be trivially added,
whereas adding support for a context deletion token requires
additional complexity.


Personally, I think that a context deletion token is a
spare kitchen sink that nobody needs, because its semantics
can be more easily obtained in an app-specific fashion.


-Martin