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

From: Stefan Winter <[email-masked]>
Date: Fri, 06 Mar 2015 09:35:39 +0100

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: +352 424409 1
Fax: +352 422473

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

---

From: Stefan Winter <[email-masked]>
Date: Fri, 06 Mar 2015 09:35:48 +0100

Hello,

> The clarification below was very useful.  Perhaps the authors will find it valuable to include the references you mentioned, and clarify that there is expected to be a limited number of trusted (preferably one) trusted to issue certificates for the consortium use case.

The NAI reference was already in the document, and I've pulled in text
from the RADIUS/DTLS reference directly into the document.

The text regarding the small set of CAs is now also in.

Thanks,

Stefan Winter

> 
> Thanks,
> Brian
> 
> On Jan 4, 2015, at 8:48 PM, Alan DeKok <[email-masked]> wrote:
> 
>> On Dec 24, 2014, at 4:05 PM, Brian Weis <[email-masked]> wrote:
>>
>>  I’m not the document author, but I can help give some clarification.
>>
>>> 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.
>>
>>  The current roaming behaviour is discussed in the NAI document, Section 3.  Unfortunately, it also assumes some familiarity with the field.
>>
>> http://tools.ietf.org/html/draft-ietf-radext-nai-15#section-3
>>
>>  Perhaps the simplest explanation is that RADIUS is client-server.  Clients request authentication on behalf of users, and servers authenticate the users.  The key thing is that historically, proxying has been static, and provisioning of proxy configuration has been entirely outside of the protocol.  i.e. proxies operate by consensus and habit, not by standard behaviour.
>>
>>  A long description of the Eduroam consortium is available as an individual draft:
>>
>> http://tools.ietf.org/html/draft-wierenga-ietf-eduroam-04
>>
>>  However, *commercial* proxies do not operate in the eduroam model.  Commercial proxies are largely “star” configurations.  An interconnect company sits at the centre of a star.  It may connect to one or more other interconnect providers.  Routes are largely static, and are usually updated by hand, after legal contracts have been exchanged.
>>
>>  This document is standardizing provisioning of RADIUS proxying, via dynamic methods.
>>
>>> 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.
>>
>>  Clients are the only ones initiating requests.  In some cases, the system running RADIUS can behave as a client or as a server, depending on it’s needs.  That makes it more complicated.
>>
>>> 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.
>>
>>  s/does not/may not/
>>
>>> Instead, it routes the request through a hierarchy of RADIUS servers following roots of trust.
>>
>>  That’s how eduroam works.  Commercial proxies are configured differently.
>>
>>  However, they both operate on a “fire and forget” model.  A RADIUS server which wants to proxy a request somehow (magically, almost) determines which upstream server to use.  The “magic” part of that process is what the dynamic discovery document is trying to standardize.
>>
>>> 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.
>>
>>  Current RADIUS practice uses a limited set of CAs.  Generally, only one.  This use-case is *very* different than that for browsers.  This document should make that clearer.  Shipping a RADIUS server (or client) with a list of pre-configured CAs is a *very bad* idea.  RFC 6614 (RADIUS over TLS) should probably have had such statements.  RFC 7360 (RADIUS over DTLS) has some related text which would be useful here:
>>
>> https://tools.ietf.org/html/rfc7360
>>
>>  Section 10.4: ...
>>
>>   Therefore, clients SHOULD NOT be pre-configured with a list of known
>>   public CAs by the vendor or manufacturer.  Instead, the clients
>>   SHOULD start off with an empty CA list.  The addition of a CA SHOULD
>>   be done only when manually configured by an administrator.
>>   This scenario is the opposite of web browsers, where they are pre-
>>   configured with many known CAs.  The goal there is security from
>>   third-party observers, but also the ability to communicate with any
>>   unknown site that presents a signed certificate.  In contrast, the
>>   goal of RADIUS/DTLS is both security from third-party observers and
>>   the ability to communicate with only a small set of well-known
>>   servers.
>>
>>> 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.
>>
>>  Generally there’s only one root CA for a consortium.  I’m not sure what the use-case would be for multiple root CAs.
>>
>>  Alan DeKok.
>>
> 

Tel: +352 424409 1
Fax: +352 422473