[Standards] Security implications of entity capabilities

Peter Saint-Andre 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.


Peter Saint-Andre
XMPP Standards Foundation

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070321/0cf49534/attachment.bin>

More information about the Standards mailing list