[Standards] [Fwd: [Council] meeting minutes, 2007-05-16]

Peter Saint-Andre stpeter at jabber.org
Fri May 18 22:14:03 UTC 2007

Ian Paterson wrote:
> Peter Saint-Andre wrote:
>> How is this for text in the Security Considerations?
>> ******
>> If a server receives a ping request directed to a full JID 
>> (<node at domain.tld/resource>) associated with a registered account but 
>> there is no connected resource matching the 'to' address, it MUST 
>> reply with a <service-unavailable/> error and set the 'from' address 
>> of the IQ-error to the full JID provided in the 'to' address of the 
>> ping request. If a connected resource receives a ping request but it 
>> does not want to reveal its network availability to the sender for any 
>> reason (e.g., because the sender is not authorized to know the 
>> connected resource's availability), then it too MUST reply with a 
>> <service-unavailable/> error. This consistency between the server 
>> response and the client response helps to prevent presence leaks.
>> ******
> What about white space character data between XML tags etc? To prevent a 
> presence leak the client MUST be able to predict every single byte of 
> its server's normal response. I think you should go so far as including 
> an example of the exact character string that a server MUST send.

What is the attack? That a malicious attacker sends IQs to random full 
resources (juliet at capulet/res1 and juliet at capulet/res2 etc.) in order to 
discover the network availability of a connected resource by comparing 
the output of IQ results returned by the user's server (which we assume 
will be the preponderance of the results) with the result returned by a 
connected resource? Now if the user typically has the same full JID and 
does not randomize its resource identifiers, we could guess at the 
result. So let's say Juliet always connects as <juliet at capulet/balcony>. 
If Romeo sends an IQ to juliet at capulet/923048laksjflasjlsrjlasdkfj (some 
random resource) and gets a reply from the server, now he knows what the 
server's response looks like. Now he sends an IQ to 
juliet at capulet/balcony and gets a different response. Aha, Juliet is 
online at her typical "balcony" resource! Now he can send messages or 
Jingle initiations or malicious files or whatever to that full JID, or 
simply discover her network availability.

To solve that problem you suggest that, at a minimum, we require all 
XMPP software to perform XML canonicalization (c14n).

But which form of c14n? There are three to choose from:

1. http://www.w3.org/TR/xml-c14n

2. http://www.w3.org/TR/xml-exc-c14n/

3. http://uddi.org/pubs/SchemaCentricCanonicalization.htm

However, even c14n might not address your concern because it seems to me 
that you want to ensure proper security layer byte precision for all XML 
sent over XMPP. Thus we would also need to specify something like the 
following in rfc3920bis:

    An entity MUST NOT send any white space characters (matching
    production [3] content of [XML]) within the root stream element
    as separators between stanzas or between elements within stanzas,
    and MUST ensure that attributes are separated by only one white
    space character.

Requiring all that just to prevent a potential presence leak seems like 
overkill to me. Especially because if you're really that paranoid, you 
can't trust your server anyway.

Better, I think, to randomize the resource identifiers. That makes the 
attack a lot harder, and it is something that's under the user's control 
(just use a client that randomizes the resource identifiers).


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/20070518/e2142ef3/attachment.bin>

More information about the Standards mailing list