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

<Pasi.Eronen@nokia.com> Fri, 23 October 2009 11:17 UTC

Return-Path: <Pasi.Eronen@nokia.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 99DCF3A6864; Fri, 23 Oct 2009 04:17:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.581
X-Spam-Level:
X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 zsHE17rNarFf; Fri, 23 Oct 2009 04:17:34 -0700 (PDT)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 6DED13A67FD; Fri, 23 Oct 2009 04:17:34 -0700 (PDT)
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n9NBHCiM010625; Fri, 23 Oct 2009 14:17:37 +0300
Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Oct 2009 14:16:59 +0300
Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Oct 2009 14:16:51 +0300
Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Fri, 23 Oct 2009 13:16:47 +0200
From: Pasi.Eronen@nokia.com
To: petithug@acm.org, j.schoenwaelder@jacobs-university.de
Date: Fri, 23 Oct 2009 13:16:46 +0200
Thread-Topic: [secdir] secdir review of draft-ietf-behave-turn-uri-03.txt
Thread-Index: AcpRr2HqbWs5MHteSKmzYzDotHQRYACHxHYg
Message-ID: <808FD6E27AD4884E94820BC333B2DB773C09B0BC50@NOK-EUMSG-01.mgdnok.nokia.com>
References: <20091019094603.GB4708@elstar.local> <4ADDFA8A.40902@acm.org>
In-Reply-To: <4ADDFA8A.40902@acm.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 23 Oct 2009 11:16:51.0029 (UTC) FILETIME=[5192C050:01CA53D2]
X-Nokia-AV: Clean
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, 23 Oct 2009 11:17:35 -0000

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

Best regards,
Pasi