Subject: [xmpp] Clarification of TLS Identity checking in draft-ietf-xmpp-3920bis

From: Stef Walter <[email-masked]>
Date: Mon, 14 Mar 2011 19:43:09 +0100

draft-ietf-xmpp-3920bis [1] refers to
draft-saintandre-tls-server-id-check [2] when it comes to TLS
certificate identity verification.

It appears to me that draft-ietf-xmpp-3920bis section 13.7.2.1 (and
possibly section 13.7.2.2) require further clarifications when it comes
to the reference identifiers that are to be used. The draft currently
specifies that the 'to' and 'from' attributes of the initial stream
header become reference identifiers used in certificate verification.

 1. What kind of reference identifiers are defined in section
    13.7.2.1. It seems that the 'to' attribute on the client side of
    a client-to-server connection should be used as two reference
    identifiers of type DNS-ID and CN-ID. If so, this should probably
    be noted specifically.

    It appears that the 'from' attribute used as an identity on the
    server side of a client-to-server connection, is used as a
    XmppAddr. Are there other ways to map this to a reference
    identifier? In either case, this should be noted.

 2. Section 3.2.3 'When Not to Use SRV' says that when a FQDN is
    explicitly configured it should be used in place of SRV lookups.
    It is not clear whether this explicitly specified FQDN should be
    used as a reference identity when verifying a certificate identity.

    This is explicitly user selected or configured information and
    therefore is available to be used as input to build the list of
    reference identifiers.

    A real example of this often occurs with the Google Apps hosted
    XMPP servers. The users explicitly configure the server as
    talk.google.com [3].

    Should the explicitly configured FQDN be used in place of the
    section 13.7.2.1 XMPP reference identifier(s), or in addition to
    them? Either way, this should be clear in the spec.

    Using multiple reference identifiers of the same type is not
    forbidden by draft-saintandre-tls-server-id-check. So this
    alternative shouldn't be dismissed out of hand.

Thanks for considering these issues (or helping set me straight :)

Cheers,

Stef

[1] http://tools.ietf.org/html/draft-ietf-xmpp-3920bis-22

[2] http://tools.ietf.org/html/draft-saintandre-tls-server-id-check-14

[3] http://www.google.com/support/a/bin/answer.py?answer=49147

---

From: Florian Zeitz <[email-masked]>
Date: Mon, 14 Mar 2011 23:38:58 +0100

> header become reference identifiers used in certificate verification.
Let me start by saying that I think you're mostly right on the following 
points, however it's rather unfortunate we are having this discussion 
this late in the process.

>      identifiers of type DNS-ID and CN-ID. If so, this should probably
I think there are 2 things in the draft that are actually wrong-ish:
a) It currently says "The initiating entity sets its reference 
identifier to the 'to' address it communicates in the initial stream 
header". I think that is somewhat backwards. The initiating entity does 
not choose the domain to construct reference identifiers from based on 
the 'to' attribute that it set, but it sets the 'to' attribute based on 
the same domain it bases the reference identifiers of.

b) I don't think the draft means "reference identifier" here. I think 
what it actually is talking about is the "source domain" that it will 
base reference identifiers of. I think once that is clarified the rules 
for building a list of reference identifiers that are in 
draft-saintandre-tls-server-id are sufficient.

>      alternative shouldn't be dismissed out of hand.
I was recently wondering something related.
Do I set the 'to' attribute in the initial stream header to the JID's 
domainpart, or to the domain I got from a SRV lookup?
The later is certainly not sufficient as a source domain. That in turn 
implies (IMHO) we will always have/want to set the 'to' attribute to the 
JID's domainpart (and while the draft actually says to put a 
"domainpart" there, it is not specific on where to get that from, 
especially for the cases where you can't set a 'from', because you don't 
know the JID beforehand). I'd therefore assume you'd not use the 
user-entered FQDN as source domain, but I'd like some clarification on 
that point, too.

--
Florian Zeitz

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 14 Mar 2011 17:01:13 -0600

> this late in the process.

It is rather late, but not too late for small fixes of the kind that can
be made (with AD approval) during "AUTH48":

http://www.rfc-editor.org/pubprocess.html#auth48

> the same domain it bases the reference identifiers of.

I don't see a real difference between those two things.

> draft-saintandre-tls-server-id are sufficient.

I think that's right, and changing "reference identifier" to "source
domain" is a relatively small fix. The rules about reference identifiers
are provided in Section 13.7.1.2.1.

>>      identifier? In either case, this should be noted.

I don't quite understand the question.

> domainpart, or to the domain I got from a SRV lookup?

The former.

Let's say you're trying to get to example.com ( = source domain) and the
result of the SRV lookup is cm8962.example.com ( = target domain). The
'to' address will be example.com, not the address of the connection manager.

> user-entered FQDN as source domain, but I'd like some clarification on

Here again I don't understand the concern.

Let's say a connected client generates a stanza for sending to
[email-masked]. The server strips off the localpart, throws away the
at-sign, and thus has montague.net as the domain to which it will try to
connect (i.e., perform FQDN resolution to get an IP address etc.).
That's the domainpart the server derives from the stanza's 'to' address.
Seems pretty straightforward to me, but perhaps it's not spelled out in
exactly that many words.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Joe Hildebrand <[email-masked]>
Date: Mon, 14 Mar 2011 17:07:56 -0600

> user-entered FQDN as source domain, but I'd like some clarification on

It's always the domain name the user entered, not something you get from the
(currently untrusted) DNS.  Many servers use this name to figure out which
certificate to give you when you Start-TLS, rather than having to rely on
SNI.

-- 
Joe Hildebrand

---

From: Florian Zeitz <[email-masked]>
Date: Tue, 15 Mar 2011 00:19:51 +0100

Am 15.03.2011 00:07, schrieb Joe Hildebrand:
> On 3/14/11 4:38 PM, "Florian Zeitz"<[email-masked]>  wrote:
>
>
That is not a sufficient answer.
Stef Walter's point, that I was trying to address, was that in some 
cases the user entered two different domains. One as part of his JID the 
other one as the domain to connect to.
Both are certainly valid options for checking against.
My reasoning was that since you have to use the domainpart of the JID 
when doing SRV (I was not sure from reading the draft, but it seemed 
sensible), it seems logical to do the same when the user specified a FQDN.

--
Florian Zeitz

---

From: Florian Zeitz <[email-masked]>
Date: Tue, 15 Mar 2011 00:30:45 +0100

> I don't see a real difference between those two things.
It's really not a big deal. Basically currently it says that the 'to' 
attribute is said from the user input and the source domain is then set 
from the 'to' attribute. That seems like a strange layer of indirection, 
but I can certainly live with it.

> are provided in Section 13.7.1.2.1.
I had hoped for that ;)

> Seems pretty straightforward to me, but perhaps it's not spelled out in
I think that example only applies to S2S connections, right?
Specifically I'm wondering:
If a client connects to a server, just knowing the domain to connect to, 
but not the users JID what does it put as the 'to' attribute?
Depending on the answer to Stef Walter's original question that might be 
trivial to answer or not, it's either that very domain, or a domainpart 
that is not actually known to the client.

--
Florian Zeitz

---

From: Justin Karneges <[email-masked]>
Date: Mon, 14 Mar 2011 17:35:48 -0700

> that is not actually known to the client.

It's not trivial to answer.  XMPP was designed to allow for virtual hosting.  
A physical server being connected to could potentially host many domains, and 
so you need to tell it which domain you are interested in.  XMPP also doesn't 
have the concept of a default domain (other than some edge cases around error 
handling).

Justin

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 14 Mar 2011 20:41:12 -0600

> other one as the domain to connect to.

I think you mean the kind of thing that is explained, in depth, in
draft-saintandre-tls-server-id-check. I encourage anyone who has
questions about these matters to please re-read that spec, because it
discusses these matters in great detail.

So yes, it is true that in some circumstances a user might configure his
IM client with two things:

1. The domain name of the application service, which is the domainpart
of his JID, such as [email-masked] => montague.lit; this is the
"source domain".

2. A "hardcoded" hostname that he has explicitly assocated with the
domainpart of your JID, such as apps.shakespeare.lit; this is the
"target domain".

However, for the purposes of checking the identity of the application
service when connecting via TLS, Romeo's client would check to see that
the service presents a certificate that says it is "montague.lit"
(unless he overrides the checks or explicitly approve of connecting to
"apps.shakesepeare.lit").

Please understand that 99% of users will never see such a configuration
option and that they don't know anything about apps.shakespeare.lit or
some special hostname that they're connecting to -- all that they know
is that they're trying to connect to montague.lit (if they even know
this, because lots of people just think that they're trying to connect
to "Shakespeare" or even "that IM thing" -- if you doubt it, I recommend
that you run your own public IM service, because it can be quite
enlightening).

> Both are certainly valid options for checking against.

Are they? From a user perspective, is montague.lit (the source domain)
just as valid as apps.shakespeare.lit (the target domain)? Does the
typical user understand that kind of delegation arrangement? Again, I
suggest that they don't.

> sensible), 

What else would you use?

> it seems logical to do the same when the user specified a FQDN.

In this case, if Romeo has explicitly approved of connecting to
apps.shakespeare.lit then he has "pinned" the certificate to that
domain, in which case it's fine for the server to check that identity in
addition to "montague.lit". However, in general this is not a good idea
because very few users understand the implications of such a configuration.

In any case, nothing in this message requires any changes to either
draft-ietf-xmpp-3920bis or draft-saintandre-tls-server-id-check.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 14 Mar 2011 21:03:40 -0600

Sorry, I was in a hurry earlier. I've had another look at this now that
I have a bit more time...

> but I can certainly live with it.

In fact I think it's right as it is. Here's why:

1. First the initiating entity opens a stream to the receiving entity.
There is no security interaction yet.

2. The parties decide to negotiate TLS. Now the initiating entity
establishes its set of reference identifiers based on the source domain.

>> are provided in Section 13.7.1.2.1.

The right fix is:

   The initiating entity sets the source domain of its reference
                              ^^^^^^^^^^^^^^^^^^^^
   identifier to the 'to' address it communicates in the initial
   stream header...

> I think that example only applies to S2S connections, right?

Yes.

> but not the users JID what does it put as the 'to' attribute?

I'm still confused. What do you mean by "the client does not know the
user's JID"?

Except in rare kinds of deployments that we don't care about in this
discussion (e.g., where the localpart of the user's JID is determined by
some kind of lookup process based on information in a client
certificate), the client is always going to know that the user has, say,
an account of "romeo" at the domain "montague.lit".

> that is not actually known to the client.

The client needs to know the domainpart of the user's bare JID if it
going to act on the user's behalf. It's as simple as that (except for
the rare deployments I mentioned above).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 14 Mar 2011 21:15:53 -0600

>    The initiating entity sets the source domain of its reference

Sorry, one more slight correction: "the source domain of its reference
identifiers" (in the plural) because the initiating entity might have
multiple reference identifiers (dNSName, SRVName, etc.).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Florian Zeitz <[email-masked]>
Date: Tue, 15 Mar 2011 21:28:10 +0100

> that you run your own public IM service, because it can be quite
I agree this is the way to do it, having read the relevant bits again 
after some sleep I also agree it's clear from the draft(s), sorry about 
that.

> typical user understand that kind of delegation arrangement? Again, I
Usually this configuration is labeled something like "Connect to 
different server: Host: Port:".
I personally do expect some percentage of users to be confused by the 
fact that a client tries to verify motague.lit when explicitly told to 
connect to apps.shakespeare.lit. But that will also happen when trying 
to verify apps.shakespeare.lit while the domainpart is montague.lit, so 
that's not a solvable "issue".
It just needs to be clear which method is correct, which it is. Again 
sorry about that.

>> when doing SRV (I was not sure from reading the draft, but it seemed
The SRV lookup's result, which I consider functionally equivalent to the 
user specifing a separate host to connect to.
And yes I *do* realize that would be an utterly stupid choice, that is 
why the "have to" is there.

---

From: Florian Zeitz <[email-masked]>
Date: Tue, 15 Mar 2011 21:41:04 +0100

> establishes its set of reference identifiers based on the source domain.
Which means (AFAICT) the initiating entity sets the 'to' attribute baed 
on the source domain, and then later builds the reference identifiers 
from the source domain.
That is slightly (as in nitpick) different from what the draft says.

> the rare deployments I mentioned above).
Is that correctly summarized as: "That is a rare case in which the value 
of the 'to' attribute is considered to be a local matter of the 
deployment." ? (And to be clear, I'm fine with that)

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 15 Mar 2011 14:45:51 -0600

> That is slightly (as in nitpick) different from what the draft says.

That is indeed a subtle nitpick. If there is no effective difference
(and I don't think there is), I'd prefer leaving the spec as-is.

> deployment." ? (And to be clear, I'm fine with that)

Well it's not even that -- the rare case is when my client doesn't know
my username, i.e., it knows the domain name of the service (and
therefore what it will put in the 'to' address of the stream header) but
it doesn't know the what localpart the service will assign to me (based
on information in the client certificate I present).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Florian Zeitz <[email-masked]>
Date: Tue, 15 Mar 2011 21:59:25 +0100

> multiple reference identifiers (dNSName, SRVName, etc.).
Sounds fine to me.

--
Florian Zeitz

---

From: Stef Walter <[email-masked]>
Date: Wed, 16 Mar 2011 10:04:18 +0100

>    The initiating entity sets the source domain of its reference

Great. That makes it clearer.

Stef

---

From: Stef Walter <[email-masked]>
Date: Wed, 16 Mar 2011 10:40:00 +0100

Hmmm, thunderbird hid this thread inside of an unrelated one :/

> that you run your own public IM service, because it can be quite

Sadly this isn't a corner case. It's the case with widely deployed XMPP
systems such as Google talk, which uses virtual hosting extensively as
part of google apps. And it seems that many XMPP clients take a
"hardcoded" or configured hostname into account when verifying the
certificate.

The Google Talk certificate does not contain the domainpart of the JID
at all, and contains the "hardcoded" hostname instead. In this setup
there are tens of thousands of different XMPP domains all using the same
certificate.

This may seem strange, broken or annoying but represents a massive
deployment. So it turns out that far more users than you might expect
will see such a configuration option, and will see these certificate
warnings.

>From a security perspective the hardcoded or configured hostname is user
input and can be used in identity checks. So client app developers have
two options:

 * Throwing up a "cop out" certificate dialog and tossing the entire
   security decision in the lap of the user.

 * Using all the user's input (not just the JID) to generate reference
   identifiers to use to verify the certificate.

If these were corner cases, and 99% of users would never run into this,
then I'd tend to agree with you, but this is a widely deployed
configuration on virtually hosted XMPP servers.

Cheers,

Stef

---

From: Kevin Smith <[email-masked]>
Date: Wed, 16 Mar 2011 09:44:25 +0000

> configuration on virtually hosted XMPP servers.

This is mixing two ideas - yes, GTalk has many many hosted domains and
isn't presenting 'valid' certificates for them. However, in none of
these cases should the user be specifying a hard-coded hostname - that
just implies that their DNS setup is broken.

Virtual hosting - common
Manually specifying connection hosts - rare.

/K

---

From: Stef Walter <[email-masked]>
Date: Wed, 16 Mar 2011 11:07:08 +0100

> Manually specifying connection hosts - rare.

I wish it was rare, but all the documentation that users follow to setup
their Google Talk accounts talk about manually specifying the connection
host:

http://www.google.com/support/talk/bin/answer.py?answer=24076
http://www.google.com/support/talk/bin/answer.py?hl=en&answer=24073
http://www.google.com/support/talk/bin/answer.py?hl=en&answer=24074
... and so on ...

Also in many clients the user selects 'Google Talk' as the type of
account, and therefore the client knows that the client is expecting to
connecting to talk.google.com and the client manually uses this as a
reference identifier.

I'm not holding this up as some example of a sane setup. But using
additional user input as reference identifiers is a pragmatic solution
to something that a large amount of users bump into when using XMPP + TLS.

I guess I'm okay with just leaving this annoying situation unspecified
in the RFC, and hopefully it'll go away in the future once things like
SNI is better supported, and service providers with virtual hosting get
their act together.

Until then clients meanwhile will probably continue to use the manually
specified server and user selection as a way to check certificate
identities and not follow the RFC too closely in this regard.

Cheers,

Stef