Subject: [AAA-DOCTORS] Review of draft-ietf-radext-radsec

From: Bernard Aboba <[email-masked]>
Date: Thu, 19 Jan 2012 08:16:18 -0800

This is a review of "TLS Encryption for RADIUS" draft-ietf-radext-radsec. 

Overall, this draft was a pleasant to read, and it is clear that a lot of thought as well as implementation experience has gone into it. 

Kudos to the authors. 

General Issues

There is a considerable amount of text relating to dynamic discovery in this document, yet
there is only an informational reference to it. 

Since inserting a normative reference to dynamic discovery could delay the publication of
this document unnecessarily, my recommendation is to consolidate some of the dynamic
discovery material into a single section in which you can discuss the implications, while
clearly indicating the status of the dynamic discovery work (e.g. still under development, optional to
implement along with RADSEC, etc.). 

For example, you might consider consolidating the following text from Sections 3.1 and 6 
and placing it prior to the current Section 3.1:

Section 3.X:  Implications of Dynamic Peer Discovery

   One mechanism to discover RADIUS over TLS peers dynamically via DNS 

   is specified in [I-D.ietf-radext-dynamic-discovery].  While this mechanism

   is still under development and therefore is not a normative dependency of

   RADIUS/TLS, the use of dynamic discovery has potential future implications that are

   important to understand. 

   If dynamic peer discovery as per
   [I-D.ietf-radext-dynamic-discovery] is used, peer authentication
   alone is not sufficient; the peer must also be authorised to perform
   user authentications.  In these cases, the trust fabric cannot depend
   on peer authentication methods like DNSSEC to identify RADIUS/TLS
   nodes.  The nodes also need to be properly authorised.  Typically,
   this can be achieved by adding appropriate authorisation fields into
   a X.509 certificate.  Such fields include SRV authority [RFC4985],
   subjectAltNames, or a defined list of certificate fingerprints.
   Operators of a RADIUS/TLS infrastructure should define their own
   authorisation trust model and apply this model to the certificates.
   The checks enumerated in Section 2.3 provide sufficient flexibility
   for the implementation of authorisation trust models.

[BA] I think you need to be more prescriptive here.  Are there specific
fields that a RADSEC TLS certificate should contain?  Having individual
implementations/deployments defining their own authorization schemes seems
like a bad idea.  

   In the case of dynamic peer discovery as per
   [I-D.ietf-radext-dynamic-discovery], a RADIUS/TLS node needs to be
   able to accept connections from a large, not previously known, group
   of hosts, possibly the whole internet.  In this case, the server's
   RADIUS/TLS port can not be protected from unauthorised connection
   attempts with measures on the network layer, i.e. access lists and
   firewalls.  This opens more attack vectors for Distributed Denial of
   Service attacks, just like any other service that is supposed to
   serve arbitrary clients (like for example web servers).

   In the case of dynamic peer discovery as per
   [I-D.ietf-radext-dynamic-discovery], X.509 certificates are the only
   proof of authorisation for a connecting RADIUS/TLS nodes.  Special
   care needs to be taken that certificates get verified properly
   according to the chosen trust model (particularly: consulting CRLs,
   checking critical extensions, checking subjectAltNames etc.) to
   prevent unauthorised connections.

Other comments

Section 1

   One mechanism to discover RADIUS over TLS peers with DNS is specified in
   [I-D.ietf-radext-dynamic-discovery].

[BA] Recommend moving this to a section devoted to dynamic discovery. 

Section 2.1

   See
   section Section 3.3 (4) and (5) for considerations regarding
   separation of authentication, accounting and dynauth traffic.

[BA] Recommend changing to:

   "See Section 3.3 for considerations regarding separation of
    authentication, accounting and dynamic authorisation traffic."

Section 2.3

   4.  start exchanging RADIUS datagrams.  Note Section 3.3 (1) ).  The
       shared secret to compute the (obsolete) MD5 integrity checks and
       attribute encryption MUST be "radsec" (see Section 3.3 (2) ).

Section 3.1

   (3) If dynamic peer discovery as per
   [I-D.ietf-radext-dynamic-discovery] is used, peer authentication
   alone is not sufficient; the peer must also be authorised to perform
   user authentications.  In these cases, the trust fabric cannot depend
   on peer authentication methods like DNSSEC to identify RADIUS/TLS
   nodes.  The nodes also need to be properly authorised.  Typically,
   this can be achieved by adding appropriate authorisation fields into
   a X.509 certificate.  Such fields include SRV authority [RFC4985],
   subjectAltNames, or a defined list of certificate fingerprints.
   Operators of a RADIUS/TLS infrastructure should define their own
   authorisation trust model and apply this model to the certificates.
   The checks enumerated in Section 2.3 provide sufficient flexibility
   for the implementation of authorisation trust models.

As noted above, I'd suggest removing this material from Section 3.1 and 
consolidating it with other dynamic-discovery material.  

Section 3.3

   Note well: it is not required for an implementation
   to actually process these packet types.  It is sufficient that upon
   receiving such a packet, an unconditional NAK is sent back to
   indicate that the action is not supported.

[BA] What Error-Cause attribute value should be included within the NAK to make it
clear that the action is not supported?  Error 406 "Unsupported Extension"?
That is what RFC 5176 Section 3.5 seems to indicate. 

   There
   is no RADIUS datagram to signal an Accounting NAK.  Clients may be
   misconfigured to send Accounting packets to a RADIUS/TLS server which
   does not wish to process their Accounting packet.  The server will
   need to silently drop the packet.  The client will need to deduce
   from the absence of replies that it is misconfigured; no negative
   ICMP response will reveal this.

[BA] This seems like a bad idea.  How about requiring implementations not
supporting Accounting to respond with an Accounting-Response containing
Error-Cause attribute value 406?  Implementations receiving an Accounting-Response
with this Error-Cause can be required to treat this like an ICMP response. 

Section 4

   As a consequence, the selection of transports to communicate from a
   client to a server is a manual administrative action.  An automatic
   fallback to RADIUS/UDP is NOT RECOMMENDED, as it may lead to down-
   bidding attacks on the peer communication.

[BA] If a fixed shared secret "radsec" is used alongside fallback to RADIUS/UDP,
that seems more like a MUST NOT!!

Section 6

   In the case of dynamic peer discovery as per
   [I-D.ietf-radext-dynamic-discovery], a RADIUS/TLS node needs to be
   able to accept connections from a large, not previously known, group
   of hosts, possibly the whole internet.  In this case, the server's
   RADIUS/TLS port can not be protected from unauthorised connection
   attempts with measures on the network layer, i.e. access lists and
   firewalls.  This opens more attack vectors for Distributed Denial of
   Service attacks, just like any other service that is supposed to
   serve arbitrary clients (like for example web servers).

   In the case of dynamic peer discovery as per
   [I-D.ietf-radext-dynamic-discovery], X.509 certificates are the only
   proof of authorisation for a connecting RADIUS/TLS nodes.  Special
   care needs to be taken that certificates get verified properly
   according to the chosen trust model (particularly: consulting CRLs,
   checking critical extensions, checking subjectAltNames etc.) to
   prevent unauthorised connections.

[BA] I'd recommend collecting this and other dynamic-discovery related material
into a separate section prior to 3.1. 

Appendix C. Assessment of Crypto-Agility Requirements

   The RADIUS Crypto-Agility Requirements (link to RFC once issued here)
   defines numerous classification criteria for protocols that strive to
   enhance the security of RADIUS.  It contains mandatory (M) and
   recommended (R) criteria which crypto-agile protocols have to
   fulfill.  The authors believe that the following assessment about the
   crypto-agility properties of RADIUS/TLS are true.

[BA] The Crypto-Agility RFC is now published so you should reference that.