Early Review of draft-ietf-radext-dynamic-discovery-09
review-ietf-radext-dynamic-discovery-09-secdir-early-weis-2015-01-02-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 with the intent of improving security requirements and
considerations in IETF drafts.  Comments not addressed in last call may be
included in AD reviews during the IESG review.  Document editors and WG chairs
should treat these comments just like any other last call comments.

This document specifies a means to find authoritative RADIUS servers for a
given realm. This can be useful when authenticating/authorizing devices within
a roaming consortium (e.g., eduroam). An authoritative RADIUS client trying to
authenticate/authorize a host or perform accounting for that host finds a
RADIUS server by querying DNS for service records defined in this document.
Once a candidate sever has been found in DNS, the querier initiates a RADIUS
protocol to it protected by TLS, authorizes it based on information in its
certificate, and then RADIUS happens in the usual fashion. The document is
almost ready for publication, in my opinion.

There’s not much background given, and having an overview of the solution
architecture in the Introduction would be useful. I.e., a description and
picture showing the actors and the communication flows between them.  I don’t
have complete confidence that I correctly understood which actors are involved
in the RASIUS/TLS transaction -- in some sections it seems that RADIUS clients
are initiating requests and sometimes RADIUS servers and I thought only clients
contacted servers. An overview of the actors would probably have clarified that.

If I understand correctly how roaming consortiums currently work today, a
RADIUS client within a consortium needing to make a AAA call to a RADIUS server
in another realm does not contact the server directly. Instead, it routes the
request through a hierarchy of RADIUS servers following roots of trust. The
trust model in this document seems to be bypass the roots of trust, where the
client directly contacts the server. This seems to be discussed in the Section
6 (Privacy Considerations) discussion of “clearinghouses", but if the trust
model is changed, this is a bigger impact than privacy so ought to be discussed
explicitly someplace in the document.

Section 2.1.1.3 discusses the use of TLS cipher suites, and makes the point
that certificate based cipher suites need to be used because there won’t be any
pre-distributed secret key material available. That’s good advice. I think the
section should also give advice on choosing trust roots. This is important
because the identity of the server was gotten in an untrusted manner (from
unsecured DNS), and the certificate it presents contains information used for 
authorization of a server (i.e., SubjectAltName). If a RADIUS client were to
accept a certificate signed by a wide range of trust roots (e.g, the set of
roots used by browsers, where the trustability of many CAs in the hierarchy is
unknown) then the RADIUS client would be  ill advised to trust authorization
information claims in the hierarchy. On the other hand, if the trust roots were
restricted to a set of highly trusted trust roots maintained by the consortium,
then the authorization information in the certificate would be trustable. This
should be explained.

Section 2.2 defines the NAIRealm name as a form of otherName. This makes sense.
But there is also a paragraph discussing sRVName, which is confusing. I think
it’s clarifying who sRVName isn’t applicable; it would be good state that
plainly at the beginning of the paragraph.

Section 5  (first paragraph) makes the point that the information gotten from
DNS can’t be trusted. But I would suggest a slight rewording: s/can not be
trusted/is not sufficient to identify an authorized server/.

Brian