[Standards] XEP-0175 1.2rc1

Brian Cully bcully at gmail.com
Fri Aug 14 01:15:49 UTC 2009

On 13-Aug-2009, at 21:06, Peter Saint-Andre wrote:
> On 8/13/09 6:45 PM, Andy Skelton wrote:
>> XEP-0175 1.2rc1, which states:
>> "After a client authenticates using the SASL ANONYMOUS mechanism, it
>> MUST bind a resource; the server SHOULD ignore the resource  
>> identifier
>> provided by the client (if any) and instead assign a resource
>> identifier that it generates on behalf of the client."
>> Why shouldn't the server bind the resource provided by the client?
> The idea (perhaps questionable) is that many or most XMPP servers  
> assign
> all anonymous users to an account like someUUID at example.com or perhaps
> literally anonymous at example.com. A repeat user could then use the same
> full JID over and over, like someUUID at example.com/anotherUUID, to
> essentially emulate a registered account. Another possible annoyance
> would be to repeatedly use obnoxious resource identifiers (remember,
> these are anonymous, unknown users) for spamming or personal  
> attacks, like:
> someUUID at example.com/This Is The Medicine You Need!
> or
> someUUID at example.com/stpeter-is-an-idiot
> Whether any of these attack vectors are worrisome is another matter.

	I tend not to think so. In the case where a bare JID is reused (e.g.,  
"anonymous at example.com") then it's acceptable to generate a resource  
(thus, the SHOULD should become a MAY in the XEP), and it comes down  
to a particular server implementation and how it generates bare JIDs.  
In the case where the bare JID is truly unique to any given stream  
then there's no reason to generate a resource.

	Mostly resources are hidden from the client, and where available you  
always (or should always) get the bare JID associated. Coupled with  
the existing recommendations in the XEP (+ stringprep) I see no  
avenues for spam/attack than already exist anyway in the protocol.  
Perhaps someone can enlighten me?

	The only potential downside I see is that by using a well-known  
resource you leak information to others which may allow them to attack  
you, but the reverse doesn't seem possible.


More information about the Standards mailing list