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='jul...@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='jul...@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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
