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

[Srinivas Cheruku]

>  -----Original Message-----
>  From: Martin Rex [mailto:mrex at sap.com]
>  
>  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.
>  
[Srinivas Cheruku] So, sending empty protected message is not a standard
according GSSAPI V2 and is still supported by some apps. 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?

>  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?

>  
>  >
>  > 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.
>  
>  
[Srinivas Cheruku] GSS-API v1 TOK_ID for context deletion token is 0x0102. 
Maybe there are no interoperable applications that are using MIT GSS-API
code and sending the delete context token to peer to signal end of the
session.

Thanks,
Srini