[Standards] Security implications of entity capabilities
stpeter at jabber.org
Wed Mar 21 16:11:00 UTC 2007
Greg Hudson wrote:
> I am a bit concerned by the ability of one malicious client to poison
> the entity capability caches of other people's clients. XEP-115
> considers this possibility:
> It is possible (though unlikely) for a bad actor or rogue
> application to poison other entities by providing incorrect
> information in response to disco#info requests. To guard against
> such poisoning, a requesting entity MAY send disco#info requests to
> multiple entities that match the same node/ver or node/ext
> combination and then compare the results to ensure consistency. The
> requesting entity SHOULD NOT send the same request to more than five
> entities and MUST ensure that the entities are truly different by
> not sending the same request to multiple entities for which the
> <user at host> portion matches.
> I suspect most implementations will simply cache the first response
> they get. If, for instance, e2e encryption is advertised by a
> capability, it will be relatively straightforward to induce two nodes
> to avoid e2e encryption when they would otherwise use it, by
> advertising that a particular node/ver or node/ext combination does
> not support that feature.
> Perhaps the right answer is simply "don't use caps for
> security-sensitive features like e2e encryption." But it can be hard
> to determine in advance what's security-sensitive sometimes.
I see this as an implementation / security note and will try to
formulate some text about it.
XMPP Standards Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards