Subject: Re: [kitten] -02 of GSS_C_CHANNEL_BOUND_FLAG I-D submitted

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 5 May 2013 16:24:19 -0400 (EDT)

On Fri, 22 Feb 2013, Nico Williams wrote:

> Version -02, using the "empty sec context constructor" design has been
> submitted.
>
> http://www.ietf.org/id/draft-williams-kitten-channel-bound-flag-02.txt
> http://tools.ietf.org/html/draft-williams-kitten-channel-bound-flag-02
> http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-williams-kitten-channel-bound-flag-02.txt
>
> (Hmm, I just realized that we should say what happens when
> GSS_Delete_sec_context() is called on an empty sec context handle,
> namely that no deletion context token is to be generated.)

(Yes, you should.)

It looks like I never commented on the channel bound flag on-list.
The concept of the -02 draft, with empty security context handles, does 
seem more appealing than the -00's flags on credential handles.

In 2.1, a NULL context is usually spelled GSS_C_NO_CONTEXT, and it might 
be good to explicitly call out that this document is changing the expected 
behavior of GSS_{Init,Accept}_sec_context() (as opposed to doing so in 
passing).

In 2.2.1, I assume that the use of 64-bit types for the flags arguments 
(as opposed to the 32-bit types in the C bindings for 
gss_init_sec_context()) is an intentional attempt to increase the number 
of flags available?

In section 3, the fourth bullet point (applications using the 
channel_bound flag) does not specify the behavior when both peers provide 
bindings but the bindings differ.  This case is covered by the first 
bullet point, but a reminder might help the reader.

-Ben