Re: [secdir] Secdir review of draft-ietf-dime-extended-naptr-06

Glen Zorn <gwz@net-zen.net> Sun, 15 May 2011 07:35 UTC

Return-Path: <gwz@net-zen.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54190E0658 for <secdir@ietfa.amsl.com>; Sun, 15 May 2011 00:35:17 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+nZlUpC7SAX for <secdir@ietfa.amsl.com>; Sun, 15 May 2011 00:35:16 -0700 (PDT)
Received: from p3plsmtpa07-01.prod.phx3.secureserver.net (p3plsmtpa07-01.prod.phx3.secureserver.net [173.201.192.230]) by ietfa.amsl.com (Postfix) with SMTP id B5B10E06AB for <secdir@ietf.org>; Sun, 15 May 2011 00:35:16 -0700 (PDT)
Received: (qmail 4348 invoked from network); 15 May 2011 07:28:36 -0000
Received: from unknown (124.122.83.151) by p3plsmtpa07-01.prod.phx3.secureserver.net (173.201.192.230) with ESMTP; 15 May 2011 07:28:36 -0000
Message-ID: <4DCF809D.6040605@net-zen.net>
Date: Sun, 15 May 2011 14:28:29 +0700
From: Glen Zorn <gwz@net-zen.net>
Organization: Network Zen
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Charlie Kaufman <charliek@microsoft.com>
References: <D80EDFF2AD83E648BD1164257B9B09122C4668B5@TK5EX14MBXC119.redmond.corp.microsoft.com>
In-Reply-To: <D80EDFF2AD83E648BD1164257B9B09122C4668B5@TK5EX14MBXC119.redmond.corp.microsoft.com>
X-Enigmail-Version: 1.1.1
Content-Type: multipart/mixed; boundary="------------080508050003040009020404"
Cc: "draft-ietf-dime-extended-naptr.all@tools.ietf.org" <draft-ietf-dime-extended-naptr.all@tools.ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Secdir review of draft-ietf-dime-extended-naptr-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Sun, 15 May 2011 07:35:17 -0000

On 5/3/2011 12:36 PM, Charlie Kaufman wrote:

...

> Unfortunately, the story doesn’t end there. To understand this spec, I
> had to read the Diameter document. The approach that Diameter takes to
> configuration using DNS appears to leave a gaping security hole that
> should be examined by whoever is reviewing RFC 3588bis (which is also in
> final stages of approval). The problem is that TLS (or IPsec) is used to
> secure the Diameter connections themselves, and shared keys or
> certificates are used to authenticate the peer entities. But the DNS
> records appear to be used to learn the names of the peer entities which
> are subsequently authenticated. That means if someone could update DNS
> they could indicate the Diameter server for some domain was in fact some
> rogue server. So long as that rogue server could be authenticated, it
> would be trusted to speak for the domain in the context of Diameter.

I don't think that that is actually true (see below).

> 
>  
> 
> I suspect common practice is to have Diameter server names be manually
> configured, in which case there is no vulnerability. But without looking
> at this in detail it would appear that the more flexible
> autoconfiguration via DNS is not secure. If so (I could easily be
> missing something), there are several ways it could be fixed. DNSSEC
> would be the obvious solution, but not necessarily the best. DNSSEC is
> still not widely deployed, and this protocol is unlikely to act as a
> forcing function. 
> Better would be to put some sort of extension in the
> certificates of Diameter certificates that indicates the domain(s) over
> which the server has jurisdiction in this context. 

>From draft-ietf-dime-rfc3588bis, Section 5.2:

   If the server is using a site certificate, the domain name in the
   NAPTR query and the domain name in the replacement field MUST both be
   valid based on the site certificate handed out by the server in the
   TLS/TCP and DTLS/SCTP or IKE exchange.  Similarly, the domain name in
   the SRV query and the domain name in the target in the SRV record
   MUST both be valid based on the same site certificate.  Otherwise, an
   attacker could modify the DNS records to contain replacement values
   in a different domain, and the client could not validate that this
   was the desired behavior, or the result of an attack.

   Also, the Diameter Peer MUST check to make sure that the discovered
   peers are authorized to act in its role.  Authentication via IKE or
   TLS/TCP and DTLS/SCTP, or validation of DNS RRs via DNSSEC is not
   sufficient to conclude this.  For example, a web server may have
   obtained a valid TLS/TCP and DTLS/SCTP certificate, and secured RRs
   may be included in the DNS, but this does not imply that it is
   authorized to act as a Diameter Server.

   Authorization can be achieved for example, by configuration of a
   Diameter Server CA.  Alternatively this can be achieved by definition
   of OIDs within TLS/TCP and DTLS/SCTP or IKE certificates so as to
   signify Diameter Server authorization.

This seems to address the issue, the only problem I can see is that the
last sentence of the second paragraph quoted above might not be specific
enough; maybe change "authorized to act as a Diameter Server." to
"authorized to act as a Diameter Server for the given realm."?

> Yet another option
> would be some naming convention for finding the name of Diameter servers
> for a particular domain rather than looking them up in DNS.

I think that that was discussed at some point thousands of years ago but
rejected; I don't recall why.

...