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
