Re: What am I waiting on for gs2?

[Nicolas Williams <Nicolas.Williams@xxxxxxx>]

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