[Standards] Instant Stream Resumption 0.0.5 ProtoXEP
georg at op-co.de
Wed Dec 20 15:19:25 UTC 2017
* Florian Schmaus <flo at geekplace.eu> [2017-11-30 21:13]:
> I've just submitted version 0.0.5 of the Instant Stream Resumption (ISR)
> ProtoXEP .
§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) .
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
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
| 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'
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.
|| 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 ||_________________________________________________||
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the Standards