* Florian Schmaus <[email protected]> [2017-11-30 21:13]: > I've just submitted version 0.0.5 of the Instant Stream Resumption (ISR) > ProtoXEP [1].
§5.2 Performing Instant Stream Resumption | The initiating entity must also provide a <inst-resume/> element | qualified by the 'https://xmpp.org/extensions/isr/0' namespace, which | must contain a <resume/> element as defined in Stream Management | (XEP-0198) [1]. It feels wrong to me to embed the 0198 <resume/>, which is a top-level stream element, into the <inst-resume/> element - especially as we do just the oppoosite to start ISR - embed the <isr-enable/> element into 0198. From a protocol design perspective, I'd rather add an explicit security-token to the 0198 handshake and allow resumption right after the TLS handshake, instead of after authentication. Only if resumption with that security-token fails, I would fall back to normal SASL. Regarding the "is this an authentication process or not" debate, I would say that this is rather the continuation of a previously existing session that broke due to issues below the TCP/TLS session. Having a short-lived(*) token that expires together with the 0198 session and needs to be kept secret by both parties doesn't seem to violate the typical security requirements from my perspective. If we couple that with 0198, there is no way to duplicate a client session (the old session gets killed on resumption, so that token abuse becomes apparent immediately), however it is possible for the client to switch networks. (*) Of course it is communicated at the beginning of the session, so both parties need to keep it as long as the session exists, which is typically days to weeks. On the other hand, it would be automatically invalidated whenever the session gets kicked, e.g. when the user does a password change. | Server implementations MUST implement the ISR token comparision in | linear runtime. I'm pretty sure you are looking for "constant runtime", though technically of course the runtime depends on the length of the token (just hopefully not on its content). §5.2.1 Successful Stream Resumption | After the <inst-resumed/> was received and has been verified both | entities MUST consider the resumed stream to be re-established. This | includes all previously negotiated stream features like Stream | Compression (XEP-0138) [...] I understand that you try everything to reduce RTTs, but I imagine this (especially compression) might be rather hard to pull off. | This element MUST contain a new ISR Token found in the 'token' | attribute. I'm not sure if there is any security benefit in rotating the token on each reconnection, as opposed to keeping the same token value for the lifetime of the session. §5.2.2 Successful Authentication but failed Stream Resumption | Since the initiating entity is authenticated, it could continue with | resource binding It is a very bad idea to allow that. If the 0198 session has expired for whatever reasons, we should fall back to unauthenticated state and require a full authentication from the client. If we don't, ISR allows an attacker to use an ISR token to create an additional authenticated session to the server by passing an invalid resume-id, and have that new session coexist with the user's original session. This only reinforces my feeling that strongly coupling the ISR token into 0198 would be a better overall design. Georg -- || http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++ || gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ || || Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y? || ++ IRCnet OFTC OPN ||_________________________________________________||
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
