[Standards] Proposed XMPP Extension: Instant Stream Resumption

Florian Schmaus flo at geekplace.eu
Fri Feb 19 20:12:03 UTC 2016


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:
> 
> 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'/>
> 
> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20160219/5b4b98e8/attachment.sig>


More information about the Standards mailing list