Re: [Standards] SASL EXTERNAL (XEP-0178) and client awkwardness

[Dave Cridland]

On Thu, Aug 15, 2013 at 8:47 PM, Thijs Alkemade  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

[Thijs Alkemade]

On 20 jun. 2013, at 05:14, Peter Saint-Andre  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 ?
> 
> 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

[Peter Saint-Andre]

-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 > > 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 ?

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

[Thijs Alkemade]

On 14 jun. 2013, at 23:10, Dave Cridland wrote:

> On Fri, Jun 14, 2013 at 9:23 PM, Thijs Alkemade  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 ?

Thijs

signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [Standards] SASL EXTERNAL (XEP-0178) and client awkwardness

[Dave Cridland]

On Fri, Jun 14, 2013 at 10:24 PM, Kurt Zeilenga wrote:

>
> On Jun 14, 2013, at 2:10 PM, Dave Cridland  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.

Re: [Standards] SASL EXTERNAL (XEP-0178) and client awkwardness

[Kurt Zeilenga]

On Jun 14, 2013, at 2:10 PM, Dave Cridland  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

[Kurt Zeilenga]

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  wrote:

> 
> 
> On Jun 14, 2013, at 1:23 PM, Thijs Alkemade  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

[Dave Cridland]

On Fri, Jun 14, 2013 at 9:23 PM, Thijs Alkemade  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

[Kurt Zeilenga]

On Jun 14, 2013, at 1:23 PM, Thijs Alkemade  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