Le mercredi 17 février 2016 19:18:01 CEST, Florian Schmaus a écrit :
requiring the initiator to save the server cert and verify that it
hasn't changed
Be aware that this will probably "soon" be impossible with TLS 1.3 which
allows 0-RTT Handshake (see
https://tlswg.github.io/tls13-spec/#rfc.section.6.2.2): application data
will be sent along with TLS handshake info by the client, which means the
server certificate won't be visible by the client until after the token (or
its transformed version) has already been sent.
Moreover, there are legitimate cases where the server cert can change yet
security hasn't been compromised: a certificate is renewed, the initiator
is redirected to another server of the cluster through the location
attribute.
You are right, exposing the 'tok' in <inst-resume/> without having the
server verified seems like a bad idea.
What are the cases where a MiTM server could decipher 'tok', after the
*mandatory* TLS dance has been done, yet shouldn't have been ? I only see
the case where the MiTM server has gotten hold of the legit server's
private key, in which case:
* the legit server is owned
* the MiTM server doesn't even need to bother with ISR, it can ask
everybody to re-auth through standards ways. It's going to be even more
juicy for him because he'll have access to actual passwords (he can send
PLAIN as the only accepted mechanism, does any client give the possibility
to refuse a PLAIN auth ?)
* (possibly more controversial) it's the domain of TLS anyway, it's not
XMPP's role to add yet another layer of hand-made security
Actually it seems to me that TLS remains the part that does server
"authentication", and the token replaces only the SASL exchange for client
authentication.
Thinking about it, maybe the server could actually send an authenticated
blob as token, so that clients would use it as a challenge for the next
authentication; along with the already existing resumption (198) and
pipelining (305) mechanisms, it would look like that:
Client Server
[TLS hello] --------->
<--------- [TLS response]
[TLS end] --------->
[XMPP <stream>] --------->
[XMPP <resume>] --------->
[XMPP SASL w/ token] --------->
<--------- [XMPP <stream>]
<--------- [XMPP SASL confirmation]
[XMPP data] <-------> [XMPP data]
Or, with future TLS's 0-RTT handshake:
Client Server
[TLS handshake] --------->
[XMPP <stream>] --------->
[XMPP <resume>] --------->
[XMPP SASL w/ token] --------->
<--------- [TLS response]
<--------- [XMPP <stream>]
<--------- [XMPP SASL confirmation]
[XMPP data] <-------> [XMPP data]
ie, 0-RTT handshake XMPP. There's probably a flaw somewhere though.
--
Matthieu Rakotojaona
_______________________________________________
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
