Re: [Standards] SASL EXTERNAL (XEP-0178) and client awkwardness
On 20 jun. 2013, at 05:14, Peter Saint-Andre stpe...@stpeter.im wrote: So when we wrote XEP-0178 this was fairly vague, but the upshot is that it probably needs some revision: 1) The right way to specify the jid you're expecting to become is by using the from attribute of the stream. This is most especially true for servers. I'm still not sure I understand 10(c), though. Does the address specified during SASL negotiation refer to the from attribute on the stream? IMHO that would indeed be the 'from' on the initial stream header. It would be good to clear that up in the spec, eh? Peter There's one more point I want to make about this, not exactly related, but close enough to continue this thread. The security considerations section of XEP-0178 states only: This document introduces no security considerations or concerns above and beyond those discussed in RFC 6120 and RFC 6125. While that may be true, there's one thing that might warrant some emphasis: Both the server's and the client's certificate are sent in plain during the handshake. This means that any id-on-xmppAddr attribute, common name field or any other personal info on the certificate will be visible to any passive observer of the stream. Every client I've used tries to avoid leaking your identity before TLS is active (no 'from' attribute on the initial stream) and this could break that. Even when a user is using a certificate with no personally identifiable information at all, just by looking at the public key an observer could try to correlate different connections to the same account. In RFC 6120, §5.1.3 point 3 this is covered this by mentioning TLS renegotiation as a way to protect the client's certificate if it's known to be private. I guess this would work, though I'm not sure how well-supported that is. I think it would be good if XEP-0178 at least mentioned that the certificate is sent in plain and pointed to §5.1.3 for a workaround. Regards, Thijs signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Standards] SASL EXTERNAL (XEP-0178) and client awkwardness
On Thu, Aug 15, 2013 at 8:47 PM, Thijs Alkemade th...@xnyhps.nl wrote: Both the server's and the client's certificate are sent in plain during the handshake. This means that any id-on-xmppAddr attribute, common name field or any other personal info on the certificate will be visible to any passive observer of the stream. Every client I've used tries to avoid leaking your identity before TLS is active (no 'from' attribute on the initial stream) and this could break that. Even when a user is using a certificate with no personally identifiable information at all, just by looking at the public key an observer could try to correlate different connections to the same account. Yes, but I don't think that's a particular point in mind with XEP-0178, or indeed XMPP in general. In RFC 6120, §5.1.3 point 3 this is covered this by mentioning TLS renegotiation as a way to protect the client's certificate if it's known to be private. I guess this would work, though I'm not sure how well-supported that is. Hmmm... I know at least some implementations might struggle. You'd have two negotiations, and you'd have to hope that the server looked at the one you wanted. I think it would be good if XEP-0178 at least mentioned that the certificate is sent in plain and pointed to §5.1.3 for a workaround. I'd much rather we investigated the practical implications - '178 is intended as best practice, so it'd be nice to know it worked.
Re: [Standards] SASL EXTERNAL (XEP-0178) and client awkwardness
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/15/13 4:05 AM, Thijs Alkemade wrote: On 14 jun. 2013, at 23:10, Dave Cridland wrote: On Fri, Jun 14, 2013 at 9:23 PM, Thijs Alkemade th...@xnyhps.nl mailto:th...@xnyhps.nl wrote: I don't see any possible downside to the client always sending its desired authzid, except for maybe ~20 characters of extra data. The server can still do the same checking. I propose clients SHOULD send an authzid, except in case the certificate contains exactly one xmppAddr field, in which case they MAY omit the authzid and send =. Here's some history for you. Once upon a time, various people noticed that IMAP had only a simple LOGIN command, and wanted to make a challenge-response based login. Because they thought that maybe other ideas might come up in the future, they made a generalized AUTHENTICATE command, which supported multiple mechanisms. This is where SASL came from, and explains why many mechanisms are distinctly text-flavoured (even though IMAP base64's them in order to handle those that aren't). Some protocols - most notably Kerberos, but also Digest-MD5 - had an extra slot aside from the login name, which was used for what's known as proxy authentication - that is, logging in as someone else's proxy. It was basically an assertion that this other guy was letting you login as them. So you'd use your principal, or login name (now Authentication Identifier) and password, but you'd ask to be logged in as somebody else - the Authorization Identifier. Obviously if the same name was used in both places, this was the same as not requesting Proxy Auth. As SASL became genericised for multiple protocols, this shifted slightly, and two things happened: a) The Authorization Identifier became protocol-specific, whereas the Authentication Identifier became mechanism-specific. In IMAP, this had made little difference, as IMAP doesn't even have a native format, but for other protocols, like XMPP and LDAP, it does. b) *Any* Authorization Identifier officially means you're trying to do Proxy Auth. Thanks for clearing that up, the lack of an authcid in this XEP confused me. So when we wrote XEP-0178 this was fairly vague, but the upshot is that it probably needs some revision: 1) The right way to specify the jid you're expecting to become is by using the from attribute of the stream. This is most especially true for servers. I'm still not sure I understand 10(c), though. Does the address specified during SASL negotiation refer to the from attribute on the stream? IMHO that would indeed be the 'from' on the initial stream header. It would be good to clear that up in the spec, eh? Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRwnOwAAoJEOoGpJErxa2puPcP/1hDb4OCuZ+nfc440k6PZ8EA JAX0rhgbDKpOWO1IkSdud62xszt27mX7MRflzDaATDBWE/0RilubGu8XIkAzU5Bc 01rGVDEse0P9K6LaHpgJ0ViQumDNG8tclxrZF6lN/mePaTfwqrflR9z+vcMyhXPC fNwNkUrDG0Ufpx2/PsFz21Z0rfMIuCxEYbUAm2nBAYuhTAdNM40SexN/vxx4nycf TWvDQNXH1V5DGyW7KWPyyuD0q6Cmhuz5Igfet1fBAKX0/JW1MMKWqkv0fhZewZaz 4CdwmCc9SEd5bDV7xtprtQIi4OO19BEpU5TNfcCXN5m/YyOV+TSbu0vHY5obX2ud RCo2ow8ifkTNKsPkFG2Yfg9i3QFD+9FOVEflQFBQV221prlquFZqrzakSoB5uOVH xlJ5+0pQO1+8szM2k3nDkYxPEPa5BO0oeg8vaz3ryWoZ0p84quRmKiHUbVwrMaBh ffxeaEZKfXPGFv8h2+2G773VOvfY5YfQ5PePIUBA7JTlh/CMPRIgq4xcNElAyzBf TBilPkz+lIsXpUAiEs8+a+pFq83DVtRLR8V8FbxEMSFDakXQYoB1Tq73YO46iuRL EHtJhYgBMdsVl1sX5b7BQnP4YCS4h5kf9oq2d+mmtXwGQQCX0DHLjANKG8Awhxvv A4MWhaI6LVbxSfQgwJcn =5IYc -END PGP SIGNATURE-
Re: [Standards] SASL EXTERNAL (XEP-0178) and client awkwardness
On 14 jun. 2013, at 23:10, Dave Cridland wrote: On Fri, Jun 14, 2013 at 9:23 PM, Thijs Alkemade th...@xnyhps.nl wrote: I don't see any possible downside to the client always sending its desired authzid, except for maybe ~20 characters of extra data. The server can still do the same checking. I propose clients SHOULD send an authzid, except in case the certificate contains exactly one xmppAddr field, in which case they MAY omit the authzid and send =. Here's some history for you. Once upon a time, various people noticed that IMAP had only a simple LOGIN command, and wanted to make a challenge-response based login. Because they thought that maybe other ideas might come up in the future, they made a generalized AUTHENTICATE command, which supported multiple mechanisms. This is where SASL came from, and explains why many mechanisms are distinctly text-flavoured (even though IMAP base64's them in order to handle those that aren't). Some protocols - most notably Kerberos, but also Digest-MD5 - had an extra slot aside from the login name, which was used for what's known as proxy authentication - that is, logging in as someone else's proxy. It was basically an assertion that this other guy was letting you login as them. So you'd use your principal, or login name (now Authentication Identifier) and password, but you'd ask to be logged in as somebody else - the Authorization Identifier. Obviously if the same name was used in both places, this was the same as not requesting Proxy Auth. As SASL became genericised for multiple protocols, this shifted slightly, and two things happened: a) The Authorization Identifier became protocol-specific, whereas the Authentication Identifier became mechanism-specific. In IMAP, this had made little difference, as IMAP doesn't even have a native format, but for other protocols, like XMPP and LDAP, it does. b) *Any* Authorization Identifier officially means you're trying to do Proxy Auth. Thanks for clearing that up, the lack of an authcid in this XEP confused me. So when we wrote XEP-0178 this was fairly vague, but the upshot is that it probably needs some revision: 1) The right way to specify the jid you're expecting to become is by using the from attribute of the stream. This is most especially true for servers. I'm still not sure I understand 10(c), though. Does the address specified during SASL negotiation refer to the from attribute on the stream? Thijs signature.asc Description: Message signed with OpenPGP using GPGMail
[Standards] SASL EXTERNAL (XEP-0178) and client awkwardness
Hello! While working on XEP-0178 and XEP-0257 support, I noticed XEP-0178 makes the distinction between 3 possible scenarios: the certificate contains one, more than one or zero xmppAddr fields. Depending on the scenario and the authzid the client wants to use the client must either include the authzid or use =. This is the only reason the client would need to understand the certificate for the user, which increases complexity for a client. The server still needs to parse the certificate as well, as it needs to validate what the client sends. I don't see any possible downside to the client always sending its desired authzid, except for maybe ~20 characters of extra data. The server can still do the same checking. I propose clients SHOULD send an authzid, except in case the certificate contains exactly one xmppAddr field, in which case they MAY omit the authzid and send =. Aside from this, I think the following line from 10(c) is self-contradictory: only if it desires to be authorized as a JID other than the address specified during SASL negotiation. This _is_ the SASL negotiation, unless I'm missing something this is where an authcid needs to be sent. I don't understand where the client would communicate its desired JID if it uses a certificate with zero xmppAddr fields and sends =. Regards, Thijs signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Standards] SASL EXTERNAL (XEP-0178) and client awkwardness
On Jun 14, 2013, at 1:23 PM, Thijs Alkemade th...@xnyhps.nl wrote: Hello! While working on XEP-0178 and XEP-0257 support, I noticed XEP-0178 makes the distinction between 3 possible scenarios: the certificate contains one, more than one or zero xmppAddr fields. Depending on the scenario and the authzid the client wants to use the client must either include the authzid or use =. IMO... Unless the user desires to assume the identity of another user, the authzid should be empty. If the user simply wants to use their cert (or one of their certs), the user should just use it. The server should be capable of figuring out what JID is associated with the user's certificate. I note that in many deployments this involves various mappings and SANS other than xmppAddr. This is the only reason the client would need to understand the certificate for the user, which increases complexity for a client. No need for the client to parse SANs out of the user's certificate. Just use it and assert no authzid. The server still needs to parse the certificate as well, as it needs to validate what the client sends. Yes. And more to the point... the client should not guess at what JID the server might associate with the cert. I don't see any possible downside to the client always sending its desired authzid, except for maybe ~20 characters of extra data. Because the server might associate a JID other than what the client thinks ought to be associated, a JID for which the user might not have wanted to assume the identity of. The server can still do the same checking. I propose clients SHOULD send an authzid, except in case the certificate contains exactly one xmppAddr field, in which case they MAY omit the authzid and send =. Again, authzid is for identity assumption... Aside from this, I think the following line from 10(c) is self-contradictory: only if it desires to be authorized as a JID other than the address specified during SASL negotiation. This _is_ the SASL negotiation, unless I'm missing something this is where an authcid needs to be sent. The server determines the user JID from the credentials, in the case of EXTERNAL, from a certificate or other lower level credential. Even in PLAIN, the server is free to drive a JID from PLAIN's credentials. Don't assume SASL authcid == user's JID. I don't understand where the client would communicate its desired JID if it uses a certificate with zero xmppAddr fields and sends =. The client doesn't communicate the user's JID. It communicates the user's credentials which then the server uses to determine the user's JID. -- Kurt Regards, Thijs
Re: [Standards] SASL EXTERNAL (XEP-0178) and client awkwardness
On Fri, Jun 14, 2013 at 9:23 PM, Thijs Alkemade th...@xnyhps.nl wrote: I don't see any possible downside to the client always sending its desired authzid, except for maybe ~20 characters of extra data. The server can still do the same checking. I propose clients SHOULD send an authzid, except in case the certificate contains exactly one xmppAddr field, in which case they MAY omit the authzid and send =. Here's some history for you. Once upon a time, various people noticed that IMAP had only a simple LOGIN command, and wanted to make a challenge-response based login. Because they thought that maybe other ideas might come up in the future, they made a generalized AUTHENTICATE command, which supported multiple mechanisms. This is where SASL came from, and explains why many mechanisms are distinctly text-flavoured (even though IMAP base64's them in order to handle those that aren't). Some protocols - most notably Kerberos, but also Digest-MD5 - had an extra slot aside from the login name, which was used for what's known as proxy authentication - that is, logging in as someone else's proxy. It was basically an assertion that this other guy was letting you login as them. So you'd use your principal, or login name (now Authentication Identifier) and password, but you'd ask to be logged in as somebody else - the Authorization Identifier. Obviously if the same name was used in both places, this was the same as not requesting Proxy Auth. As SASL became genericised for multiple protocols, this shifted slightly, and two things happened: a) The Authorization Identifier became protocol-specific, whereas the Authentication Identifier became mechanism-specific. In IMAP, this had made little difference, as IMAP doesn't even have a native format, but for other protocols, like XMPP and LDAP, it does. b) *Any* Authorization Identifier officially means you're trying to do Proxy Auth. So when we wrote XEP-0178 this was fairly vague, but the upshot is that it probably needs some revision: 1) The right way to specify the jid you're expecting to become is by using the from attribute of the stream. This is most especially true for servers. 2) As far as I'm aware, all servers will handle you specifying it as the Authorization Identifier as well, even if the certificate is unambiguous. 3) Not specifying it anywhere will probably be OK. You don't know how the server will map the certificate anyway. 4) The client should know how to find a jid from a certificate, otherwise it can't validate the server's certificate... So a sane UI will be doing this anyway. Dave.
Re: [Standards] SASL EXTERNAL (XEP-0178) and client awkwardness
Basically, my recommendation is, clients should generally not assert an authzid. The exception is when the user specifically requests the client to do so, whether for identity assumption or to authenticate to some server which might use it to select between multiple possible accounts for the same credentials. The client SHOULD NOT attempt to guess what JID the server will associate with a particular credential, whether a X.509 certificate or something else. -- Kurt On Jun 14, 2013, at 2:02 PM, Kurt Zeilenga kurt.zeile...@isode.com wrote: On Jun 14, 2013, at 1:23 PM, Thijs Alkemade th...@xnyhps.nl wrote: Hello! While working on XEP-0178 and XEP-0257 support, I noticed XEP-0178 makes the distinction between 3 possible scenarios: the certificate contains one, more than one or zero xmppAddr fields. Depending on the scenario and the authzid the client wants to use the client must either include the authzid or use =. IMO... Unless the user desires to assume the identity of another user, the authzid should be empty. If the user simply wants to use their cert (or one of their certs), the user should just use it. The server should be capable of figuring out what JID is associated with the user's certificate. I note that in many deployments this involves various mappings and SANS other than xmppAddr. This is the only reason the client would need to understand the certificate for the user, which increases complexity for a client. No need for the client to parse SANs out of the user's certificate. Just use it and assert no authzid. The server still needs to parse the certificate as well, as it needs to validate what the client sends. Yes. And more to the point... the client should not guess at what JID the server might associate with the cert. I don't see any possible downside to the client always sending its desired authzid, except for maybe ~20 characters of extra data. Because the server might associate a JID other than what the client thinks ought to be associated, a JID for which the user might not have wanted to assume the identity of. The server can still do the same checking. I propose clients SHOULD send an authzid, except in case the certificate contains exactly one xmppAddr field, in which case they MAY omit the authzid and send =. Again, authzid is for identity assumption... Aside from this, I think the following line from 10(c) is self-contradictory: only if it desires to be authorized as a JID other than the address specified during SASL negotiation. This _is_ the SASL negotiation, unless I'm missing something this is where an authcid needs to be sent. The server determines the user JID from the credentials, in the case of EXTERNAL, from a certificate or other lower level credential. Even in PLAIN, the server is free to drive a JID from PLAIN's credentials. Don't assume SASL authcid == user's JID. I don't understand where the client would communicate its desired JID if it uses a certificate with zero xmppAddr fields and sends =. The client doesn't communicate the user's JID. It communicates the user's credentials which then the server uses to determine the user's JID. -- Kurt Regards, Thijs
Re: [Standards] SASL EXTERNAL (XEP-0178) and client awkwardness
On Jun 14, 2013, at 2:10 PM, Dave Cridland d...@cridland.net wrote: Obviously if the same name was used in both places, this was the same as not requesting Proxy Auth. Actually, not necessarily so. Note the even where the credentials do contain an authzid, it's in the mechanism's name space whereas the authzid is in the application's namespace. For instance, I can login as kurt in PLAIN but have a JID of kurt.zeile...@isode.com. (This is a real example.)
Re: [Standards] SASL EXTERNAL (XEP-0178) and client awkwardness
On Fri, Jun 14, 2013 at 10:24 PM, Kurt Zeilenga kurt.zeile...@isode.comwrote: On Jun 14, 2013, at 2:10 PM, Dave Cridland d...@cridland.net wrote: Obviously if the same name was used in both places, this was the same as not requesting Proxy Auth. Actually, not necessarily so. Note the even where the credentials do contain an authzid, it's in the mechanism's name space whereas the authzid is in the application's namespace. For instance, I can login as kurt in PLAIN but have a JID of kurt.zeile...@isode.com. (This is a real example.) I did say that was the case originally, before it was genericised into SASL. I'm actually paraphrasing Mark Crispin here, as it happens. Because of my (a), it's meant that instead of empty meaning use my authenticaiton identifier, it now means use the default authorization identifier derived from the authentication identifier, indeed. Dave.
