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

Peter Saint-Andre <stpeter@stpeter.im> Wed, 03 November 2010 21:41 UTC

Return-Path: <stpeter@stpeter.im>
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 937773A68E8; Wed, 3 Nov 2010 14:41:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.556
X-Spam-Level:
X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 YhzHNR+SuTuT; Wed, 3 Nov 2010 14:41:23 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 2EF483A66B4; Wed, 3 Nov 2010 14:41:23 -0700 (PDT)
Received: from squire.local (dsl-228-82.dynamic-dsl.frii.net [216.17.228.82]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D917E40D1E; Wed, 3 Nov 2010 15:50:12 -0600 (MDT)
Message-ID: <4CD1D708.7010308@stpeter.im>
Date: Wed, 03 Nov 2010 15:41:28 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Yaron Sheffer <yaronf.ietf@gmail.com>
References: <4CC9503D.2000809@gmail.com> <4CCBA7A9.7030506@stpeter.im> <4CCE87A5.80701@gmail.com> <4CCF20E7.30401@stpeter.im>
In-Reply-To: <4CCF20E7.30401@stpeter.im>
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020704090006000309010701"
X-Mailman-Approved-At: Thu, 04 Nov 2010 10:23:15 -0700
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: Wed, 03 Nov 2010 21:41:24 -0000

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

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