Subject: Re: What am I waiting on for gs2?

From: Alexey Melnikov <[email-masked]>
Date: Sun, 27 Jan 2008 18:15:22 +0000

Simon Josefsson wrote:

>Sam Hartman <[email-masked]> writes:
>  
>
>>However if the WG doesn't have consensus behind this change then it
>>should be backed out.
>>
>I support the change below.  Others?
>  
>
I support it as well.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 28 Jan 2008 17:32:00 -0500

> I support the change below.  Others?

I support the addition of a security layer bit to indicate channel binding 
negotiation failed, as described in the change in question.

However, the diff you provided also makes a second change, whose effect is 
to number bits with bit '0' being the least-significant bit rather than the 
most-significant bit, as is the convention used in the RFC Series.  Please 
see ID-Checklist section 2.1 item 9, and draft-rfc-editor-rfc2223bis-08.txt 
section 3.4.

-- Jeff

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 28 Jan 2008 17:29:22 -0600

I support this change as well, modulo the what-do-we-do-about-Sam's-
comment thread.

We may still decide to make more changes to gs2.

What would gs2 with an option to support channel-binding-but-no-sec-
layers mechanisms?

I think the packet format would change from this:

                           1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             length                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               /
      /                      GSS_Init_sec_context or                  /
      /                   GSS_Accept_sec_context token,               /
      /                     of given length                           /
      /                                           --------------------/
      /                     ---------------------/                    /
      /--------------------/                                          /
      /                              Optional GSS_Wrap token          /
      /                                                               /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

to this for the initial one (and, if we want to simplify the spec, for
all of them):

                           1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             length                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |<gss-channel-binding-in-use>[<authzid>]                        |
      /                                           --------------------/
      /                     ---------------------/                    /
      /--------------------/                                          /
      |                                                               /
      /                      GSS_Init_sec_context or                  /
      /                   GSS_Accept_sec_context token,               /
      /                     of given length                           /
      /                                           --------------------/
      /                     ---------------------/                    /
      /--------------------/                                          /
      /                              Optional GSS_Wrap token          /
      /                                                               /
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where, if gss-channel-binding-in-use == TRUE then <authzid> is present
and the optional GSS_Wrap token is absent on this and all subsequent
context token exchange packets.  If gss-channel-binding-in-use == FALSE
then everything is just as it used to be.

If gss-channel-binding-in-use == TRUE then the client and the server
MUST both construct the GSS-API channel bindings from the actual channel
bindings passed in by the application and the authzid as well.  Channel
binding failure is critical in the GSS-API, so if channel binding fails
then SASL authentication fails.

gss-channel-binding-in-use can be a single octet, and authzid can be
NUL-terminated UTF-8.  The packet marshalling and unmarshalling is easy
then.  And the channel bindings can be the NUL-terminated authzid in
UTF-8 with the actual channel bindings appended.

Nico
--