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

Mridul Muralidharan mridul at sun.com
Sat May 19 11:05:17 UTC 2007

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

As Ian mentioned, this is a potential problem for long (I think we 
discussed it in passing in interop 2006 as part of invisibility) ...
I am not sure how we will handle it : one possibility is as suggested - 
client sending back something to server "send this error on my behalf" 
instead of directly responding back to sender.
Even in this case, we will be missing corner cases which could be exploited.

Though, sending different error codes makes it a bit easy for sender to 
discover presence.

> 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).

Yes, random resources is a very good way to tackle the problem !
User's should preferably not be using resources to convey meaning 
(/work, /home anyone ? :) ) but this is the common practice nowadays.


> Peter

More information about the Standards mailing list