[jdev] Figuring out what a client thinks its JID is

[Peter Saint-Andre]

On 4/5/10 4:01 PM, Aaron Kryptokos wrote:
> Nathan Fritz wrote:
>> By not using the same node as the authentication user, you're going
>> against two SHOULD suggestions in the RFC
> 
> I can't find anything in RFC 3920 about this case.  Can you help me find
> these two recommendations?
> 
>> I would recommend against doing this on a public
>> service where you expect any IM client.
> 
> The authentication and authorization system already exists, so my hands
> are mostly tied.  I'm open to any reasonable implementation that will
> make this work.  The one design restriction imposed on me is that the
> authenticating client must some sort of way provide the authentication
> username as part of the process; mapping from the node to auth
> credentials is not acceptable.

Hi Aaron, I took another look at your original message in this thread:

https://www.jabber.org/jdev/2010-March/088174.html

and:

https://www.jabber.org/jdev/2009-November/087885.html

We had some discussions about a related issue recently on the XMPP WG list:

http://www.ietf.org/mail-archive/web/xmpp/current/msg00332.html

The conclusion we came to is that the authentication identity is indeed
not necessarily the same as the localpart of a JID. We mostly glossed
over this issue in RFC 3920, but the replacement RFC will make it clear
that this is a matter for the SASL mechanism or local deployment policy,
not the core XMPP RFC.

> If it's true that the RFC discourages this practice, then I think the
> RFC may need to be revised.  For people who are running simple
> stand-alone Jabber servers, this sort of thing doesn't matter.  But for
> organizations like mine that are trying to embrace XMPP by adding an
> XMPP interface to existing infrastructure, this is a major issue.  GTalk
> has a variation of the same problem, except with domain instead of
> username.  I think the real long-term solution here is that the RFC
> needs to firmly instruct clients to not make assumptions about their
> JIDs, 

See http://tools.ietf.org/html/draft-ietf-xmpp-3920bis-05 (section 7.2.7).

> and instead accept (or reject) what they are given at resource
> binding.

We could probably strengthen the text about that.

>> You
>> are, again, in violation of the spec by delivering stanzas where the
>> bare jid does not match their bound name, and you could cause
>> unintended consequences on the client (crashes or strange behavior) by
>> simply pinging them in this way.
> 
> I can't find any prohibition like this in RFC 3920 or the draft.  Can
> you point out a specific passage that prohibits this sort of probing?

I don't see any need for this -- the client needs to get its JID from
the server.

>> I really don't see either of these options being viable as the client
>> is simply broken if it doesn't respond to it's bound fulljid and you
>> risk greater consequences if you try to "adjust" at the protocol
>> level.
> 
> My main goal is for a short-term, practical improvement in functionality
> for as many users as possible.

I agree with Fritzy here -- better to file bug reports or provide
patches to the clients you care about. Supposedly short-term fixes have
a way of lasting for a long time, people start to depend on the fix and
it will never disappear.

> As an alternative, I'm thinking about perhaps having the user do
> something special to indicate that 'JID masquerading' should be
> performed, such as placing a special character in their username.

Please not.

> Another option is to try to detect specific versions that are broken
> using XEP-0092: Software Version, and apply the workaround for just
> those.  This would get correct operations to the largest groups of
> users, and prevent breaking people whose clients were in fact operating
> correctly.

Do you have a list of broken clients? Let's figure out what they are and
start the process of reporting bugs and fixing code.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://www.jabber.org/jdev/attachments/20100405/bf997ae9/attachment.bin>