On Mon, 04 Aug 2008 16:59:50 -0600 Peter Saint-Andre <[EMAIL PROTECTED]> wrote:
> Pedro Melo wrote: > > > > On Jul 22, 2008, at 2:12 AM, Ovidiu Craciun wrote: > > > >> > >> 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. > > > > I believe the above paragraph is not referring to presence leaks as > > a full <presence> stanza but just as a way for me to know if you > > are online or not. It might not be your full <presence> but it is > > still a leak. > > Yes, this is not a leak of <presence/> stanzas, but it is effectively > a leak of information about whether a particular resource is online. > > > If I can guess your resource, I might trick your client into > > replying to an IQ or direct presence stanza. Any of those replies > > would mean that you are online at the moment, and therefore > > constitute a presence leak. > > Correct. > > >> 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. > > > > If you bind your sessions without a resource, the server will give > > you a random resource. For the server to enforce a proper security > > perimeter, it would have to filter (drop) IQ's directed to your JID > > from JIDs outside your roster. This would most likely prevent some > > normal (as in currently available and useful) workflows. > > Well, this is pretty much how Google Talk works, and it mostly > functions just fine. > > > Sometimes I chat with people that are not on my roster, including > > file transfer. That would be impossible with a "server-side" > > firewall. Of course, you can today implement such firewall with > > privacy lists, if your server supports them. > > Right. Or XEP-0191. Effectively Google Talk (and other similar > services) deploy a rule of "forbid communications with people not on > my roster" on the user's behalf -- no need for fancy privacy rules > managed by the user. But this also disallows chatting with people outside your roster, which is something I often do. I'm for any way that doesn't leak presence but allows chat sessions (or single messages)... without giving any presence info. It's nice to be able to decide about the non-roster people blocking separately. Some people would also like to use the "invisible" facility, that would also be orthogonal to the roster subscriptions. (I never used invisible personally.) Sorry if I'm just repeating the obvious. > > Peter > -- Web: http://www.pavlix.net/ Jabber & Mail: pavlix(at)pavlix.net OpenID: pavlix.net
