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

Florian Zeitz <florob@babelmonkeys.de> Tue, 15 March 2011 20:39 UTC

Return-Path: <florob@babelmonkeys.de>
X-Original-To: xmpp@core3.amsl.com
Delivered-To: xmpp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B80BA3A6B45 for <xmpp@core3.amsl.com>; Tue, 15 Mar 2011 13:39:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKkgo558IcqQ for <xmpp@core3.amsl.com>; Tue, 15 Mar 2011 13:39:44 -0700 (PDT)
Received: from babelmonkeys.de (v64231.topnetworks.de [82.197.159.233]) by core3.amsl.com (Postfix) with ESMTP id C28A43A6A2D for <xmpp@ietf.org>; Tue, 15 Mar 2011 13:39:44 -0700 (PDT)
Received: from xdsl-87-79-189-17.netcologne.de ([87.79.189.17] helo=[192.168.234.167]) by babelmonkeys.de with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <florob@babelmonkeys.de>) id 1Pzb3F-000267-US for xmpp@ietf.org; Tue, 15 Mar 2011 21:41:10 +0100
Message-ID: <4D7FCEE0.5070504@babelmonkeys.de>
Date: Tue, 15 Mar 2011 21:41:04 +0100
From: Florian Zeitz <florob@babelmonkeys.de>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110307 Lanikai/3.1.9
MIME-Version: 1.0
To: xmpp@ietf.org
References: <4D7E61BD.50804@collabora.co.uk> <4D7E9902.4020908@babelmonkeys.de> <4D7E9E39.4030900@stpeter.im> <4D7EA525.4050207@babelmonkeys.de> <4D7ED70C.7070708@stpeter.im>
In-Reply-To: <4D7ED70C.7070708@stpeter.im>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [xmpp] Clarification of TLS Identity checking in draft-ietf-xmpp-3920bis
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xmpp>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Mar 2011 20:39:45 -0000

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.

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