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

Charlie Kaufman <charliek@microsoft.com> Tue, 03 May 2011 05:36 UTC

Return-Path: <charliek@microsoft.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 13DC8E06FE; Mon, 2 May 2011 22:36:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 4SFKsR24J0kf; Mon, 2 May 2011 22:36:46 -0700 (PDT)
Received: from smtp.microsoft.com (mail3.microsoft.com []) by ietfa.amsl.com (Postfix) with ESMTP id 0F157E06F1; Mon, 2 May 2011 22:36:46 -0700 (PDT)
Received: from TK5EX14HUBC102.redmond.corp.microsoft.com ( by TK5-EXGWY-E803.partners.extranet.microsoft.com ( with Microsoft SMTP Server (TLS) id; Mon, 2 May 2011 22:36:45 -0700
Received: from TK5EX14MBXC119.redmond.corp.microsoft.com ([]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([]) with mapi id 14.01.0289.008; Mon, 2 May 2011 22:36:45 -0700
From: Charlie Kaufman <charliek@microsoft.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-dime-extended-naptr.all@tools.ietf.org" <draft-ietf-dime-extended-naptr.all@tools.ietf.org>
Thread-Topic: Secdir review of draft-ietf-dime-extended-naptr-06
Thread-Index: AcwJUP9jS00Dz04RS1qvYxOu4jn5AQ==
Date: Tue, 3 May 2011 05:36:44 +0000
Message-ID: <D80EDFF2AD83E648BD1164257B9B09122C4668B5@TK5EX14MBXC119.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_D80EDFF2AD83E648BD1164257B9B09122C4668B5TK5EX14MBXC119r_"
MIME-Version: 1.0
Subject: [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: Tue, 03 May 2011 05:36:48 -0000

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.

This document makes some straightforward extensions to the DNS records that support the Diameter protocol (RFC 3588). The goal is to improve performance over the previous approach where in some cases multiple servers would have to be contacted to determine which one(s) supported some particular application. As the document notes, there are no security issues beyond those that apply to the base protocol (RFC 3588).

So I found nothing objectionable in this document.

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

In any case, someone should have a look.