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

[Peter Saint-Andre <[e-mail]>]

On 3/14/11 4:38 PM, Florian Zeitz wrote:
> Am 14.03.2011 19:43, schrieb Stef Walter:
>> 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.
>>
> 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.

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

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

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

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

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.

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

I don't quite understand the question.

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

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

Here again I don't understand the concern.

Let's say a connected client generates a stanza for sending to
[e-mail]. 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/