Re: [secdir] [xmpp] SecDir review of draft-ietf-xmpp-3920bis-17

Yaron Sheffer <yaronf.ietf@gmail.com> Thu, 04 November 2010 16:02 UTC

Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 025F13A6927; Thu, 4 Nov 2010 09:02:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 Jk1kJz3EexQA; Thu, 4 Nov 2010 09:02:24 -0700 (PDT)
Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id AA37E3A6848; Thu, 4 Nov 2010 09:02:23 -0700 (PDT)
Received: by gwb15 with SMTP id 15so1619625gwb.31 for <multiple recipients>; Thu, 04 Nov 2010 09:02:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=zTkd5/6R8ztF9mUl78ebkTyDcekzX/TctEqMneKn/LE=; b=xXVxEUDwfvvrNzhMFMwn6BEb2stQCXTECoqHCzOTuLYdC1BEHOEB28NEbskCkX4Yp6 /CyCCu6AohNizqaOCDyQEqnPhoxWUHSOI/WHTUDcuhV8K1v+9X6VKsCtnRLBhhWzYCkY 5ZbVAS+weenOwyWYmlUO2o7V3fozxb+EDnFOM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=WgBl28rpXF0cKq9OZ9vHNHY7seVIgJsuDyJQXHuFyK+I+Zw8AsHYDsFQ6fWase3PRK XfCdPQG/MALIUDGOFSraJYjUujju2L/6+33OOmHeX02GAWLZE0QqqvXgwV/qDaKm3ggM /k2aW0A6CXFm4nfNOMy8mlaS90X07iQBjrl1k=
Received: by 10.204.53.193 with SMTP id n1mr851022bkg.3.1288886552957; Thu, 04 Nov 2010 09:02:32 -0700 (PDT)
Received: from [192.168.0.102] ([95.35.139.62]) by mx.google.com with ESMTPS id t10sm90368bkj.4.2010.11.04.09.02.27 (version=SSLv3 cipher=RC4-MD5); Thu, 04 Nov 2010 09:02:30 -0700 (PDT)
Message-ID: <4CD2D90F.6040304@gmail.com>
Date: Thu, 04 Nov 2010 18:02:23 +0200
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6
MIME-Version: 1.0
To: Peter Saint-Andre <stpeter@stpeter.im>
References: <4CC9503D.2000809@gmail.com> <4CCBA7A9.7030506@stpeter.im> <4CCE87A5.80701@gmail.com> <4CCF20E7.30401@stpeter.im> <4CD1D708.7010308@stpeter.im>
In-Reply-To: <4CD1D708.7010308@stpeter.im>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-xmpp-3920bis.all@tools.ietf.org, iesg@ietf.org, XMPP <xmpp@ietf.org>, secdir@ietf.org
Subject: Re: [secdir] [xmpp] SecDir review of draft-ietf-xmpp-3920bis-17
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Nov 2010 16:02:25 -0000

Hi Peter,

yes, these seem reasonable. Is there a "converse" to the rewriting of 
the client's From header before forwarding to other servers, i.e. is 
there a server-side check on stanza From headers received from other 
servers?

Thanks,
	Yaron

On 11/03/2010 11:41 PM, Peter Saint-Andre wrote:
> Hi Yaron, following up our discusion, here is proposed text for the
> conformance features you suggested...
>
> On 11/1/10 2:19 PM, Peter Saint-Andre wrote:
>> On 11/1/10 3:25 AM, Yaron Sheffer wrote:
>>
>>> On 10/30/2010 07:05 AM, Peter Saint-Andre wrote:
>>>>
>>>> On 10/28/10 4:28 AM, Yaron Sheffer wrote:
>>>>
>>>>> - 15: I would expect one or a few features around validation of
>>>>> identities at the various layers, since we're spending much of the
>>>>> document on this issue. "tls-certs" is an important piece of that, but
>>>>> not the whole thing.
>>>>
>>>> I agree with you that the layering topics are important here. Do you
>>>> have specific suggestions?
>>>>
>>> - Server side: correlate cert-asserted client ID with "from".
>>> - Server: correlate "from" on stream to identity as authenticated by SASL.
>>> - Server: rewrite "from" on stanza to authenticated ID.
>>> - Client side: correlate cert-asserted server ID with "from".
>>> - Client: correlate "from" on stream to identity as authenticated by TLS
>>> certs and/or SASL.
>
> I think we can combine client and server validation into two features
> (instead of four), one for TLS and one for SASL.
>
> The TLS feature would be:
>
>     Feature:  tls-correlate
>     Description:  When validating a certificate presented by a stream
>        peer during TLS negotiation, correlate the validated identity with
>        the 'from' address (if any) of the stream header it received from
>        the peer.
>     Section:  Section 13.7.2
>     Roles:  Client SHOULD, Server SHOULD.
>
> As a target for that pointer, I think we need to add the following
> paragraph to the end of Section 13.7.2 ("Certificate Validation"):
>
>     Once the identity of the stream peer has been validated, the
>     validating entity SHOULD also correlate the validated identity with
>     the 'from' address (if any; see Section 4.6.1) of the stream header
>     it received from the peer.  If the two identities do not match, the
>     validating entity SHOULD terminate the connection attempt.
>
> The SASL feature would be:
>
>     Feature:  sasl-correlate
>     Description:  When authenticating a stream peer using SASL, correlate
>        the authentication identifier resulting from SASL negotiation with
>        the 'from' address (if any) of the stream header it received from
>        the peer.
>     Section:  Section 6.4.6
>     Roles:  Client N/A, Server SHOULD.
>
> As a target for that pointer, I think we need to add the following
> paragraph to the beginning of Section 6.4.6 ("SASL Success"):
>
>     Before considering the SASL handshake to be a success, the receiving
>     entity SHOULD correlate the authentication identity resulting from
>     the SASL negotiation with the 'from' address (if any; see
>     Section 4.6.1) of the stream header it received from the initiating
>     entity.  If the two identities do not match, the receiving entity
>     SHOULD terminate the connection attempt.
>
> Finally, we need one more feature, for server stamping of client 'from'
> addresses:
>
>     Feature:  stanza-attribute-from-stamp
>     Description:  Stamp or rewrite the 'from' address of all stanzas
>        received from connected clients.
>     Section:  Section 8.1.2.1
>     Roles:  Client N/A, Server MUST.
>
> Let me know if those seem reasonable.
>
> Peter
>