Re: [secdir] Secdir review of draft-ietf-radext-dynamic-discovery-12

[Stefan Winter <[e-mail]>]

Hello all,

sorry for taking so long :-(

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

I have added two ASCII art descriptions: how static request routing
works (in an example deployment which uses top-level domain endings to
partition the realm space) and one where DNS replaces these static
routing rules. I hope the art and accompanying text clarifies the document.

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

It doesn't bypass trust; it moves trust away from static IP adress and
shared secrets to a trust based on PKIX and DNS. The roots of trust
still exist, they are just not RADIUS servers any more, but CAs, and
they do their work out-of-band (CA issuing/revoking certs instead of a
RADIUS proxy inspecting each packet and making a packet-by-packet trust
decision).

In other words, the RADIUS client and RADIUS server remain the same
actors and they maintain their same level of trust as before.

The impact on privacy is the most outstanding one, and is extensively
discussed in the document. There is indeed another aspect, and that is a
technical one: the hierarchy/star topology of intermediate servers can
do sanitisation of packets as they pass by (typically, removing, adding,
or re-writing RADIUS attributes); when these intermediates are not in
place any more, a RADIUS server needs to expect more diversified packets
coming in and it may need to do some sanitisation itself.

A sentence to that effect is in the draft, inside privacy
considerations. Maybe that's not the best place, but I do think that
this beyond-privacy aspect is touched upon. I'm speaking of this sentence:

"However, there exist
      reasons why clearinghouses might still be used.  One reason to
      keep a clearinghouse is to act as a gateway for multiple backends
      in a company; another reason may be a requirement to sanitise
      RADIUS datagrams (filter attributes, tag requests with new
      attributes, ... )."

> 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 t
rustable. This should be explained.

I have added new text (thanks Alan for the suggestion, I've reused a few
sentences from the RADIUS/DTLS document), 2.1.1.3 now has a new last
paragraph.

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

I'm not sure I can follow you here... NAIRealm is used to verify after
discovery that the target server is authorised to handle requests for
the realm that was queried from DNS.

The querying itself may use either NAPTR records (preferred) or SRV
records (fallback).

The paragraph which discusses sRVName only makes clear why verifying
sRVName against an SRV doesn't buy you anything. If you find the
paragraph regarding the uselessness of sRVName confusing, I can take it
out, but since issue has repeatedly been asked during the lifetime of
the draft, I think it is useful to keep this explanatory statement in.

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

I'd prefer to keep my wording, as these are two different things:

With DNS (no SEC), the result O (=IP addresses and ports) are
potentially bogus (i.e. possibly incorrect *and* the resulting TLS
connection may be to an unauthorised peer).
With DNSSEC, the result O is verifiably correct, but the resulting TLS
connection may still be to an unauthorised server.

Your rewording would suggest that DNS-no-SEC only has a shortcoming re
authorisation, but it's more than that.

I've just issued rev -13 with all the above-mentioned changes. Please
consult the diff at

https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-radext-dynamic-discovery-13.txt

and let me know if you are satisfied.

Greetings,

Stefan Winter

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: [phone]
Fax: [phone]

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me

http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66