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.
The point is - if we send n - it is a downgrade, because what happens
now is:
Me: <stream>
Server: <stream><features><mechanisms>SCRAM-SHA-512-PLUS SCRAM-SHA-
512</mechanisms>
MITM: <stream><features><mechanisms>SCRAM-SHA-512</mechanisms>
Me: <auth mechanism="SCRAM-SHA-512">y,,n=me,r=blah</auth>
Server: <failure><not-authorized></failure>
any modification of the challenge (eg to swap my y with n) is protected
by hmac so will cause failure.
But now:
Server: <stream><features><mechanisms>SCRAM-SHA-512-PLUS SCRAM-SHA-
512<sasl-binding><binding type="tls-unqiue"></sasl-
binding></mechanisms>
MITM: <stream><features><mechanisms>SCRAM-SHA-512-PLUS SCRAM-SHA-
512<sasl-binding><binding type="tls-unqiue-for-telnet"></sasl-
binding></mechanisms>
Me (what?!?!, ok): <auth mechanism="SCRAM-SHA-
512">n,,n=me,r=blah</auth>
Server: <success/>
MITM: <message><body>thanks man, now I'll take it from
here</body></message></stream>
> We could say xep440 modifies the semantic of the 'n' value of the
> gs2-cbind-flag from
>
> "n" -> client doesn't support channel binding.
>
> to
>
> "n" -> client doesn't support any channel binding announced/supported
> by
> the server.
>
>
Like submit a change to IETF or something? Ideally it should be
y=dGxzLXVuaXF1ZS1mb3ItdGVsbmV0LHRscy1zZXJ2ZXItZW5kLXBvaW50Cg
- b64(tls-unique-for-telnet,tls-server-end-point) - eg I hear you but i
don't support that stuff.
> Maybe there are other options, like extending the gs2 header with a
> flag
> that explicitly states that the client believes that there are no
> mutual
> supported channel-binding types by client and server.
>
Yes, all the negotiation should be part of the exchange signed by hmac,
otherwise you can manipulate security context from outside of security
context.
> But right now, I lean towards explicitly stating in xep440 that the
> semantic of 'n' is modified in the way I mentioned above.
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________
