[Standards] NEW: XEP-0440 (SASL Channel-Binding Type Capability)

Ruslan N. Marchenko me at ruff.mobi
Thu Jul 2 16:57:03 UTC 2020


Am Donnerstag, den 02.07.2020, 17:37 +0200 schrieb Florian Schmaus:
> On 7/2/20 1:26 PM, Ruslan N. Marchenko wrote:
> > Am Donnerstag, den 02.07.2020, 11:23 +0200 schrieb Florian Schmaus:
> > > I am not sure if this is a downgrade attack (at least a full-
> > > blown),
> > > or,
> > > if it is, if it. Without xep440 the client would have send 'p' in
> > > the
> > > case you described, with a channel-binding type not supported by
> > > the
> > > server and hence SASL authentication would fail.
> > > 
> > yes if server does not support tls unique - yes (which is mandatory
> > to
> > support), fat chance. Known issue.
> 
> Some implementations only support tls-server-end-point and not
> tls-unique, even though the latter is mandatory to implement. But in
> reality, it is often impossible to get the data required for tls-
> unique
> from the TLS stack, or at least it is far easier to get the data for
> tls-server-end-point.
> 
> 
Yes, I have also faced with that and was looking forward for this XEP
to do exactly that, but then I reconsidered and better submitted
upstream patches to include bindings retrieval api.


> 
> I think this is ultimately an issue on the SASL layer, and not
> necessarily in xep440. Clients are free to ignore the xep440
> information.
> 
The issue is rather with channel bidning selection and definition, 5056
defined one approach, then 5929 redefined another, in the end the whole
binding thing became futile. Hopefully Sam's proposal will be properly
reviewed and accepted to enforce new clealry defined defaults (101st
standard :) ).

> A pragmatic middle-ground, which mitigates the impact of the
> downgrade
> attack vector you described, would be if clients remember and pin the
> announced and used SASL mechanisms and channel-binding types (This
> may
> be a good recommendation for certain setups irregardless of xep440
> anyway.).
> 
> The security section of xep440 should definitely discuss the
> downgrade
> attack vector you described and potentially recommend SASL mechanism
> and
> channel-binding type pinning as mitigation.
> 
Pinning or even better server side signature of the features section
(another hmac) similar to but outside of sasl. Need to think of what
could be selected as reliable but well protected shared secret then.
maybe again PKDF2 derived key from authenticated credentials.

--rr



More information about the Standards mailing list