Re: [Standards] Proposed XMPP Extension: Remote Authentication
On Thu Dec 2 17:16:06 2010, Kim Alvefur wrote: On Thu, 2010-12-02 at 17:06 +, Dave Cridland wrote: > (FWIW, I wondered for some time about clients generating a CSR and > having servers actually be PKIX CAs, but that equally gains nothing, > except adding lots more exciting-looking X.509). > > Of course, if the certificate is signed by a trusted party (ie, a > real CA), then everything changes - the server cannot advertise a > false certificate any longer, so the situation is entirely different. This is where it would have been useful for the PKIX CA structure to be more like DNS, so you could sign certs for your own users and subdomains etc. Of course, you could do that with DNSSEC and CERT records. Or you could do it with a mad CA which authenticated you as the owner of a domain, and then granted you an ICA certificate with name constraints for the domain. Quite excitingly mad, actually - I'm almost tempted. 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] Proposed XMPP Extension: Remote Authentication
On Thu, 2010-12-02 at 17:06 +, Dave Cridland wrote: > (FWIW, I wondered for some time about clients generating a CSR and > having servers actually be PKIX CAs, but that equally gains nothing, > except adding lots more exciting-looking X.509). > > Of course, if the certificate is signed by a trusted party (ie, a > real CA), then everything changes - the server cannot advertise a > false certificate any longer, so the situation is entirely different. This is where it would have been useful for the PKIX CA structure to be more like DNS, so you could sign certs for your own users and subdomains etc. -- Kim Alvefur signature.asc Description: This is a digitally signed message part
Re: [Standards] Proposed XMPP Extension: Remote Authentication
On Thu, 2010-12-02 at 20:18 +0500, Waqas Hussain wrote: > S2S poses an issue for normal EXTERNAL auth for remote > clients. Didn't someone mention direct communication with the MUC host over Jingle? Then XTLS! :D -- Kim Alvefur signature.asc Description: This is a digitally signed message part
Re: [Standards] Proposed XMPP Extension: Remote Authentication
On Thu Dec 2 15:47:04 2010, Peter Saint-Andre wrote: Another idea: client auto-generates a cert for me and I register it with my server when I register an account (or after the first login). If you're reliant on the server to "vouch" for your public key (which is all the certificate is, here), then you're effectively treating the server as a kind of quasi-CA - it is asserting that the certificate is yours. It also means that remote entities must: a) Trust your server to make that assertion. b) Authenticate your server. However, both are essentially true anyway, aren't they? We assume that if the server jabber.org says a stanza is from stpe...@jabber.org, then it's being honest, and we assume that a server really is jabber.org and able to make that assertion by authenticating it (either with X.509 or DNS, whichever our server trusts). So my general feeling here is that in terms of authentication, such a pattern actually gains us nothing. It intuitively *feels* like it should, of course, but I can't see what it does actually gain. (FWIW, I wondered for some time about clients generating a CSR and having servers actually be PKIX CAs, but that equally gains nothing, except adding lots more exciting-looking X.509). Of course, if the certificate is signed by a trusted party (ie, a real CA), then everything changes - the server cannot advertise a false certificate any longer, so the situation is entirely different. 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] Proposed XMPP Extension: Remote Authentication
On Dec 2, 2010, at 8:35 AM, Kurt Zeilenga wrote: > On Dec 1, 2010, at 6:54 PM, XMPP Extensions Editor wrote: > >> The XMPP Extensions Editor has received a proposal for a new XEP. >> >> Title: Remote Authentication >> >> Abstract: This document defines an XMPP protocol extension that enables >> entities to use SASL for authentication with remote services (such as >> Multi-User Chat rooms). >> >> URL: http://www.xmpp.org/extensions/inbox/remote-auth.html >> >> The XMPP Council will decide at its next meeting whether to accept this >> proposal as an official XEP. >> > > While I have no objection at present to this becoming a XEP, I have some > concerns. > > It's not clear what exactly the problem is that this extension is trying to > solve. > > It doesn't seem to be trying to generally solve how to provide secure > communications between any two entities. > > It seems more focused on addressing the MUC password issues. I note that MUC > passwords are not about identity authentication, so it's not clear to me why > SASL, which is about identity authentication and channel protection, is > applicable to this problem. > > Assuming this is about the MUC password issue, I note that the concern here > has generally been that about eavesdroppers being about to discover the > passwords (such as when C2S or S2S streams are not protected via TLS). To > address this, I think the best answer is "use TLS, damn it". It might be > useful to design an extension which advises the entity one provides a stanza > to as to what the stanza should only be forwarded via protected channels. If > that's insufficient (because one doesn't want to rely on advisory), then one > really needs to utilize a complete e2e solution (which this Proto-XEP doesn't > offer). > > There are also MUC password concerns that a subscriber's server could grab it > and use it. But I note that this Proto-XEP solution doesn't adequately > defend against that threat as the remains downgrade and hijack attack vectors. > > So, I guess I ought to be looking at this more as a facility for operating > services requiring remote identity authentication. Okay, I can seem some > value in offering a solution to this, even one which doesn't protect against > downgrade and hijack attack. But then why the MUC password comparison? > Seems an apples to oranges comparison to me. > > -- Kurt I also note that there is an object level encryption proposal which could be used to protect MUC passwords. http://xmpp.org/internet-drafts/draft-miller-3923bis-02.html -- Kurt
Re: [Standards] Proposed XMPP Extension: Remote Authentication
On Dec 1, 2010, at 6:54 PM, XMPP Extensions Editor wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Remote Authentication > > Abstract: This document defines an XMPP protocol extension that enables > entities to use SASL for authentication with remote services (such as > Multi-User Chat rooms). > > URL: http://www.xmpp.org/extensions/inbox/remote-auth.html > > The XMPP Council will decide at its next meeting whether to accept this > proposal as an official XEP. > While I have no objection at present to this becoming a XEP, I have some concerns. It's not clear what exactly the problem is that this extension is trying to solve. It doesn't seem to be trying to generally solve how to provide secure communications between any two entities. It seems more focused on addressing the MUC password issues. I note that MUC passwords are not about identity authentication, so it's not clear to me why SASL, which is about identity authentication and channel protection, is applicable to this problem. Assuming this is about the MUC password issue, I note that the concern here has generally been that about eavesdroppers being about to discover the passwords (such as when C2S or S2S streams are not protected via TLS). To address this, I think the best answer is "use TLS, damn it". It might be useful to design an extension which advises the entity one provides a stanza to as to what the stanza should only be forwarded via protected channels. If that's insufficient (because one doesn't want to rely on advisory), then one really needs to utilize a complete e2e solution (which this Proto-XEP doesn't offer). There are also MUC password concerns that a subscriber's server could grab it and use it. But I note that this Proto-XEP solution doesn't adequately defend against that threat as the remains downgrade and hijack attack vectors. So, I guess I ought to be looking at this more as a facility for operating services requiring remote identity authentication. Okay, I can seem some value in offering a solution to this, even one which doesn't protect against downgrade and hijack attack. But then why the MUC password comparison? Seems an apples to oranges comparison to me. -- Kurt
Re: [Standards] Proposed XMPP Extension: Remote Authentication
On 12/2/10 8:18 AM, Waqas Hussain wrote: > On Thu, Dec 2, 2010 at 7:58 PM, Peter Saint-Andre wrote: > >> It would also be interesting to use certificate-based authentication. > > I've been very interested in certificate-based auth for clients > lately. S2S poses an issue for normal EXTERNAL auth for remote > clients. Me too. Let's get to work. :) Another idea: client auto-generates a cert for me and I register it with my server when I register an account (or after the first login). Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: Remote Authentication
On Thu, Dec 2, 2010 at 7:58 PM, Peter Saint-Andre wrote: > On 12/2/10 7:50 AM, Waqas Hussain wrote: >> On Thu, Dec 2, 2010 at 7:54 AM, XMPP Extensions Editor >> wrote: >>> The XMPP Extensions Editor has received a proposal for a new XEP. >>> >>> Title: Remote Authentication >>> >>> Abstract: This document defines an XMPP protocol extension that enables >>> entities to use SASL for authentication with remote services (such as >>> Multi-User Chat rooms). >>> >>> URL: http://www.xmpp.org/extensions/inbox/remote-auth.html >>> >>> The XMPP Council will decide at its next meeting whether to accept this >>> proposal as an official XEP. >>> >> >> Some comments: >> >> 1. The SASL mechanisms list can be sent back in the presence error, >> avoiding a round trip. > > Yeah, I wasn't sure whether to do that or not. My email to the jdev list > on this topic included the mechanisms in the presence error. I'm still > mulling it over, but you're right that it would save a round trip. I > wonder: can that model be generalized to other extensions? (Think > pubsub, gateways, etc.) > Various fun things come to mind. e.g., my client could authenticate with an MSN transport using some X-MSN SASL mechanism, and the transport never needs to know my password. (it can probably change the password once it's authenticated, but that's besides the point :) ) >> 2. The presence after authentication need not be sent. On successful >> auth, the initially sent presence can be used, avoiding a round trip. > > Good point -- and a good reason to include the SASL mechanisms in the > presence error. > >> 3. What the authentication identity looks like is undefined. I'm not >> sure if this is good or bad. > > I think it's bad. We need to fix that up. > >> 4. The error condition is 'sasl-required'. Does this imply that normal >> MUC password auth should fail, even with a correct password? > > What do you think? > > Because legacy MUC passwords are sent in the clear, a given MUC service > might not want to accept that other method, but in practice I think they > would for quite a while. I think allow. That is, if the client has already sent us a ***, there isn't much point in ignoring that and redoing auth. The damage is done already. >> And finally, an implementation: >> http://code.google.com/p/prosody-modules/source/browse/mod_saslauth_muc/mod_saslauth_muc.lua > > Cool. :) > >> The linked implementation works with Prosody trunk, and verifies that >> the user knows the room password. This would be far more interesting >> with some per-user credentials. > > Indeed. How to establish those? > > It would also be interesting to use certificate-based authentication. > I've been very interested in certificate-based auth for clients lately. S2S poses an issue for normal EXTERNAL auth for remote clients. >> How about something new instead of `> var='muc_passwordprotected'/>' to advertise SASL support. > > Yep, we need that. How about 'urn:ietf:params:xml:ns:xmpp-sasl'? If that > is not specific enough, we could define urn:xmpp:remote-auth as a > feature (but not an XML namespace). > > Peter > +1 to 'urn:ietf:params:xml:ns:xmpp-sasl' -- Waqas Hussain
Re: [Standards] Proposed XMPP Extension: Remote Authentication
On 12/2/10 8:12 AM, Kim Alvefur wrote: > On Thu, 2010-12-02 at 07:58 -0700, Peter Saint-Andre wrote: >> I wonder: can that model be generalized to other extensions? (Think >> pubsub, gateways, etc.) > >>> 4. The error condition is 'sasl-required'. Does this imply that >> normal MUC password auth should fail, even with a correct password? >> >> What do you think? >> >> Because legacy MUC passwords are sent in the clear, a given MUC >> service might not want to accept that other method, but in practice I >> think they would for quite a while. > > How about something new instead of ` var='muc_passwordprotected'/>' to advertise SASL support. Yep, we need that. How about 'urn:ietf:params:xml:ns:xmpp-sasl'? If that is not specific enough, we could define urn:xmpp:remote-auth as a feature (but not an XML namespace). Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: Remote Authentication
On Thu, 2010-12-02 at 07:58 -0700, Peter Saint-Andre wrote: > I wonder: can that model be generalized to other extensions? (Think > pubsub, gateways, etc.) > > 4. The error condition is 'sasl-required'. Does this imply that > normal MUC password auth should fail, even with a correct password? > > What do you think? > > Because legacy MUC passwords are sent in the clear, a given MUC > service might not want to accept that other method, but in practice I > think they would for quite a while. How about something new instead of `' to advertise SASL support. -- Kim Alvefur signature.asc Description: This is a digitally signed message part
Re: [Standards] Proposed XMPP Extension: Remote Authentication
On 12/2/10 7:50 AM, Waqas Hussain wrote: > On Thu, Dec 2, 2010 at 7:54 AM, XMPP Extensions Editor > wrote: >> The XMPP Extensions Editor has received a proposal for a new XEP. >> >> Title: Remote Authentication >> >> Abstract: This document defines an XMPP protocol extension that enables >> entities to use SASL for authentication with remote services (such as >> Multi-User Chat rooms). >> >> URL: http://www.xmpp.org/extensions/inbox/remote-auth.html >> >> The XMPP Council will decide at its next meeting whether to accept this >> proposal as an official XEP. >> > > Some comments: > > 1. The SASL mechanisms list can be sent back in the presence error, > avoiding a round trip. Yeah, I wasn't sure whether to do that or not. My email to the jdev list on this topic included the mechanisms in the presence error. I'm still mulling it over, but you're right that it would save a round trip. I wonder: can that model be generalized to other extensions? (Think pubsub, gateways, etc.) > 2. The presence after authentication need not be sent. On successful > auth, the initially sent presence can be used, avoiding a round trip. Good point -- and a good reason to include the SASL mechanisms in the presence error. > 3. What the authentication identity looks like is undefined. I'm not > sure if this is good or bad. I think it's bad. We need to fix that up. > 4. The error condition is 'sasl-required'. Does this imply that normal > MUC password auth should fail, even with a correct password? What do you think? Because legacy MUC passwords are sent in the clear, a given MUC service might not want to accept that other method, but in practice I think they would for quite a while. > And finally, an implementation: > http://code.google.com/p/prosody-modules/source/browse/mod_saslauth_muc/mod_saslauth_muc.lua Cool. :) > The linked implementation works with Prosody trunk, and verifies that > the user knows the room password. This would be far more interesting > with some per-user credentials. Indeed. How to establish those? It would also be interesting to use certificate-based authentication. Peter -- Peter Saint-Andre https://stpeter.im/ smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Proposed XMPP Extension: Remote Authentication
On Thu, Dec 2, 2010 at 7:54 AM, XMPP Extensions Editor wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Remote Authentication > > Abstract: This document defines an XMPP protocol extension that enables > entities to use SASL for authentication with remote services (such as > Multi-User Chat rooms). > > URL: http://www.xmpp.org/extensions/inbox/remote-auth.html > > The XMPP Council will decide at its next meeting whether to accept this > proposal as an official XEP. > Some comments: 1. The SASL mechanisms list can be sent back in the presence error, avoiding a round trip. 2. The presence after authentication need not be sent. On successful auth, the initially sent presence can be used, avoiding a round trip. 3. What the authentication identity looks like is undefined. I'm not sure if this is good or bad. 4. The error condition is 'sasl-required'. Does this imply that normal MUC password auth should fail, even with a correct password? And finally, an implementation: http://code.google.com/p/prosody-modules/source/browse/mod_saslauth_muc/mod_saslauth_muc.lua The linked implementation works with Prosody trunk, and verifies that the user knows the room password. This would be far more interesting with some per-user credentials. -- Waqas Hussain
[Standards] Proposed XMPP Extension: Remote Authentication
The XMPP Extensions Editor has received a proposal for a new XEP. Title: Remote Authentication Abstract: This document defines an XMPP protocol extension that enables entities to use SASL for authentication with remote services (such as Multi-User Chat rooms). URL: http://www.xmpp.org/extensions/inbox/remote-auth.html The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP.
