[Standards] Proposed XMPP Extension: Instant Stream Resumption
dave at cridland.net
Tue Mar 1 08:26:36 UTC 2016
On 19 February 2016 at 20:12, Florian Schmaus <flo at geekplace.eu> wrote:
> On 18.02.2016 09:45, Thijs Alkemade wrote:
> > Of course, there are situations where a certificate legitimately
> changes, but
> > quick resumption failing once every 3 months and having to fall back to a
> > normal XEP-0198 resume sounds fine to me. I'd assume the possibility of
> > specifying the IP address + port on which to resume makes it easy to
> > redirect the client to the same server in the cluster.
> Exactly my thought: It's not really an issue if once every few months
> ISR would fail because of a changed cert.
> > The YAP draft Dave linked looks interesting, though it only offers
> > binding and not mutual authentication, but I think that can be easily
> fixed by
> > something like:
I wonder - and I've not thought through the implications of this - whether
instead of trying to build a SASL-equivalent authentication into '198, with
all that entails, is it worth approaching this from the other direction?
I mean instead of something like this:
> > S: <enabled
> > xmlns='urn:xmpp:sm:3'
> > xmlns:isr='urn:xmpp:isr:0'
> > isr:id='6956e8e5-b123-4a1a-9d23-939199568c4f'
> > isr:key='a0b9162d-0981-4c7d-9174-1f55aedd1f52'/>
Something more like:
I would think this design would address Tobias's current veto:
[16:11:09] Tobias: but yeah..i'm -1, will post on list, and as it aims to
replace the whole SASL step for a reconnection it's currently pretty light
on the discussion on how it obtains the same level of security
> > Resumption uses SASL with:
> > C: id || HMAC(key, "Client" || ChannelBinding)
> > S: HMAC(key, "Server" || ChannelBinding)
> > Where the id is only necessary so the server can find the key
> efficiently (it
> > could be made stateless by making the id an encrypted token containing
> key, or
> > by deriving key from id using HMAC).
> I'd like to take on this approach and modify it a bit:
> - Instead of xsr:id we simply use the stream ID that's in <enabled/> if
> resume=true. I'd assume that ISR supporting servers will always also
> support (ver likely) xep198 stream resumption.
> - I'd like to fix ChannelBinding to tls-server-end-point. Mostly because
> the situation hasn't much improved since Tobias asked in 2011 : You
> can't implement tls-unique in Java SE or Android without resorting to a
> custom TLS stack.
> - Don't use SASL for ISR. The XMPP session state after SASL <success/>
> is a fundamentally different one then after <inst-resumed/>.
> So basically we have now:
> * Client receives <enabled/> with ISR key
> isr:key='a0b9162d-0981-4c7d-9174-1f55aedd1f52' />
> * Client performs ISR with HMAC(isr:key, "Initiator" || cb)
> from='juliet at im.example.com'
> <hash xmlns='urn:xmpp:hashes:1' algo='sha-256'>initiator-hmac</hash>
> * Server acknowledges ISR with HMAC(isr:key, "Responder" || cb)
> to='juliet at im.example.com'
> <isr xmlns='urn:xmpp:isr:0'/>
> <hash xmlns='urn:xmpp:hashes:1' algo='sha-256'>responder-hmac</hash>
> initiator-hmac = Base64(HMAC(key, "Initiator" ||
> responder-hmac = Base64(HMAC(key, "Responder" ||
> I'm not even sure if we need verify the server cert with the one at the
> time of <enabled/>. I don't see a point, since the server is
> authenticated by responder-hmac.
> Or am I missing something? If not, then I'm going to change the ISR
> ProtoXEP to this.
> - Florian
> 1: https://www.ietf.org/mail-archive/web/kitten/current/msg02767.html
> Standards mailing list
> Info: http://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards