Re: [Standards] XEP-0175 feedback
I'm fine with those amendments, Dave. 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 auth/ 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 feedback
Cheers, 2009/9/11 Jack Moffitt j...@collecta.com: In general, the proposed changes in v1.2 at http://xmpp.org/extensions/tmp/xep-0175-1.2.html are sound ones. I do however have some minor points to raise. 1) The current wording states that anonymous users SHOULD NOT be able to establish long term relationships. I believe this is too strong. I think that it will be quite common to use SASL ANONYMOUS clients to do things like pubsub scriptions and creating muc rooms. My team and I have done this in nearly every app we've written. I do however agree that it makes sense to tear these down once the session is over. I propose the following wording instead: Anonymous users MAY establish relationships with services and users if allowed by sever policy such as presence subscriptions, multi-user chat rooms, and pubsub subscriptions. If a server permits these relationships, it MUST cancel such relationships when the user's session ends. I agree. I also often allow SASL ANONYMOUS clients to have time based PubSub subscriptions (or even presence based on my tests). Same for muc rooms based stuff. When user's session ends the cleaning must be done accordingly of course. Good weekend for all, -- tuomas 2009/9/11 Jack Moffitt j...@collecta.com: I might add another sentence as well: It is not recommended that SASL ANONYMOUS users add human contacts to their rosters, as this may create odd user experiences. 2) The next line states that users SHOULD NOT store things on the server, and that if so the server MUST delete them. This is also overly restrictive. I can see several use cases where one would want to temporarily store something on the server and retrieve it in another session, similar to an HTTP cookie. I think that it should be the server operators perogative to allow or disallow storage and to determine when that storage is undone. Perhaps changing the MUST to MAY is enough. I do think that Peter's previous feedback of there being two different scenarios is spot on. Some of us see this as what should SASL ANONYMOUS users be able to do on jabber.org and some of us are not running IM servers, but using SASL ANONYMOUS as a tool in a bigger application. I think the above wording proposals are good enough for both cases, but if people feel strongly otherwise, I think we may have to split this into two sections of recommendations for the different use cases. jack.
Re: [Standards] XEP-0175 feedback
On Fri Sep 11 18:27:10 2009, Jack Moffitt wrote: Anonymous users MAY establish relationships with services and users if allowed by sever policy such as presence subscriptions, multi-user chat rooms, and pubsub subscriptions. If a server permits these relationships, it MUST cancel such relationships when the user's session ends. That's what I took it to mean by long term relationships. A pubsub subscription that only lasts a session is, IMHO, comfortably within the one-night-stand length. Still, I'd go for SHOULD NOT, I can conceive of cases whereby this rule may need breaking, at least locally. It is not recommended that SASL ANONYMOUS users add human contacts to their rosters, as this may create odd user experiences. This makes sense, too. I'd go for NOT RECOMMENDED, though. (== SHOULD NOT). 2) The next line states that users SHOULD NOT store things on the server, and that if so the server MUST delete them. This is also overly restrictive. I can see several use cases where one would want to temporarily store something on the server and retrieve it in another session, similar to an HTTP cookie. I think that it should be the server operators perogative to allow or disallow storage and to determine when that storage is undone. Perhaps changing the MUST to MAY is enough. Or SHOULD, with a note that there are cases where service operators may need to rely on storage of data by anonymous clients. SHOULD means Do this unless you know better. I do worry that although *you* certainly do know when to break these rules, a server implementor might think Oh, hey, I don't have to do that then. The note implies that a configuration option might be useful to control this. Dave. -- Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
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 auth/ 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 9/3/09 2:34 PM, Home wrote: --- Original message --- From: Kevin Smith ke...@kismith.co.uk Sent: 3/9/'09, 18:07 On Wed, Sep 2, 2009 at 9:39 PM, Peter Saint-Andrestpe...@stpeter.im 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
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
On Wed, Sep 2, 2009 at 9:39 PM, Peter Saint-Andrestpe...@stpeter.im 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
--- Original message --- From: Kevin Smith ke...@kismith.co.uk Sent: 3/9/'09, 18:07 On Wed, Sep 2, 2009 at 9:39 PM, Peter Saint-Andrestpe...@stpeter.im 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
-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 Cullybcu...@gmail.com 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 Wed, Sep 2, 2009 at 3:39 PM, Peter Saint-Andrestpe...@stpeter.im 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
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 localp...@domain.tld/ 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 localp...@domain.tld is unique in the context of the domain served by the server. -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
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: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 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
On Thu, Aug 13, 2009 at 8:15 PM, Brian Cullybcu...@gmail.com 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 v. 1.2rc1
Hi, Indeed this draft provides more detailed information. It's great :) I think it would be useful to make a similar draft for PLAIN method, the core xmpp RFC only explaining the digest-md5 method. Thanks for this work, regards, Eloi On Mon, Jul 6, 2009 at 8:23 PM, Peter Saint-Andre stpe...@stpeter.imwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 As discussed recently on the list, I've updated XEP-0175 (Best Practices for Use of SASL ANONYMOUS) to provide more detailed recommendations regarding usage restrictions for anonymous users. http://xmpp.org/extensions/tmp/xep-0175-1.2.html http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0175.xml?%40diffMode=u%40diffWrap=sr1=1675r2=3308u=3ignore=k= 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 iEYEARECAAYFAkpSMwMACgkQNL8k5A2w/vwIlACeIIucufW62wDiqgVBUUeGowbK XVsAoMm8PZAZb3d0VjCuV32yIAvE0uFi =cvXd -END PGP SIGNATURE-
Re: [Standards] XEP-0175 v. 1.2rc1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/6/09 11:40 AM, Eloi Bail wrote: Indeed this draft provides more detailed information. It's great :) Super! I think it would be useful to make a similar draft for PLAIN method, the core xmpp RFC only explaining the digest-md5 method. The document http://tools.ietf.org/html/draft-ietf-xmpp-3920bis has more information about PLAIN (and indeed DIGEST-MD5 is deprecated there). I would not object to a document Best Practices for Use of SASL PLAIN but I think that PLAIN is quite straightforward, unlike EXTERNAL with certificates = XEP-0178 (there is always lots of confusion about certs!) or ANONYMOUS (it's important to provide recommendations about how the server needs to restrict the user's access). Thanks for this work, Sure thing! 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 iEUEARECAAYFAkpSOPQACgkQNL8k5A2w/vyE/gCdFlHNvkJhiZb/vwMHIzA4cGWK ng4AmJjPJ5kOa6f28fRPrriw5jDuwXo= =r1cM -END PGP SIGNATURE-
Re: [Standards] XEP-0175 v. 1.2rc1
Eloi Bail wrote: Hi, Indeed this draft provides more detailed information. It's great :) I like the new text on ANONYMOUS as well. I think it would be useful to make a similar draft for PLAIN method, the core xmpp RFC only explaining the digest-md5 method. I think we need to be careful about describing handling of each SASL mechanism, as this defeats the purpose of having generic SASL libraries that support multiple authentication mechanisms. While I agree that ANONYMOUS and PLAIN are a bit special, we need to have a criteria on which mechanisms should deserve own XEPs. If there are issues with how some SASL mechanisms are described, which are not specific to XMPP, then the IETF SASL WG needs to be notified.
Re: [Standards] XEP-0175 v. 1.2rc1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/6/09 11:50 AM, Alexey Melnikov wrote: Eloi Bail wrote: Hi, Indeed this draft provides more detailed information. It's great :) I like the new text on ANONYMOUS as well. Good. I think it would be useful to make a similar draft for PLAIN method, the core xmpp RFC only explaining the digest-md5 method. I think we need to be careful about describing handling of each SASL mechanism, as this defeats the purpose of having generic SASL libraries that support multiple authentication mechanisms. While I agree that ANONYMOUS and PLAIN are a bit special, we need to have a criteria on which mechanisms should deserve own XEPs. If there are issues with how some SASL mechanisms are described, which are not specific to XMPP, then the IETF SASL WG needs to be notified. Agreed. It seems to me that, for example, RFC 4505 (ANONYMOUS) leaves a number of items up to the implementation or the using application. For example, what does restricted access mean? That might mean something different in XMPP vs. IMAP or LDAP or whatever, so I think it's good to discuss those issues in a XEP. If our discussions raise more general issues, then I think it's important for us to bring those to the SASL WG list. 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 iEYEARECAAYFAkpSOzsACgkQNL8k5A2w/vzEZgCfSKTOtiT2n+R/+EfsRsr2uxFf GB0AnRr27eozz+oJL4mUhQY3I7eagHz2 =9w6n -END PGP SIGNATURE-
Re: [Standards] XEP-0175 v. 1.2rc1
Peter Saint-Andre schrieb: As discussed recently on the list, I've updated XEP-0175 (Best Practices for Use of SASL ANONYMOUS) to provide more detailed recommendations regarding usage restrictions for anonymous users. http://xmpp.org/extensions/tmp/xep-0175-1.2.html http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0175.xml?%40diffMode=u%40diffWrap=sr1=1675r2=3308u=3ignore=k= One additional thing that might make banning those users in a room easier: Encode the originating ip address in the resource using either a hash or a symmetric encryption algorithm so that whenever a user connects from the same IP, they get the same resource (or resource-prefix). In IRC, this enables room operators to ban a specific IP without disclosing the address itself. philipp
Re: [Standards] XEP-0175 v. 1.2rc1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/6/09 12:09 PM, Philipp Hancke wrote: Peter Saint-Andre schrieb: As discussed recently on the list, I've updated XEP-0175 (Best Practices for Use of SASL ANONYMOUS) to provide more detailed recommendations regarding usage restrictions for anonymous users. http://xmpp.org/extensions/tmp/xep-0175-1.2.html http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0175.xml?%40diffMode=u%40diffWrap=sr1=1675r2=3308u=3ignore=k= One additional thing that might make banning those users in a room easier: Encode the originating ip address in the resource using either a hash or a symmetric encryption algorithm so that whenever a user connects from the same IP, they get the same resource (or resource-prefix). In IRC, this enables room operators to ban a specific IP without disclosing the address itself. That seems sensible. Something like cryptopan? http://www.cc.gatech.edu/computing/Telecomm/projects/cryptopan/ 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 iEYEARECAAYFAkpSQPQACgkQNL8k5A2w/vxnOACg3AS8Zb5ubDNyiPII1NVLzcyH M8IAnRZNsUXnjsuzp7jiG8UlumAUxyZE =9OKk -END PGP SIGNATURE-
Re: [Standards] XEP-0175 v. 1.2rc1
Peter Saint-Andre schrieb: On 7/6/09 12:09 PM, Philipp Hancke wrote: Peter Saint-Andre schrieb: As discussed recently on the list, I've updated XEP-0175 (Best Practices for Use of SASL ANONYMOUS) to provide more detailed recommendations regarding usage restrictions for anonymous users. http://xmpp.org/extensions/tmp/xep-0175-1.2.html http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0175.xml?%40diffMode=u%40diffWrap=sr1=1675r2=3308u=3ignore=k= One additional thing that might make banning those users in a room easier: Encode the originating ip address in the resource using either a hash or a symmetric encryption algorithm so that whenever a user connects from the same IP, they get the same resource (or resource-prefix). In IRC, this enables room operators to ban a specific IP without disclosing the address itself. That seems sensible. heh... xmpp should be more like irc ;-) Something like cryptopan? http://www.cc.gatech.edu/computing/Telecomm/projects/cryptopan/ Nice. That's way more advanced than what some ircds do. What ircds usually did is map the ip/hostname to cryptothing.provider.tld This enables room operators to ban whole providers or even countries with a single command. cryptopan sounds like a good idea, but might be too difficult for the average room operator. philipp
Re: [Standards] XEP-0175 v. 1.2rc1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/6/09 12:40 PM, Philipp Hancke wrote: Peter Saint-Andre schrieb: On 7/6/09 12:09 PM, Philipp Hancke wrote: Peter Saint-Andre schrieb: As discussed recently on the list, I've updated XEP-0175 (Best Practices for Use of SASL ANONYMOUS) to provide more detailed recommendations regarding usage restrictions for anonymous users. http://xmpp.org/extensions/tmp/xep-0175-1.2.html http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0175.xml?%40diffMode=u%40diffWrap=sr1=1675r2=3308u=3ignore=k= One additional thing that might make banning those users in a room easier: Encode the originating ip address in the resource using either a hash or a symmetric encryption algorithm so that whenever a user connects from the same IP, they get the same resource (or resource-prefix). In IRC, this enables room operators to ban a specific IP without disclosing the address itself. That seems sensible. heh... xmpp should be more like irc ;-) Well, in fact, if the server doesn't allow outbound communication (to remote domains) then the server can correlate the IP addresses of banned anonymous users and come to its own conclusions -- there is no real need for the server to transform the IP address into the resource identifier because the room admins don't need to know or care about IP addresses. That logic changes if you allow an anonymous user to communicate with entities on remote servers. But then it's a more general problem, and not limited to anonymous users. Something like cryptopan? http://www.cc.gatech.edu/computing/Telecomm/projects/cryptopan/ Nice. That's way more advanced than what some ircds do. What ircds usually did is map the ip/hostname to cryptothing.provider.tld This enables room operators to ban whole providers or even countries with a single command. cryptopan sounds like a good idea, but might be too difficult for the average room operator. I think we're now into a MUC issue, not a SASL ANONYMOUS issue... 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 iEYEARECAAYFAkpSSM8ACgkQNL8k5A2w/vzwtQCfWL1kpaVz3+OffAUc7U+bkklA wlUAoJBu8VXQ84A2KlMUc0g4ZzsoIxp/ =3G2o -END PGP SIGNATURE-
Re: [Standards] XEP-0175
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 7/2/09 9:28 PM, Matthew Wild wrote: On Thu, Jul 2, 2009 at 5:02 PM, Peter Saint-Andrestpe...@stpeter.im wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/30/09 8:37 AM, Dave Cridland wrote: On Tue Jun 30 15:33:35 2009, Matthew Wild wrote: It does. Anonymous users get given a unique (~random) JID, with an empty roster. So you /can/ send presence, you just either have to send it to a known address, or add people to your temporary roster first. FWIW, although I agree that's what *should* happen, nothing in the specifications available says that's what does. Perhaps an update to include such things in XEP-0175 is in order? Indeed, aligning XEP-0175 more closely with RFC 4505 might be helpful. For example, RFC 4505 says that typically an anonymous user will have restricted access but it seems to leave the definition of restricted access up to the application protocol. The security considerations section of RFC 4505 talks about denial of service attacks and the like, so we might want to discuss such issues in XEP-0175 a bit more than we do now. Et cetera. Based on this and discussion on the topic the other day in jdev, I just made a commit to Prosody to disable s2s by default for anonymous users. This can of course be overridden by admins if they so choose, but it seems a very sane default for me. I wouldn't be against adding this recommendation to XEP-0175. Yes, I was thinking about that yesterday after I posted: when we say that an anonymous user should have restricted access, what does that mean? In part it might mean that the user is temporary and therefore cannot establish permanent relationships via pubsub subscriptions, registration with chatrooms, etc. If the user does that on the local server, the local server can clean up after the anonymous user's session is over, but the local server can't perform that cleanup if the user has taken such actions on a remote server, so I think that forbidding outbound s2s communication is a reasonable restriction. 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 iEYEARECAAYFAkpOAnEACgkQNL8k5A2w/vyiTACgvQ/aEkDiIum4SP5r4ugMBena +V8An2Ki3dRSN8BxlyqzdQvfGs4+N2eQ =N64f -END PGP SIGNATURE-
Re: [Standards] XEP-0175 (was: Re: Anonymous SASL and Presence)
On Thu, Jul 2, 2009 at 5:02 PM, Peter Saint-Andrestpe...@stpeter.im wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/30/09 8:37 AM, Dave Cridland wrote: On Tue Jun 30 15:33:35 2009, Matthew Wild wrote: It does. Anonymous users get given a unique (~random) JID, with an empty roster. So you /can/ send presence, you just either have to send it to a known address, or add people to your temporary roster first. FWIW, although I agree that's what *should* happen, nothing in the specifications available says that's what does. Perhaps an update to include such things in XEP-0175 is in order? Indeed, aligning XEP-0175 more closely with RFC 4505 might be helpful. For example, RFC 4505 says that typically an anonymous user will have restricted access but it seems to leave the definition of restricted access up to the application protocol. The security considerations section of RFC 4505 talks about denial of service attacks and the like, so we might want to discuss such issues in XEP-0175 a bit more than we do now. Et cetera. Based on this and discussion on the topic the other day in jdev, I just made a commit to Prosody to disable s2s by default for anonymous users. This can of course be overridden by admins if they so choose, but it seems a very sane default for me. I wouldn't be against adding this recommendation to XEP-0175. Matthew
Re: [Standards] XEP-0175: Contact Addresses
Carlo v. Loesch wrote: Peter Saint-Andre typeth: | vCard is not very extensible on this point -- we can include a JabberID | via our hack of vcard-xml and I suppose that's OK. Perhaps we can even | include multiple JabberIDs. :) What about a list of URIs, so you can put all xmpp:jids, OpenID, and ahum URIs of other protocols in there next to each other. Possibly in the order of preference, which otherwise would be missing. The vCard XML format does include a URL/ element, but I think that was intended only for http URLs. Or something. IMHO vCard was never very well specified... Also I ran into a problem parsing this format, as it isn't semantically equivalent to vCard: TELVOICE/HOME/NUMBER303-555-1212/NUMBER/TEL I can't access it using an XPath-kind of approach as I could if it were written like this: TELVOICEHOMENUMBER303-555-1212/NUMBER/HOME/VOICE/TEL Regular vCard syntax is TEL;VOICE;HOME which gives me a clear hierarchy and at the same time a simple string to access. I miss that simplicity in XEP-0054. I decided not to handle this special case and simply return anything that has NUMBER in TEL, which may randomly turn out to be a voice or fax number out of 5 possibly provided numbers. Not a nice solution. It's probably too late to fix this, but I can try to ask anyway. It's too late to fix this. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0175: Contact Addresses
Pedro Melo wrote: Hi, On Mar 18, 2008, at 4:37 AM, Peter Saint-Andre wrote: Pedro Melo wrote: Hi, during the latest DevCon, one of the issues about deployment was contact addresses. The current XEP for that is 0157. I think that 157 breaks the current disco#info usage pattern. We use disco#info to discover which protocols an entity supports, not the get the information directly (exception for basic identity ). So receiving the entire contact information in the disco#info reply seems wrong, because on most requests, we don't need it. I think we should use a pubsub node instead. This would give us all the benefits of pubsub, and we could probably implement this faster, given that pubsub and pep are starting to get deployed in latest releases of some servers like Openfire and Ejabberd. The schema for the information could be reused from XEP-0157 or XEP-0154 if that one comes back from the dead. Why not just put this in one of the following? 1. server vCard (XEP-0054) 2. server profile (XEP-0154) I'm ok with either, and I think any of them is better than xep-0157. Profiles seem to be in limbo right now, and vCards are widely deployed, so I think that server vCard is the best one right now. vCard is not very extensible on this point -- we can include a JabberID via our hack of vcard-xml and I suppose that's OK. Perhaps we can even include multiple JabberIDs. :) Profiles are in limbo only because they've received less attention than technologies on which they depend (e.g., PEP). But now that work is done on the preliminaries, perhaps we can revisit profiles. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0175: Contact Addresses
Peter Saint-Andre typeth: | vCard is not very extensible on this point -- we can include a JabberID | via our hack of vcard-xml and I suppose that's OK. Perhaps we can even | include multiple JabberIDs. :) What about a list of URIs, so you can put all xmpp:jids, OpenID, and ahum URIs of other protocols in there next to each other. Possibly in the order of preference, which otherwise would be missing. Also I ran into a problem parsing this format, as it isn't semantically equivalent to vCard: TELVOICE/HOME/NUMBER303-555-1212/NUMBER/TEL I can't access it using an XPath-kind of approach as I could if it were written like this: TELVOICEHOMENUMBER303-555-1212/NUMBER/HOME/VOICE/TEL Regular vCard syntax is TEL;VOICE;HOME which gives me a clear hierarchy and at the same time a simple string to access. I miss that simplicity in XEP-0054. I decided not to handle this special case and simply return anything that has NUMBER in TEL, which may randomly turn out to be a voice or fax number out of 5 possibly provided numbers. Not a nice solution. It's probably too late to fix this, but I can try to ask anyway.
Re: [Standards] XEP-0175: Contact Addresses
Hi, On Mar 18, 2008, at 4:37 AM, Peter Saint-Andre wrote: Pedro Melo wrote: Hi, during the latest DevCon, one of the issues about deployment was contact addresses. The current XEP for that is 0157. I think that 157 breaks the current disco#info usage pattern. We use disco#info to discover which protocols an entity supports, not the get the information directly (exception for basic identity ). So receiving the entire contact information in the disco#info reply seems wrong, because on most requests, we don't need it. I think we should use a pubsub node instead. This would give us all the benefits of pubsub, and we could probably implement this faster, given that pubsub and pep are starting to get deployed in latest releases of some servers like Openfire and Ejabberd. The schema for the information could be reused from XEP-0157 or XEP-0154 if that one comes back from the dead. Why not just put this in one of the following? 1. server vCard (XEP-0054) 2. server profile (XEP-0154) I'm ok with either, and I think any of them is better than xep-0157. Profiles seem to be in limbo right now, and vCards are widely deployed, so I think that server vCard is the best one right now. Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP!
Re: [Standards] XEP-0175: Contact Addresses
Sorry for the slow reply... Pedro Melo wrote: Hi, during the latest DevCon, one of the issues about deployment was contact addresses. The current XEP for that is 0157. I think that 157 breaks the current disco#info usage pattern. We use disco#info to discover which protocols an entity supports, not the get the information directly (exception for basic identity ). So receiving the entire contact information in the disco#info reply seems wrong, because on most requests, we don't need it. I think we should use a pubsub node instead. This would give us all the benefits of pubsub, and we could probably implement this faster, given that pubsub and pep are starting to get deployed in latest releases of some servers like Openfire and Ejabberd. The schema for the information could be reused from XEP-0157 or XEP-0154 if that one comes back from the dead. Why not just put this in one of the following? 1. server vCard (XEP-0054) 2. server profile (XEP-0154) Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] XEP-0175: Contact Addresses
On Feb 26, 2008, at 3:05 PM, Maciek Niedzielski wrote: Pedro Melo pisze: during the latest DevCon, one of the issues about deployment was contact addresses. The current XEP for that is 0157. I think that 157 breaks the current disco#info usage pattern. We use disco#info to discover which protocols an entity supports, not the get the information directly (exception for basic identity ). So receiving the entire contact information in the disco#info reply seems wrong, because on most requests, we don't need it. I think we should use a pubsub node instead. If I remember well, disco + data forms were choosen to make this very easy to implement (using basic XEPs), because this information was considered very important. The information is important but not to everyone, nor on every request of disco. Now, if you go with pubsub, we run into where is that node? problem again. And for PEP you'd need to subscribe to server's presence.. The node is the namespace presented in 157 for example. iq type='set' from='[EMAIL PROTECTED]/barracks' to='pubsub.shakespeare.lit' id='sub1' pubsub xmlns='http://jabber.org/protocol/pubsub' subscribe node='http://jabber.org/network/serverinfo' jid='my_domain'/ /pubsub /iq So there is no issue with the node name. And you don't need PEP, just basic pubsub. Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP!
Re: [Standards] XEP-0175: Contact Addresses
Pedro Melo pisze: On Feb 26, 2008, at 3:05 PM, Maciek Niedzielski wrote: Pedro Melo pisze: during the latest DevCon, one of the issues about deployment was contact addresses. The current XEP for that is 0157. I think that 157 breaks the current disco#info usage pattern. Now, if you go with pubsub, we run into where is that node? problem again. And for PEP you'd need to subscribe to server's presence.. The node is the namespace presented in 157 for example. iq type='set' from='[EMAIL PROTECTED]/barracks' to='pubsub.shakespeare.lit' id='sub1' pubsub xmlns='http://jabber.org/protocol/pubsub' subscribe node='http://jabber.org/network/serverinfo' jid='my_domain'/ /pubsub /iq So there is no issue with the node name. But now you need to know (from where?) that info about jabber.org is stored in pubsub.jabber.org. -- Maciek xmpp:[EMAIL PROTECTED]
Re: [Standards] XEP-0175: Contact Addresses
Hi, On Feb 26, 2008, at 3:15 PM, Joe Hildebrand wrote: What about section 6.3 of the new version of XEP-115? stream:features c xmlns='http://jabber.org/protocol/caps' hash='sha-1' node='http://jabberd.org' ver='ItBTI0XLDFvVxZ72NQElAzKS9sU=' /stream:features Then you don't even have to do the disco, except the first time. Yes, that would cut down the number of disco's in everything we do, but I still think putting this information in there is wrong. If we do this for 157, why not slap the jabber:id:time in there? The pattern has been: use disco#info to discover support, then use a IQ GET or something similar to retrieve the information. And I don't see any reason to break the pattern. Best regards, On Feb 26, 2008, at 7:24 AM, Pedro Melo wrote: Hi, during the latest DevCon, one of the issues about deployment was contact addresses. The current XEP for that is 0157. I think that 157 breaks the current disco#info usage pattern. We use disco#info to discover which protocols an entity supports, not the get the information directly (exception for basic identity ). So receiving the entire contact information in the disco#info reply seems wrong, because on most requests, we don't need it. I think we should use a pubsub node instead. This would give us all the benefits of pubsub, and we could probably implement this faster, given that pubsub and pep are starting to get deployed in latest releases of some servers like Openfire and Ejabberd. The schema for the information could be reused from XEP-0157 or XEP-0154 if that one comes back from the dead. Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP! -- Joe Hildebrand -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP!
Re: [Standards] XEP-0175: Contact Addresses
Hi, On Feb 27, 2008, at 3:47 PM, Maciek Niedzielski wrote: Pedro Melo pisze: On Feb 26, 2008, at 3:05 PM, Maciek Niedzielski wrote: Pedro Melo pisze: during the latest DevCon, one of the issues about deployment was contact addresses. The current XEP for that is 0157. I think that 157 breaks the current disco#info usage pattern. Now, if you go with pubsub, we run into where is that node? problem again. And for PEP you'd need to subscribe to server's presence.. The node is the namespace presented in 157 for example. iq type='set' from='[EMAIL PROTECTED]/barracks' to='pubsub.shakespeare.lit' id='sub1' pubsub xmlns='http://jabber.org/protocol/pubsub' subscribe node='http://jabber.org/network/serverinfo' jid='my_domain'/ /pubsub /iq So there is no issue with the node name. But now you need to know (from where?) that info about jabber.org is stored in pubsub.jabber.org. Sorry, my mistake. Replace pubsub.shakespeare.lit with shakespeare.lit. As with PEP, we use the domain as the pubsub server. Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP!
Re: [Standards] XEP-0175: Contact Addresses
Dnia 2008-02-26, Wt o godzinie 16:05 +0100, Maciek Niedzielski pisze: If I remember well, disco + data forms were choosen to make this very easy to implement (using basic XEPs), because this information was considered very important. This is _the_ point. Pedro, have you read the Standards-JIG archives on the topic? This could answer many of your concerns. -- /\_./o__ Tomasz Sterna (/^/(_^^' http://www.xiaoka.com/ ._.(_.)_ im:[EMAIL PROTECTED]
Re: [Standards] XEP-0175: Contact Addresses
Pedro Melo pisze: during the latest DevCon, one of the issues about deployment was contact addresses. The current XEP for that is 0157. I think that 157 breaks the current disco#info usage pattern. We use disco#info to discover which protocols an entity supports, not the get the information directly (exception for basic identity ). So receiving the entire contact information in the disco#info reply seems wrong, because on most requests, we don't need it. I think we should use a pubsub node instead. If I remember well, disco + data forms were choosen to make this very easy to implement (using basic XEPs), because this information was considered very important. Now, if you go with pubsub, we run into where is that node? problem again. And for PEP you'd need to subscribe to server's presence.. -- Maciek xmpp:[EMAIL PROTECTED]
Re: [Standards] XEP-0175: Contact Addresses
Pedro Melo pisze: I think that 157 breaks the current disco#info usage pattern. We use disco#info to discover which protocols an entity supports, not the get the information directly (exception for basic identity ). So receiving the entire contact information in the disco#info reply seems wrong, because on most requests, we don't need it. Maybe we could use disco with a well-know node? -- Maciek xmpp:[EMAIL PROTECTED]
Re: [Standards] XEP-0175: Contact Addresses
What about section 6.3 of the new version of XEP-115? stream:features c xmlns='http://jabber.org/protocol/caps' hash='sha-1' node='http://jabberd.org' ver='ItBTI0XLDFvVxZ72NQElAzKS9sU=' /stream:features Then you don't even have to do the disco, except the first time. On Feb 26, 2008, at 7:24 AM, Pedro Melo wrote: Hi, during the latest DevCon, one of the issues about deployment was contact addresses. The current XEP for that is 0157. I think that 157 breaks the current disco#info usage pattern. We use disco#info to discover which protocols an entity supports, not the get the information directly (exception for basic identity ). So receiving the entire contact information in the disco#info reply seems wrong, because on most requests, we don't need it. I think we should use a pubsub node instead. This would give us all the benefits of pubsub, and we could probably implement this faster, given that pubsub and pep are starting to get deployed in latest releases of some servers like Openfire and Ejabberd. The schema for the information could be reused from XEP-0157 or XEP-0154 if that one comes back from the dead. Best regards, -- Pedro Melo Blog: http://www.simplicidade.org/notes/ XMPP ID: [EMAIL PROTECTED] Use XMPP! -- Joe Hildebrand
