Re: [Standards] XEP-0175 1.2rc1
> No! trace data should, at most, just be logged. It's intended to have no > semantic value. By using it to identify a particular anonymous user (across > sessions) you are adding a semantic. I don't have strong feeling for this, but I thought I'd point out the following. This was Andy's use case: "I anticipate looking at a large number of anonymous BOSH connections and wanting to know which blogs they are looking at without having to look up their pubsub subscriptions." That sounds a lot like logging to me. jack.
Re: [Standards] XEP-0175 1.2rc1
On Sep 11, 2009, at 10:29 AM, Jack Moffitt wrote: My use is more of a lazy hack. I want to use the anonymous JID resource to store information about BOSH clients. For example, we could have a number of web pages on different domains connecting via proxy to a single BOSH service and we would like to know at a glance the domain name of the site they are connecting from Wouldn't a better way to do this be the RFC 4505 trace data? You could put shuch data into the element and use it on the backend or whereever to identify users this way. I assume that is the purpose of trace data. No! trace data should, at most, just be logged. It's intended to have no semantic value. By using it to identify a particular anonymous user (across sessions) you are adding a semantic. -- Kurt This however, may not be well supported in servers. Most SASL implementations I know of won't expose the trace information to the calling application program, except possibly as data to be logged. I only thought of it as I saw it mentioned at the end of the recommendation section of the XEP 175 changes. jack.
Re: [Standards] XEP-0175 1.2rc1
> My use is more of a lazy hack. I want to use the anonymous JID > resource to store information about BOSH clients. For example, we > could have a number of web pages on different domains connecting via > proxy to a single BOSH service and we would like to know at a glance > the domain name of the site they are connecting from Wouldn't a better way to do this be the RFC 4505 trace data? You could put shuch data into the element and use it on the backend or whereever to identify users this way. I assume that is the purpose of trace data. This however, may not be well supported in servers. I only thought of it as I saw it mentioned at the end of the recommendation section of the XEP 175 changes. jack.
Re: [Standards] XEP-0175 1.2rc1
> Most of the discussion about XEP-0175 has assumed that servers are > exposed on the public Internet (I know that's how I have looked at it, > from my perspective as an admin of the jabber.org IM service). However, > server admins might offer a more controlled or private service, such as > a for-pay gaming service, a help desk within a corporation, an IM > "helpline" at a school, etc. In these situations, the admins might want > to open up the options a bit more. This is where Jack Moffitt is coming > from with his concerns (Chesspark, Collecta), and perhaps Andy Skelton > (Wordpress) as well. I think it's important to capture both > perspectives, and I don't think we've quite done so yet in the spec. > Perhaps I'll have time to wordsmith it a bit further next week. My use is more of a lazy hack. I want to use the anonymous JID resource to store information about BOSH clients. For example, we could have a number of web pages on different domains connecting via proxy to a single BOSH service and we would like to know at a glance the domain name of the site they are connecting from: 123456...@im.wordpress.com/live.gizmodo.com for example. Our service would not care whether anonymous clients crafted "fraudulent" resources because our server already guarantees a unique bare JID for anonymous clients (ejabberd) and our use of the resource would only be for convenience. We might not even use it this way, but I wouldn't like the spec telling me not to. Andy
Re: [Standards] XEP-0175 1.2rc1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/3/09 2:34 PM, Home wrote: > --- Original message --- >> From: Kevin Smith >> Sent: 3/9/'09, 18:07 >> >> On Wed, Sep 2, 2009 at 9:39 PM, Peter Saint-Andre >> wrote: >>> In my working version of the spec, I now have: >>> >>> On public servers where the same JID is reused for multiple >>> anonymous sessions, the server MAY ignore the resource >>> identifier provided by the client (if any) and instead assign >>> a resource identifier that it generates on behalf of the client. >>> >>> OK? >> >> Seems consistent with what we agreed tonight, thanks :) > > If I might be a PITA for a sec, it'd seem good to capture the discussion > on why it might be useful sometimes, and why you might not want to others. Agreed. Here is my take... Most of the discussion about XEP-0175 has assumed that servers are exposed on the public Internet (I know that's how I have looked at it, from my perspective as an admin of the jabber.org IM service). However, server admins might offer a more controlled or private service, such as a for-pay gaming service, a help desk within a corporation, an IM "helpline" at a school, etc. In these situations, the admins might want to open up the options a bit more. This is where Jack Moffitt is coming from with his concerns (Chesspark, Collecta), and perhaps Andy Skelton (Wordpress) as well. I think it's important to capture both perspectives, and I don't think we've quite done so yet in the spec. Perhaps I'll have time to wordsmith it a bit further next week. > Indeed, it might be better to insist that servers can be configured > either way... I think that's mostly implied by saying that the server MAY do X or Y, but in a neutral way. There are plenty of server implementations that might not want to expose hundreds of configuration options but instead have some kind of "safe mode" or "public mode" that tunes down what an anonymous user can do. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqhMGsACgkQNL8k5A2w/vy1kACgzrunmM1/K4pw3EXwpUXcPGw0 aGwAoM2FG4Dv4CIrQD087TmpBYODzn/+ =9POh -END PGP SIGNATURE-
Re: [Standards] XEP-0175 1.2rc1
--- Original message --- From: Kevin Smith Sent: 3/9/'09, 18:07 On Wed, Sep 2, 2009 at 9:39 PM, Peter Saint-Andre wrote: In my working version of the spec, I now have: On public servers where the same JID is reused for multiple anonymous sessions, the server MAY ignore the resource identifier provided by the client (if any) and instead assign a resource identifier that it generates on behalf of the client. OK? Seems consistent with what we agreed tonight, thanks :) If I might be a PITA for a sec, it'd seem good to capture the discussion on why it might be useful sometimes, and why you might not want to others. Indeed, it might be better to insist that servers can be configured either way...
Re: [Standards] XEP-0175 1.2rc1
On Wed, Sep 2, 2009 at 9:39 PM, Peter Saint-Andre wrote: > In my working version of the spec, I now have: > > On public servers where the same JID is reused for multiple > anonymous sessions, the server MAY ignore the resource > identifier provided by the client (if any) and instead assign > a resource identifier that it generates on behalf of the client. > > OK? Seems consistent with what we agreed tonight, thanks :) /K (sorry, got saved to drafts in the gmail outage, and never sent)
Re: [Standards] XEP-0175 1.2rc1
On Wed, Sep 2, 2009 at 3:39 PM, Peter Saint-Andre wrote: > In my working version of the spec, I now have: > > On public servers where the same JID is reused for multiple > anonymous sessions, the server MAY ignore the resource > identifier provided by the client (if any) and instead assign > a resource identifier that it generates on behalf of the client. > > OK? Works for me. Thanks. Andy
Re: [Standards] XEP-0175 1.2rc1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/13/09 7:43 PM, Andy Skelton wrote: > On Thu, Aug 13, 2009 at 8:15 PM, Brian Cully wrote: >> On 13-Aug-2009, at 21:06, Peter Saint-Andre wrote: >>> 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., >> "anonym...@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. > > I would also like to see SHOULD replaced by MAY in that sentence. > Other than that I like the changes. In my working version of the spec, I now have: On public servers where the same JID is reused for multiple anonymous sessions, the server MAY ignore the resource identifier provided by the client (if any) and instead assign a resource identifier that it generates on behalf of the client. OK? Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqe2AEACgkQNL8k5A2w/vyhEgCfZn/o2z9pK1+Dm4YK791qt9aa PsMAoIKxnUmGrnI0edva/o/tNCszOJCR =Ufzf -END PGP SIGNATURE-
Re: [Standards] XEP-0175 1.2rc1
On Thu, Aug 13, 2009 at 8:15 PM, Brian Cully wrote: > On 13-Aug-2009, at 21:06, Peter Saint-Andre wrote: >> 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., > "anonym...@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. I would also like to see SHOULD replaced by MAY in that sentence. Other than that I like the changes. Andy
Re: [Standards] XEP-0175 1.2rc1
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 someu...@example.com or perhaps literally anonym...@example.com. A repeat user could then use the same full JID over and over, like someu...@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: someu...@example.com/This Is The Medicine You Need! or someu...@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., "anonym...@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. -bjc
Re: [Standards] XEP-0175 1.2rc1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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 someu...@example.com or perhaps literally anonym...@example.com. A repeat user could then use the same full JID over and over, like someu...@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: someu...@example.com/This Is The Medicine You Need! or someu...@example.com/stpeter-is-an-idiot Whether any of these attack vectors are worrisome is another matter. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqEuK4ACgkQNL8k5A2w/vxVSACfY2w+0+s5dYAsPqXIwSWGuEam rdsAn0HyZ0Gu+7UVFw5mGUDMattK4c7h =JH89 -END PGP SIGNATURE-
Re: [Standards] XEP-0175 1.2rc1
On 13-Aug-2009, at 20:54, Peter Saint-Andre wrote: On 8/13/09 6:53 PM, Brian Cully wrote: On 13-Aug-2009, at 20:45, Andy Skelton wrote: "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." I cannot find this text in XEP 0175. Perhaps you're looking at an older version? It's in the provisional version 1.2: http://xmpp.org/extensions/tmp/xep-0175-1.2.html Indeed it is, my apologies. I admit, I can't see why the recommendation is there except anal retentivity when the server is already generating unique bare JIDs. If the bare JID is unique to a given stream then the resource is completely redundant as there should never be any reason (that I can see, anyway) for resource mapping to come into play. By definition there will never be more than one resource to any given bare JID. Right? -bjc
Re: [Standards] XEP-0175 1.2rc1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/13/09 6:53 PM, Brian Cully wrote: > On 13-Aug-2009, at 20:45, Andy Skelton wrote: >> "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." > > I cannot find this text in XEP 0175. Perhaps you're looking at an > older version? It's in the provisional version 1.2: http://xmpp.org/extensions/tmp/xep-0175-1.2.html Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqEteEACgkQNL8k5A2w/vysZwCgiVtIXNRBeLbqIQSRFru6Adei QsoAnjayD1/PIS5JxussVqyDv4Xx8TXL =QBck -END PGP SIGNATURE-
Re: [Standards] XEP-0175 1.2rc1
Sorry, I should have pasted this link: http://xmpp.org/extensions/tmp/xep-0175-1.2.html On Thu, Aug 13, 2009 at 7:53 PM, Brian Cully wrote: > On 13-Aug-2009, at 20:45, Andy Skelton wrote: >> >> "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." > > I cannot find this text in XEP 0175. Perhaps you're looking at an > older version? > > What I see is: > > RFC 3920 specifies that after an XMPP client authenticates with an XMPP > server, it must bind a resource to the XML stream so that XML stanzas can be > routed to the client. In essence there are three resource binding scenarios: > > • The client specifies a desired resource identifier and the server > accepts it. > • The client specifies a desired resource identifier but the server > does not accept it, instead overruling the client and assigning a resource > identifier. > • The client asks the server to assign a resource identifier and the > server does so. > No matter which scenario is enacted, at the end of the process the server > informs the client of its full JID . In > particular, it might be helpful for an XMPP server to assign a full JID to > the client (i.e., not just the resource identifier) if it authenticates with > SASL ANONYMOUS, and to ensure that the "bare JID" portion > is unique in the context of the domain served by the > server. > > -bjc
Re: [Standards] XEP-0175 1.2rc1
On 13-Aug-2009, at 20:45, Andy Skelton wrote: "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." I cannot find this text in XEP 0175. Perhaps you're looking at an older version? What I see is: RFC 3920 specifies that after an XMPP client authenticates with an XMPP server, it must bind a resource to the XML stream so that XML stanzas can be routed to the client. In essence there are three resource binding scenarios: • The client specifies a desired resource identifier and the server accepts it. • The client specifies a desired resource identifier but the server does not accept it, instead overruling the client and assigning a resource identifier. • The client asks the server to assign a resource identifier and the server does so. No matter which scenario is enacted, at the end of the process the server informs the client of its full JID resource>. In particular, it might be helpful for an XMPP server to assign a full JID to the client (i.e., not just the resource identifier) if it authenticates with SASL ANONYMOUS, and to ensure that the "bare JID" portion is unique in the context of the domain served by the server. -bjc
