Skip to main content

Last Call Review of draft-ietf-dime-extended-naptr-
review-ietf-dime-extended-naptr-secdir-lc-kaufman-2011-05-07-00

Request Review of draft-ietf-dime-extended-naptr
Requested revision No specific revision (document currently at 09)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2011-04-20
Requested 2011-04-14
Authors Jouni Korhonen , Lionel Morand , Mark Jones
I-D last updated 2011-05-07
Completed reviews Tsvdir Last Call review of -?? by Magnus Westerlund
Secdir Last Call review of -?? by Charlie Kaufman
Assignment Reviewer Charlie Kaufman
State Completed
Request Last Call review on draft-ietf-dime-extended-naptr by Security Area Directorate Assigned
Completed 2011-05-07
review-ietf-dime-extended-naptr-secdir-lc-kaufman-2011-05-07-00

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.



                --Charlie