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

[Srinivas Cheruku]

Thank you. I agree with you.

>  -----Original Message-----
>  From: Martin Rex [mailto:mrex at sap.com]
>  Sent: Tuesday, May 11, 2010 12:09 AM
>  To: Srinivas Cheruku
>  Cc: mrex at sap.com; krbdev at mit.edu; ietf-krb-wg at anl.gov
>  Subject: Re: [Ietf-krb-wg] RFC 4121 - Context Deletion Tokens
>  
>  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