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

From: "Srinivas Cheruku" <[email-masked]>
Date: Thu, 6 May 2010 17:08:12 +0530

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:[email-masked]] 
Sent: Thursday, May 06, 2010 3:55 PM
To: [email-masked]'; [email-masked]'
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

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Greg Hudson <[email-masked]>
Date: Thu, 06 May 2010 12:49:09 -0400

> So, why MIT code is still generating context deletion token with TOK_ID

Based on the version control history, I can tell you that the code to
generate that token dates back to 1993 and hasn't been substantively
changed since.

---

From: Martin Rex <[email-masked]>
Date: Thu, 6 May 2010 19:06:18 +0200 (MEST)

> 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

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 6 May 2010 10:34:44 -0500

On Thu, May 06, 2010 at 05:08:12PM +0530, Srinivas Cheruku wrote:
> session

Yes.

>         and no GSS is involved in doing so?

Well, you'd want to protect the application "delete context" message
with a MIC or a wrap.

> So, why MIT code is still generating context deletion token with TOK_ID

I don't know.

Nico
--

---

From: "Srinivas Cheruku" <[email-masked]>
Date: Fri, 7 May 2010 09:30:51 +0530

[Srinivas Cheruku] Do you mean that we can generate a MIC token with message
as NULL for delete context and can be sent to the peer and this is an
interoperable approach? Is there any interoperable way of signalling delete
context to the peer?

Thanks,
Srini

---

From: "Srinivas Cheruku" <[email-masked]>
Date: Fri, 7 May 2010 09:32:05 +0530

[Srinivas Cheruku] Thank you. Does that mean this part of the code needs to be removed?

---

From: "Srinivas Cheruku" <[email-masked]>
Date: Fri, 7 May 2010 09:57:26 +0530

>  -----Original Message-----
>  From: Martin Rex [mailto:[email-masked]]
>  
>  Srinivas Cheruku wrote:
>  >
[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?

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

>  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

---

From: "Douglas E. Engert" <[email-masked]>
Date: Fri, 07 May 2010 09:48:24 -0500

> interoperable approach? Is there any interoperable way of signalling delete

All the gssapi applications I have ever seen, delete the context based
either because of a network failure, or the client and server have agreed
using some non-GSSAPI message to close the connection.

In every case the applications need to call gss_delete_sec_context on
both ends.

So is there some special reason you need to use the GSSAPI delete context
message?

gss_delete_sec_context will return a token, and this can be sent if the transport
connection is working but is not strictly required.

> krbdev mailing list             [email-masked]
> https://mailman.mit.edu/mailman/listinfo/krbdev
> 
> 

-- 

  Douglas E. Engert  <[email-masked]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Tim Alsop <[email-masked]>
Date: Fri, 7 May 2010 15:53:41 +0100

Doug,

> So is there some special reason you need to use the GSSAPI delete context message?

Srini and I are working on testing our own GSS library for RFC4121 compliance and testing interoperability with MIT, Heimdal, Microsoft SSPI etc. and whilst doing this we found some inconsistencies between MIT code and the RFC, which is why Srini asked about it.

Thanks,
Tim Alsop
CyberSafe

---

From: "Douglas E. Engert" <[email-masked]>
Date: Fri, 07 May 2010 09:58:44 -0500

> Maybe I am not looking at the big picture?

Could be. In most cases GSSAPI is used to protect existing protocols,
that already have a way to signal termination.

> code and sending the delete context token to peer to signal end of the

There might be, but it only signals the the peer's GSSAPI that it can close
the GSSAPI context not necessarily the applications session. The application
could continue to run without using wrap/unwrap or even establish a new GSSAPI
context on both ends and go back to using wrap/unwrap.

--

---

From: "Douglas E. Engert" <[email-masked]>
Date: Fri, 07 May 2010 10:13:53 -0500

> Srini and I are working on testing our own GSS library for RFC4121 compliance and testing interoperability with MIT, Heimdal, Microsoft SSPI etc. and whilst doing this we found some inconsistencies…

OK, well that explains, it. But some of the questions like the RR questions lead me
to believe he might be a lone novice just looking at GSSAPI code.

But has has been pointed out the code in question was from 1993 and may not be
used but is still in the RFC and may be broken in some implementations.

--

---

From: Tim Alsop <[email-masked]>
Date: Fri, 7 May 2010 16:20:23 +0100

Doug,

> OK, well that explains, it. But some of the questions like the RR questions lead me to believe he might be a lone novice just looking at GSSAPI code.

He is certainly not a novice, I can assure you. We all make mistakes sometimes, especially when working for many hours.

> But has has been pointed out the code in question was from 1993 and may not be used but is still in the RFC and may be broken in some implementations.

This is why we check various implementations as well as the RFC, and we sometimes need to ask questions like on this thread, to confirm our understanding from our findings.

Thanks again for your help.

Tim

---

From: "Douglas E. Engert" <[email-masked]>
Date: Fri, 07 May 2010 10:45:13 -0500

> He is certainly not a novice, I can assure you. We all make mistakes sometimes, especially when working for many hours.

All of his recent messages were from gmail.com and gave to indication of who he works for.
(I see in ietf-wg lists, in 8/21/2008 and 4/14/2009 he did use CyberSafe.com,
but had not sent in any e-mails between 8/5/2009 and 5/6/2010.)
My memory span is not what it used to be and I did not recognize his name.

These mailing lists get a lot of newbies who are smart and ask lots of questions.
Many times the questions arise from some simple misunderstanding of something that
is obvious to an old timer. I am sorry, if the term novice offended anyone.

> This is why we check various implementations as well as the RFC, and we sometimes need to ask questions like on this thread, to confirm our understanding from our findings.

It is good to see that you are looking at the interoperability.

--

---

From: Tim Alsop <[email-masked]>
Date: Fri, 7 May 2010 16:49:20 +0100

Doug,

Thankyou for your understanding. I might be wrong, but I think Srini uses his gmail account on public news lists since it reduces spam to his CyberSafe email account. I will suggest that he uses his CyberSafe account in future, so that he is not considered a novice ! Anyway, I don't think anybody was offended. As always, your help is appreciated.

Take care,
Tim

-----Original Message-----
From: Douglas E. Engert [mailto:[email-masked]] 
Sent: 07 May 2010 16:45
To: Tim Alsop; Srinivas Cheruku; Kerberos WG; Kerberos WG
Subject: Re: [Ietf-krb-wg] RFC 4121 - Context Deletion Tokens

All of his recent messages were from gmail.com and gave to indication of who he works for.
(I see in ietf-wg lists, in 8/21/2008 and 4/14/2009 he did use CyberSafe.com, but had not sent in any e-mails between 8/5/2009 and 5/6/2010.) My memory span is not what it used to be and I did not recognize his name.

These mailing lists get a lot of newbies who are smart and ask lots of questions.
Many times the questions arise from some simple misunderstanding of something that is obvious to an old timer. I am sorry, if the term novice offended anyone.

--

---

From: Martin Rex <[email-masked]>
Date: Mon, 10 May 2010 20:38:30 +0200 (MEST)

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

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.

> 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

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 10 May 2010 13:48:29 -0500

> can be more easily obtained in an app-specific fashion.

+1

---

From: "Srinivas Cheruku" <[email-masked]>
Date: Tue, 11 May 2010 09:58:34 +0530

Thank you. I agree with you.

>  Sent: Tuesday, May 11, 2010 12:09 AM
>  To: Srinivas Cheruku
>  Cc: [email-masked]; [email-masked]; [email-masked]