Nicolas Williams <Nicolas.Williams <at> Sun.COM> writes:

> On Mon, Jan 30, 2006 at 09:11:05AM -0500, Jeffrey Hutzelman wrote:
>> On Monday, January 30, 2006 01:50:28 PM +0100 Simon Josefsson 
>> <jas <at> extundo.com> wrote:
>> >
>> >>It may be that the best thing to do for SASL/GS2 channel bindings is
>> >>that the first wrap token should include the channel bindings, if any,
>> >>and security layers preferences for the cases that the binding succeeds
>> >>and for when it fails, and the second wrap token should indicate binding
>> >>success/failure and cause security layer selection accordingly.
>> >
>> >I believe I understand the point, but I'm not sure how to implement
>> >this.  How do the server and client gracefully find out whether
>> >channel binding negotiation succeeded?
>> 
>> You don't.  What Nico is proposing is that you ignore the GSSAPI channel 
>> binding mechanism, and handle it yourself by including the channel 
>> identifying information among the data sent in the first GSS_wrap() token.
>
> Exactly.  The client send its channel bindings data and security layers
> preferences [for channel bindings OK, channel bindings not OK] and the
> server validates the channel bindings and selects a security layer as
> per the client's preferences and channel binding status (success/failure).

Thanks for the ideas.  I've made good progress on this at
<http://josefsson.org/sasl-gs2/>.

However, the above approach effectively creates a new concept: "SASL
GS2 channel bindings" which is distinct from the "GSS-API channel
bindings" mechanism.  How these should best interact isn't clear to
me.

For example, should GSS-API channel bindings be permitted at all in
GS2?  I.e., where the application suggest some channel bindings, which
the SASL mechanism pass on to GSS_Init_sec_context and
GSS_Accept_sec_context?  Should they be included in the SASL GS2
channel binding field or not?  Should they influence whether the qop
for cb or non-cb is used?

It also appear to the following problem: It isn't enough to
standardize channel bindings for GSS-API over TLS, as they wouldn't
apply to GS2 channel bindings.  Perhaps the GS2 document should
specify the channel binding to use when GS2 is used over TLS
specifically, and leave further channel bindings (IPSEC) for future
updates?

>     <sec layer selection - 1 octet>
>     <max output_size -- 4 octets>
>     <sasl mech list length -- 4 octets>
>     [<sasl mech list string>]
>     [... -- extensibility :)]
>
> The sasl mech list is a trivial item to throw in that optimizes
> negotiation protection as recommended in rfc2222bis (get the list before
> and after and compare) without overly complicating the implementation;
> clients wouldn't have to do anything with it other than make it
> available to applications.

I don't think this is a good idea.  There are no APIs for passing this
information to the application today.  Having an API that is specific
for this mechanism seem like a poor idea.  If we are proposing that
all mechanisms MAY support a similar scheme, I believe we should
revise the core document to say that instead of adding it to this
mechanism.

If we expect GS2 to be used over TLS, with channel bindings, there's
also no need for this optimization.

> Pick a byte order for the length fields.

Network byte order seem appropriate.

Thanks!