Re: [secdir] secdir review of draft-ietf-behave-turn-uri-03.txt

Marc Petit-Huguenin <petithug@acm.org> Fri, 30 October 2009 14:32 UTC

Return-Path: <petithug@acm.org>
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 431903A69B9; Fri, 30 Oct 2009 07:32:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.055
X-Spam-Level:
X-Spam-Status: No, score=-102.055 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 Trck1MpHvspA; Fri, 30 Oct 2009 07:32:03 -0700 (PDT)
Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 725DC3A67B6; Fri, 30 Oct 2009 07:32:03 -0700 (PDT)
Received: by server.implementers.org (Postfix, from userid 1001) id 0DFC96C984CA; Fri, 30 Oct 2009 14:32:19 +0000 (UTC)
Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 3D33E6C984B2; Fri, 30 Oct 2009 14:32:17 +0000 (UTC)
Message-ID: <4AEAF8F0.30201@acm.org>
Date: Fri, 30 Oct 2009 07:32:16 -0700
From: Marc Petit-Huguenin <petithug@acm.org>
User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701)
MIME-Version: 1.0
To: Pasi.Eronen@nokia.com
References: <20091019094603.GB4708@elstar.local> <4ADDFA8A.40902@acm.org> <808FD6E27AD4884E94820BC333B2DB773C09B0BC50@NOK-EUMSG-01.mgdnok.nokia.com>
In-Reply-To: <808FD6E27AD4884E94820BC333B2DB773C09B0BC50@NOK-EUMSG-01.mgdnok.nokia.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Sat, 31 Oct 2009 08:42:58 -0700
Cc: iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] secdir review of draft-ietf-behave-turn-uri-03.txt
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: Fri, 30 Oct 2009 14:32:04 -0000

Hi Pasi,

Sorry for the delay in responding to this.  See my answer inline.

Pasi.Eronen@nokia.com wrote:
> Marc Petit-Huguenin wrote:
> 
>> I propose to replace the second paragraph of section 6 by the
>> following text.  Let me know if it addresses your comment:
>>
>> "The Application Service Tag and Application Protocol Tags defined in
>> this document do not introduce any specific security issues beyond
>> the security considerations discussed in [RFC3958].  [RFC3958]
>> requests that an S-NAPTR application defines some form of end-to-end
>> authentication to ensure that the correct destination has been
>> reached.  This is achieved by the mandatory Long-Term Credential
>> Mechanism defined by [RFC5389] and additionally for a "turns" URI by
>> the usage of TLS."
> 
> We probably need some additional text about TLS here.
> 
> The text in RFC 3958 asks for a very specific kind of "end-to-end"
> authentication: the authenticated identity of the server must be the
> same as the *input* to the S-NAPTR processing.
> 
> So if the URI was "turns:example.com", and the DNS records are as
> follows:
> 
>   example.com. IN NAPTR 100 10 "S" "RELAY" "" turn.example.net.
>   turn.example.net. IN SRV 10 0 10001 turnserver1.example.org.
>   turnserver1.example.org. IN A 192.0.2.1
> 
> Then the server needs to present a certificate with name "example.com"
> (NOT "turn.example.net" or "turnserver1.example.org").
> 
> Is this the intent here?
> 
> The reason behind this text in RFC 3958 is that otherwise an attacker
> could just spoof DNS reply "example.com. IN NAPTR 100 10 "S" "RELAY"
> "" turn.attacker.org.", and TLS wouldn't catch this.
> 
> (Basically the same thing occurs in HTTPS, of course. If the URI is
> "https://www.example.com/", then the certificate must contain name
> "www.example.com", even if DNS replies with "www.example.com. IN 
> CNAME foo.attacker.org.")

Here's the new proposed text.  Let me know if this is OK for you:

"The Application Service Tag and Application Protocol Tags defined in
 this document do not introduce any specific security issues beyond
 the security considerations discussed in [RFC3958].  [RFC3958]
 requests that an S-NAPTR application defines some form of end-to-end
 authentication to ensure that the correct destination has been
 reached.  This is achieved for "turn" and "turns" URIs by the Long-
 Term Credential Mechanism defined in [RFC5389], which is mandatory
 for TURN [I-D.ietf-behave-turn].  Additionally for a "turns" URI, the
 usage of TLS has the capability to address the requirement.  In this
 case the client MUST verify the identity of the server by following
 the identification procedure in section 7.2.2 of [RFC5389]."


Thanks.

-- 
Marc Petit-Huguenin
Personal email: marc@petit-huguenin.org
Professional email: petithug@acm.org
Blog: http://blog.marc.petit-huguenin.org