[Standards] comments on section 8.3, draft-saintandre-rfc3920bis-06.html

Ovidiu Craciun Ovidiu.Craciun at philips.com
Tue Jul 22 01:12:04 UTC 2008


Excerpt from: http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-06.html

"Section: 8.3.  Generation of Resource Identifiers
A resource identifier can be security-critical. For example, if a malicious entity can guess a client's resource identifier then it may be able to determine if the client (and therefore the controlling principal) is online or offline, thus resulting in a presence leak as described under Section 15.13 (Presence Leaks). Traditionally, XMPP resource identifiers have been generated by clients in ways that are not secure (e.g., hardcoding the resource identifier to the name of the client or to a common location such as "home" or "work"). However, for the sake of proper security, a resource identifier SHOULD be random (see [RANDOM] (Eastlake, D., Schiller, J., and S. Crocker, “Randomness Requirements for Security,” June 2005.)). It is RECOMMENDED that the resource identifier incorporate a Universally Unique Identifier (UUID), for which the format specified in [UUID] (Leach, P., Mealling, M., and R. Salz, “A Universally Unique IDentifier (UUID) URN Namespace,” July 2005.) is RECOMMENDED. "

From the IMPP RFC I get that:
	X can read Y's presence info only
		(A) if Y's presence info is public domain, or 
		(B) if Y previously allowed X to read it's presence.

In this case, when a malicious entity, that can guess X's resource identifier, is be able to read X's presence only if (A) or (B) is true, in which case it is not a security threat, it is by default. What I am saying is that the presence leaks are not related with the easiness of guessing X's resource IDs but if the server is handling correctly the presence information for a given JID.

Also, the requirement to have a resource identifier be random "for the sake of proper security" it is also a forced and unnecessary requirement. The server should guarantee the security by implementing correctly a secure protocol not by following recommendations.

It is very possible to have missed some angles here, I am pretty new in this world, please correct me if I am wrong.
Ovidiu


More information about the Standards mailing list