[Standards] Proposed XMPP Extension: Channel Binding Pseudomechanisms

Sam Whited sam at samwhited.com
Wed May 6 17:05:25 UTC 2020

I thought about something like this but it wasn't clear to me what
negotiating channel binding would even mean. 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)? 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 continues to list
all mechanisms, we just wasted round trips negotiating channel binding
even though we'll never use it.

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?

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.


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?

More information about the Standards mailing list