Re: [Standards] UPDATED: XEP-0257 (Client Certificate Management for SASL EXTERNAL)
A comment on a different issue: A free public XMPP server MUST allow self-signed certificates and certificatessigned by a CA unknown to the server. (line 184) I don't think this XEP is a good place to define policys and definitions of a free public XMPP server. That's outside of the scope. Adding a MUST here requires us to define free public XMPP server. /O
Re: [Standards] UPDATED: XEP-0257 (Client Certificate Management for SASL EXTERNAL)
12 feb 2009 kl. 18.03 skrev XMPP Extensions Editor: Version 0.2 of XEP-0257 (Client Certificate Management for SASL EXTERNAL) has been released. Abstract: This specification defines a method to manage client certificates that can be used with SASL External to allow clients to log in without a password. Changelog: [See revision history] (dm) Diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0257.xml?%40diffMode=u%40diffWrap=sr1=2598r2=2730u=3ignore=k= I think we should change the text about self-signed vs CA-signed that is currently a bit ambigous. I know that Dirk's use case is not CA- related, but I still think that the XEP should be more neutral and I see a lot of use cases where a CA will be required. It doesn't have to be a commercial CA, could be the congersman-frog-who-signs-anything CA as well, but we have reasons to verify the certificate chain. We could add a statement in the beginning about different models for trusting the certificates and then delete all references to whether the cert is signed by a trusted party or self-signed from other parts of the document. A recommendation for server developers would be to implement a model where the admin can set a policy for the use of certificates for SASL external: - Only trusted certificates for bare JID certificates and any cert for full JID (bot) certificates - Only trusted certificates for both bare JID and full JID certificates - Any kind of certificate With trusted certificates we mean a certificate that can be securely verified by checking the CA chain to a trusted CA certificate. /O
Re: [Standards] Password protected rooms
Matthew Wild wrote: This single issue aside however, I do think that the total lack of any way to track which services a JID is affiliated with is scary. This affects transports/gateways, MUCs, etc. Are roster subscriptions even cancelled on account removal? jabberd does that (since 2005).
Re: [Standards] UPDATED: XEP-0257 (Client Certificate Management for SASL EXTERNAL)
Johansson Olle E wrote: I think we should change the text about self-signed vs CA-signed that is currently a bit ambigous. I know that Dirk's use case is not CA- related, but I still think that the XEP should be more neutral and I see a lot of use cases where a CA will be required. I added the text on request based on a discussion on the summit (with you?). The only use case I could think of was a company internal use of XMPP. Maybe other use cases requiring a CA should be added to the beginning of the doc. Can you write down / outline some use cases? A recommendation for server developers would be to implement a model where the admin can set a policy for the use of certificates for SASL external: - Only trusted certificates for bare JID certificates and any cert for full JID (bot) certificates - Only trusted certificates for both bare JID and full JID certificates - Any kind of certificate From your other mail: A free public XMPP server MUST allow self-signed certificates and certificatessigned by a CA unknown to the server. (line 184) I don't think this XEP is a good place to define policys and definitions of a free public XMPP server. That's outside of the scope. Adding a MUST here requires us to define free public XMPP server. Yes, I also don't like how I wrote it down. I wrote it because I guess most people will not have a certificate for all their devices. Therefore I wanted to make sure that I can use self-signed certificates on public servers such as xmpp.org. Dirk -- May brute force be with you.
Re: [Standards] UPDATED: XEP-0257 (Client Certificate Management for SASL EXTERNAL)
Peter Saint-Andre wrote: So you'll have two kinds of certs: one that is limited to a particular full JID (let's call it a full-JID cert) and one that isn't (let's call it a bare-JID cert). If a bare-JID cert is currently logged in with a full JID that matches a given full-JID cert (e.g., our TV resource), then Dirk is suggesting that the client presenting the full-JID would have priority and the server would bump the client that presented a bare-JID cert. So that rule would provide guidance to the server regarding the alternatives described in Section 8.5.2.2 of rfc3920bis: http://xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-08.html#bind-clientsubmit-error-conflict Right. Section 8.5.2.2 gives many options and suggests to provide a different resource to the client. That is not possible with a full JID in the cert. I added it to my todo list for the next revision. Dirk -- ++?++ Out of Cheese Error. Redo From Start. -- (Terry Pratchett, Interesting Times)
Re: [Standards] XEP-0255: Location Query
Hi Helge, Having worked for www.Amethon.com last year I can tell you categorically that mobile handset ip addresses have very little location based information. You need a cell tower mapping system which isn't readily accessible by the applications etc. Ignore this problem for a few years and it will sort itself out, in the mean time I think your idea for mapping landline ip addresses etc is a great one. Cheers, Dean -Original Message- From: standards-boun...@xmpp.org [mailto:standards-boun...@xmpp.org] On Behalf Of Helge Timenes Sent: Friday, February 13, 2009 1:24 AM To: XMPP Standards Subject: [Standards] XEP-0255: Location Query Just a heads up notice: As suggested by Stephen Pendleton I plan to add ip-address to the type of beacons that can be submitted in a location query. The justification being that in most cases an IP address can be associated with a particular country, region and city. Some items of concern in this matter: A server implementing this XEP directly might be able to pull out a connected user's IP address without this tag. I assume a component style implementation does not have this option, or there would be little use in re-stating it explicitly in the stanza. This XEP is of particular interest for mobile applications. Does anyone know if the IP-to-location mapping holds true for mobile connections? Are handsets assigned an IP by the local carrier where you happen to be roaming, or by your home-network? Do mobile operators even use location-mappable IP addresses? As opposed to cell towers, wifi access points and bluetooth devices, an ip address can hardly be construed as a beacon in any sense of the word, i plan to change the nomenclature to simply reference from now on. Any injections/suggestions/comments? If no suggestions to the contrary, i will add type ip and rename beacon to reference. As already mentioned i feel more and more that breaking up the generic notation and using dedicated tags for each beacon/reference would make sense, but as there has not been much opinions in either direction on this I'll leave it as mentioned above under the motto if it ain't completely broken, don't fix it more than necessary... Helge
[Standards] Fw: [Security] Unsubscribe on Userdelete (Was: Password protected rooms)
This crossposting is hell. On Fri, 13 Feb 2009 11:52:19 +0100 Alexander Gnauck gna...@ag-software.de wrote: Thats an very interesting point - in many respects. Two more examples: - I have a service with many users from other servers subscribed. As there is no unsubscribe if the user has been deleted, I have many zombie-subscription. I can only check the subscriptions from my own server if the accounts still exist. And even that is not so easy. - A friend subscribed my presence. He was some time in hospital, so I never noticed, that his account was deleted on the server (due to inactivity?). As the jid came back online I wrote him gladly, how he is after the surgery... I realised very late, that the account was now new assigned. I had a similar problem when I unregistered my jabber.org account by error with a beta version of a client. The subscription was out of sync, and still is for many of my contacts, because server don't route my subscription requests. The only solution is to delete the contact on both sides and subscribe again. I had similar problems in other scenarios too... I see only the solution, that there has to be an unsubscribe-request to every contact in the roster of an user if that user is going to be deleted. right, this is how it should (MUST) be done. This does not help enough (though it catches the easiest cases). I believe the subscription stuff in XMPP should be further re-thinked. There are many real-world cases that break integrity of subscriptions across servers. * User delete * Server switch (if you're not careful enough about the database) * User grants subscription without being asked (I believe this is an implementation issue) * Some important presence/ stanza gets lost due to lost connection * Various server errors (happenes once, but the integrity is lost) * Other cases I believe the only way is to implement some sort of auto-correction that occures upon any sort of interaction. E.g. the server could check the subscription when the following suspicious (though many times valid) events occur. * You got a presence/ from someone you're not subscribed to * You got a message/ (or iq/) from someone you're subscribed to but you haven't got his presence * User tries to subscribe to someone he's already subscribed (and similar) * Of course, user deletion should trigger unsubscribe, but it would be better to distinguish it from regular unsubscribe. It would also be good to have some sort of redirection support that would allow an account to be in a state between registered and nonexistant. Could be as simple as a redirect/ element in any error answers. Supporting clients could then offer the user to *delete* the contact or *replace* the contact with his new ID, request subscription and retain group, local name and comments. Pavel Alex -- Alexander Gnauck http://www.ag-software.de xmpp:gna...@jabber.org -- Freelance consultant and trainer in networking, communications and security. Web: http://www.pavlix.net/ Jabber, Mail: pavlix(at)pavlix.net OpenID: pavlix.net -- Freelance consultant and trainer in networking, communications and security. Web: http://www.pavlix.net/ Jabber, Mail: pavlix(at)pavlix.net OpenID: pavlix.net
Re: [Standards] XEP-0255: Location Query
-Original Message- From: standards-boun...@xmpp.org [mailto:standards-boun...@xmpp.org] On Behalf Of Helge Timenes Sent: 02/13/2009 1:24 AM To: XMPP Standards Subject: [Standards] XEP-0255: Location Query Just a heads up notice: As suggested by Stephen Pendleton I plan to add ip-address to the type of beacons that can be submitted in a location query. The justification being that in most cases an IP address can be associated with a particular country, region and city. Some items of concern in this matter: A server implementing this XEP directly might be able to pull out a connected user's IP address without this tag. I assume a component style implementation does not have this option, or there would be little use in re-stating it explicitly in the stanza. This XEP is of particular interest for mobile applications. Does anyone know if the IP-to-location mapping holds true for mobile connections? Are handsets assigned an IP by the local carrier where you happen to be roaming, or by your home-network? Do mobile operators even use location-mappable IP addresses? As opposed to cell towers, wifi access points and bluetooth devices, an ip address can hardly be construed as a beacon in any sense of the word, i plan to change the nomenclature to simply reference from now on. Any injections/suggestions/comments? If no suggestions to the contrary, i will add type ip and rename beacon to reference. IP address is worthless for mobile radio (data/gprs/etc) devices. However it would be helpful for other IP devices (laptops, desktops, etc). Also, the server already has the connected users IP address anyway, so maybe I am missing something? Thanks
[Standards] UPDATED: XEP-0234 (Jingle File Transfer)
Version 0.9 of XEP-0234 (Jingle File Transfer) has been released. Abstract: This specification defines a Jingle application type for transferring files between two entities. The protocol provides a modular framework that enables the exchange of information about the file to be transferred as well as the negotiation of parameters such as the transport to be used. Changelog: [See revision history] (psa) Diff: http://svn.xmpp.org:18080/browse/XMPP/trunk/extensions/xep-0234.xml?%40diffMode=u%40diffWrap=sr1=2291r2=2733u=3ignore=k= URL: http://www.xmpp.org/extensions/xep-0234.html
