8 May
2024
8 May
'24
8:29 a.m.
On Wed, 2024-05-08 at 10:19 -0400, Sam Whited wrote:
I'd like to see the security considerations
expanded on this.
In particular, in the business rules it mentions the fact that if
occupant-id isn't supported it could be spoofed. This should exist in
the security considerations.
Fair.
Also, I suspect the naive way to implement this will
be to hash the
bare
JID. We probably want to mention that this is a bad idea and that
these
identifiers should be random (or we should explicitly define the
security properties that are required if they're derived, which
probably
includes using a salt and ensuring high entropy).
This is not only a bad idea, but is very much non-compliant:
"The occupant identifier MUST be generated such that it is anonymous.
This means that it MUST be sufficiently hard to determine the real bare
JID of an occupant from its occupant identifier. Additionally, a MUC
service SHOULD generate the identifier such that the occupant
identifier of a user in one room of the service does not match the
occupant identifier of the same user in another room of the same
service."
Nonetheless could be made even more specific that this is not allowed
(aka MUST NOT just hash using widely known, static parameters).
However, I think this does not belong into Security Considerations, as
not complying is not just "bad for security", but actually defeats the
whole purpose of the XEP.
Marvin