[Standards] Proposed XMPP Extension: Instant Stream Resumption

Dave Cridland 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
> always
> > 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
> channel
> > 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:

<authenticate mechanism='YAP-SHA256-TLS-UNIQ'
isr:key='a0b9162d-0981-4c7d-9174-1f55aedd1f52'>...</authenticate>

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 [1]: 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
>
> <enabled
>   xmlns='urn:xmpp:sm:3'
>   xmlns:isr='urn:xmpp:isr:0'
>   id='some-long-sm-id'
>   resume='true'
>   isr:key='a0b9162d-0981-4c7d-9174-1f55aedd1f52' />
>
>
> * Client performs ISR with HMAC(isr:key, "Initiator" || cb)
>
> <stream:stream
>  from='juliet at im.example.com'
>  to='im.example.com'
>  version='1.0'
>  xml:lang='en'
>  xmlns='jabber:client'
>  xmlns:stream='http://etherx.jabber.org/streams'>
> <inst-resume
>   xmlns='urn:xmpp:isr:0'
>   previd='some-long-sm-id'
>   h='42'>
>   <hmac>
>     <hash xmlns='urn:xmpp:hashes:1' algo='sha-256'>initiator-hmac</hash>
>   </hmac>
> </inst-resume>
>
>
> * Server acknowledges ISR with HMAC(isr:key, "Responder" || cb)
>
> <stream:stream
>   from='im.example.com'
>   id='t7AMCin9zjMNwQKDnplntZPIDEI='
>   to='juliet at im.example.com'
>   version='1.0'
>   xml:lang='en'
>   xmlns='jabber:client'
>   xmlns:stream='http://etherx.jabber.org/streams'>
> <stream:features>
>  <isr xmlns='urn:xmpp:isr:0'/>
> </stream:features>
> <inst-resumed
>   xmlns='urn:xmpp:isr:0'
>   key='006b1a29-c549-41c7-a12c-2a931822f8c0'
>   h='21'>
>   <hmac>
>     <hash xmlns='urn:xmpp:hashes:1' algo='sha-256'>responder-hmac</hash>
>   </hmac>
> </inst-resumed
>
>
> where
>   initiator-hmac = Base64(HMAC(key, "Initiator" ||
> cb-tls-server-end-point))
>   responder-hmac = Base64(HMAC(key, "Responder" ||
> cb-tls-server-end-point))
>
>
> 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...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160301/7221d899/attachment-0001.html>


More information about the Standards mailing list