RFC 4121 - Context Deletion Tokens

[Srinivas Cheruku]

Hi,

 

>From RFC 2743 - APPENDIX B

 

COMPATIBILITY WITH GSS-V1

 

   The following GSS-V1 constructs, while supported within GSS-V2, are

   deprecated:

 

 

      GSS_Delete_sec_context() facility for context_token usage,

      allowing mechanisms to signal context deletion, is retained for

      compatibility with GSS-V1.  For current usage, it is recommended

      that both peers to a context invoke GSS_Delete_sec_context()

      independently, passing a null output_context_token buffer to

      indicate that no context_token is required.  Implementations of

      GSS_Delete_sec_context() should delete relevant locally-stored

      context information.

 

 

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?

 

So, why MIT code is still generating context deletion token with TOK_ID
0x0405?

 

Thanks,
Srini

 

From: Srinivas Cheruku [mailto:srinivas.cheruku at gmail.com] 
Sent: Thursday, May 06, 2010 3:55 PM
To: 'krbdev at mit.edu'; 'ietf-krb-wg at anl.gov'
Subject: RFC 4121 - Context Deletion Tokens

 

Hi,

 

>From RFC 4121:

4.3.  Context Deletion Tokens

 

   Context deletion tokens are empty in this mechanism.  Both peers to a

   security context invoke GSS_Delete_sec_context() [RFC2743]

   independently, passing a null output_context_token buffer to indicate

   that no context_token is required.  Implementations of

   GSS_Delete_sec_context() should delete relevant locally-stored

   context information.

 

whereas according to RFC 1964, a context deletion token similar to that of
MIC token but with the corresponding TOK_ID for context deletion token. This
context deletion token can be sent to the peer and the peer can delete its
context indicating closing of session.

 

But how would this work when using new token format as defined in RFC 4121.
How can a peer ask another peer to end the context/session?

 

>From MIT code, I found that the code is using the TOK_ID as below and using
the same token format as MIC Token for newer encryption types also which is
not specified in RFC 4121 - Why?

#define KG2_TOK_DEL_CTX         0x0405

 

I am confused? Can anyone help me understand the context deletion tokens
better when using newer encryption types?

 

Thanks,
Srini