This message constitutes notice of a Last Call for comments on
XEP-0484.
1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?
Yes
2. Does the specification solve the problem stated in the introduction
and requirements?
Yes
3. Do you plan to implement this specification in your code? If not,
why not?
N/A (currently, at least).
4. Do you have any security concerns related to this specification?
No
5. Is the specification accurate and clearly written?
Yes
BUT... I think we may have a problem with the replay protection included in this layer.
Many many apologies for not having reviewed this until now. Or, you know, if I knew about this before, I'd forgotten it, which I'm also sorry for if this is the case.
When I designed CLIENTKEY -
draft-cridland-kitten-clientkey-00 - Client Key SASL mechanism - it was designed such that it, too, had replay protection built-in to the SASL mechanism. When discussing this with various people at the IETF, it was suggested that having a write for each authentication would be extremely expensive in some environments, preventing the usage (LDAP was given as an example here). Similarly, for clustered implementations this required a coordinated write (and possibly a lock); otherwise it might be possible to replay a session almost-concurrently and quickly enough to hit another cluster node successfully. Anyway, a lot of push-back, which is why I decided not to actively progress CLIENTKEY.
There's an additional concern at the back of my mind, which is that this all represents a bit of a layer violation, which might be important or might not be.
So...
One option here is to (as I did with CLIENTKEY) move the replay concern into the SASL mechanism. I don't think this is a bad option; clients should be expected to know the security properties of the SASL mechanisms they use, and to know whether it's safe to use within TLS early data. But it does mean servers cannot enforce (or at least, servers cannot easily enforce) that an unsuitable mechanism hasn't been used in early data and thus at risk of replay.
Another is to require it anyway at the FAST layer rather than the SASL mechanism layer. This has advantages, but does mean that if the IETF ever did take up CLIENTKEY or similar mechanisms with built-in replay protection - I mean, other than DIGEST-MD5 - we're doing everything twice. And it also means that the IETF might end up standardizing the other model.
Anyway, this is all very late - but I think we need consensus on an approach prior to moving this along the track.
Dave.