5 Feb
2025
5 Feb
'25
7:28 a.m.
On Mon, 13 Jan 2025 at 11:52, Daniel Gultsch <daniel(a)gultsch.de> wrote:
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
<https://datatracker.ietf.org/doc/draft-cridland-kitten-clientkey/> - 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.