[Standards] Proposed XMPP Extension: Channel Binding Pseudomechanisms

Florian Schmaus flo at geekplace.eu
Thu May 7 16:21:22 UTC 2020


On 5/6/20 7:05 PM, Sam Whited wrote:
> I thought about something like this but it wasn't clear to me what
> negotiating channel binding would even mean.

That the remote entity, the server in c2s, supports those particular
channel binding types.


> It also means that we have
> more state to keep around for when auth is negotiated, and more behavior
> and edge cases to figure out. If we negotiate channel binding, does the
> server *only* list SCRAM-PLUS mechanisms (ie does negotiating channel
> binding imply intent to use it)?

That depends on the server's intention. Fundamentally, the server
listing the supported channel bindings in the stream features just tells
the client which channel binding types the server supports. If the
server wants to enforce channel binding, then only SASL mechanisms with
channel binding could be listed. But there are also mechanisms where
channel binding is not required, like EXTERNAL. So servers could do

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

(Note that I have refined my initial example here)


> What if we negotiate channel binding,
> then the server only lists SCRAM-SHA-1-PLUS but we only support SCRAM-SHA-256-
> PLUS? Do we fail when we would have otherwise been able to fall back to
> PLAIN (which would have been listed if not for the fact that we
> negotiated channel binding up front)?

If the server really wants to support PLAIN, then it would be announce
from the very start, i.e.,

<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-unique'/>
    </sasl-channel-binding>
  </mechanisms>
</stream:features>

The client has always an incentive to select to "most secure"
authentication mechanism. Hence sensible clients would use one with
channel binding, and only use fallbacks like PLAIN (if they have not
blacklisted that mechanism) otherwise.


> If the server continues to list
> all mechanisms, we just wasted round trips negotiating channel binding
> even though we'll never use it.

I am not sure which round trips you see here that are wasted.


> Furthermore, what if in the future we have multiple mechanisms that
> support channel binding (maybe we support issuing oauth tokens that use
> channel binding) but support different types (eg. oauth might use the
> token pinning spec that was in draft at the IETF recently… it was
> abandoned IIRC, but it's just an example). How do we convey that and
> make sure your channel binding feature is extensible?

As other said, I too find not necessary to plan for the world where a
channel binding type exists that can only be used with a particular SASL
mechanism. Channel binding types are usually available for all channel
binding supporting SASL mechanisms. If an implementation is able to
support a particular channel binding type depends on its TLS library
providing an API to ge the secret sauce (bytes).

And if you do not want a given channel binding type, then you do not
want it for all SASL mechanisms.

Furthermore, if we really have the case that a particular channel
binding type is exclusive to a certain SASL mechanism, then simply list
this channel binding type among the others in <sasl-channel-binding/>.


> Having the list of mechanisms continue the trend of adding a suffix like
> "-PLUS" Means we can have all the context and state in one place, and
> pick a mechanism that works for us while remaining fully backwards and
> forwards compatible with what we have today.

I am not sure if I buy the "have all the context and state in one place"
argument. I could also argue you have all the context and state in one
place: the stream features.

- Florian

> On Wed, May 6, 2020, at 12:50, Florian Schmaus wrote:
>> I am surprised about the design. Why inflate the SASL mechanism
>> namespace? Wouldn't something like
>>
>> <stream:features> <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-
>> sasl'> <mechanism>EXTERNAL</mechanism> <mechanism>SCRAM-SHA-1-
>> PLUS</mechanism> <mechanism>SCRAM-SHA-1</mechanism>
>> <mechanism>PLAIN</mechanism> </mechanisms> <sasl-channel-binding xmlns='urn:ietf:params:xml:ns:xmpp-
>> sasl' required='false'
>>  >
>>  <channel-binding>tls-unique</channel-binding> </sasl-channel-binding>
>>  </stream:features>
>>
>> Be way simpler and better?
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
> 

-------------- 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/20200507/a4dfc25d/attachment-0001.sig>


More information about the Standards mailing list