[Standards] XEP-0175 1.2rc1
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
>> 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
> 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!
> 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