Re: New GS2: pulling everything together

[Simon Josefsson <simon@xxxxxxxxxxxxx>]

Nicolas Williams <Nicolas.Williams@xxxxxxx> writes:

> We've had a lot of comments on the new GS2 design.  Time to pull
> everything together again.

Good summary!

I have one question/observation about GS2 for non-SCRAM mechanisms and
header compression:

>     - The RFC2743 section 3.1 initial context token header compression
>       flag would not be needed for a pure SASL SCRAM.  But it's only a
>       constant for SCRAM, therefore it's not a problem.  I believe we
>       have consensus on this.

If a server advertise a GS2 SASL mech, that doesn't have a "simple"
name, GS2 clients (that use a GSS-API library) will need to iterate over
all the GSS-API mechanisms supported by the GSS-API library, and compute
the generated SASL mech name and compare that with the server mech list
before it knows whether it supports an offered mechanism or not.  Is my
understanding right?  It seems somewhat sub-optimal, but I don't see how
we can avoid it.

To avoid this, it seems another GSS-API function such as
GSS_Inquire_mech_for_SASLname that return a mech OID for a given SASL
name, is needed.  Thoughts on whether this is worthwhile?

>  - With regards to the two mechname + gs2-cb-flag approach to negotiable
>    channel binding:
...
>     - Kurt prefers this approach to doing the negotiation in the mech

I prefer it as well.  Sub-negotiation adds complexity.

>     - Jeff and I believe this approach is simple enough.  We can't make
>       CB negotiation in GS2 any simpler.  I believe Sam and Simon agree.

As far as I understand so far, I agree fully.

Thanks,
/Simon