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

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

On 3/15/11 2:41 PM, Florian Zeitz wrote:
> Am 15.03.2011 04:03, schrieb Peter Saint-Andre:
>> On 3/14/11 5:30 PM, Florian Zeitz wrote:
>>> Am 15.03.2011 00:01, schrieb Peter Saint-Andre:
>>>> On 3/14/11 4:38 PM, Florian Zeitz wrote:
>>>>> 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.
>>>>
>>> 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.
>>
>> 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.
>>
> 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.

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.

>>> 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?
>>
>> 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".
>>
>>> 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.
>>
>> 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).
>>
> 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)

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/