[Standards] Proposed XMPP Extension: Channel Binding Pseudomechanisms

Florian Schmaus flo at geekplace.eu
Sun May 10 14:34:12 UTC 2020


On 5/10/20 3:42 PM, Sam Whited wrote:
> On Sun, May 10, 2020, at 08:53, Dave Cridland wrote:
>> I'd be fine with putting channel bindings alongside mechanisms, just
>> not pretending they are mechanisms.
> 
> I still don't see why it bothers anyone. We already do this with "-
> PLUS", so what is wrong with adding another suffix?

"Look, they did the same bad thing here, then it must be OK if I do the
same", is no argument.


> So far it's just "I
> don't like it" and "I'm not fine with it". I can't really do much to fix
> it if I don't know why.

It (1) unnecessarily bloats the SASL mechanism space with (2)
unregistered mechanisms while (3) additionally adding a lot of redundant
information.

1: It is a small combinatorial explosion if we list the cross product of
SASL mechanism and channel binding type in <mechanisms/>, for no reason
(see below).
2: All those mechanisms do not, and very likely will never, appear in
the IANA SASL mechanism registry.
3: Since you can assume that if a server (or implementation in general)
supports a channel binding type, it is supported for all SASL
mechanisms. Your suggestion repeats that same information, the supported
channel binding types, multiple times.

Now, I know you argue that there may be in the future channel binding
types that are specific to a SASL mechanism. Please read below why we
could still go with a way simpler and terse syntax.


>> It *is* possible that a server might not support all channel bindings
>> equally, but I think that server would be broken.
> 
> What I was trying to say is that I don't think the server can always
> support all channel bindings equally, no matter how much we want it to,
> not just that it might not want to.
> 
> For example, in my tls-exporter I-D [1] I am currently mixing in part of
> the SCRAM messages which makes it SCRAM specific. This *cannot* work
> with other non-SCRAM mechanisms that support channel binding (such as a
> future OAuth mechanism).

Even if there is a channel binding type that is specific to a SASL
mechanism, then the server announcing

<stream:features>
  <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
    <mechanism>EXTERNAL</mechanism>
    <mechanism>SCRAM-SHA-1-PLUS</mechanism>
    <mechanism>PLAIN</mechanism>
    <sasl-channel-binding xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
      <channel-binding type='tls-server-end-point'/>
      <channel-binding type='tls-exporter'/>
    </sasl-channel-binding>
  </mechanisms>
</stream:features>

would be sufficient for the client to now what do to. Even if
'tls-exporter' is SCRAM specific, because its specification then surely
would declare the supported SASL mechanisms.


> Now, since writing that I've decided that the value that we want to mix
> in probably doesn't need to include anything SCRAM specific. However, I
> don't see anything stopping other future channel bindings from mixing
> in data from a specific auth mechanism (eg. to prevent substitution
> attacks when credentials are valid for more than one identity). If we
> forbid servers from advertising different channel binding types for
> different mechanisms, we would not be able to support future mechanisms
> that work this way.

I don't see why anyone would ever want design a SASL mechanism specific
channel binding type. I am happy to learn about potential reasons, of
course. But even if such a channel binding type existed, then the
<sasl-channel-binding/> extension of the <mechanism/> stream feature
shown above would enable clients to deal with it.

- Florian


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 618 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20200510/f53dffc0/attachment.sig>


More information about the Standards mailing list