On 19 February 2016 at 20:12, Florian Schmaus <f...@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='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 > > > _______________________________________________ > Standards mailing list > Info: http://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _______________________________________________ > >
_______________________________________________ Standards mailing list Info: http://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
