Re: Letting the client choose the protocol to use during a SASL exchange

On 04/13/2017 02:35 PM, Álvaro Hernández Tortosa wrote:
> On 13/04/17 13:24, Heikki Linnakangas wrote:
>> Right, when we get channel binding, the server will list
>> "SCRAM-SHA-256" and "SCRAM-SHA-256-PLUS" as the list of mechanisms.
>> And if we get channel binding using something else than tls-unique,
>> then those will be added as extra mechanisms, too, e.g.
>> "SCRAM-SHA-256-PLUS tls-awesome".
>
>      And how about supporting different SCRAM mechanisms with different
> possible channel bindings? Separate by space too? So given a field, is
> the first item the SCRAM mechanism, and all the remaning the channel
> binding methods? I.e.:
>
> SCRAM-SHA-256-PLUS tls-awesome tls-awesome2 tls-awesome3\0...

I think we're going in circles.. Yeah, we could do that. Or they could 
be listed as separate mechanisms:

SCRAM-SHA-256-PLUS\0
SCRAM-SHA-256-PLUS tls-awesome\0
SCRAM-SHA-256-PLUS tls-awesome2\0
SCRAM-SHA-256-PLUS tls-awesome3\0
\0

One alternative is that you could list extra channel bindings that are 
supported by all the mechanisms, as separate entries. So the list could be:

binding tls-unique\0
binding tls-awesome\0
binding tls-awesome2\0
binding tls-awesome3\0
SCRAM-SHA-256-PLUS\0
SCRAM-SHA-512-PLUS\0
\0

which would mean that those bindings are supported by all the mechanisms 
that follow. I think this would achieve the same thing as your proposed 
separate field, with the current proposed protocol.

But again, I'm 99% sure we won't need it, and we don't need to decide 
the exact syntax for channel bindings yet. We have the flexibility now, 
so we can cross the bridge when we get there.

- Heikki