Skip to main content

Last Call Review of draft-ietf-radext-radsec-

Request Review of draft-ietf-radext-radsec
Requested revision No specific revision (document currently at 12)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2012-01-31
Requested 2012-01-12
Authors Klaas Wierenga , Mike McCauley , Stefan Winter , Stig Venaas
I-D last updated 2012-02-08
Completed reviews Secdir Last Call review of -?? by Matt Lepinski
Assignment Reviewer Matt Lepinski
State Completed
Request Last Call review on draft-ietf-radext-radsec by Security Area Directorate Assigned
Completed 2012-02-08
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 specifies a TLS transport for the RADIUS protocol. It is 

an experimental specification that is one of several approaches to 

address security shortcomings in RADIUS (for example, the reliance of 

RADIUS upon MD5).

I believe this document presents a reasonable approach to providing 

integrity and confidentiality protection to RADIUS packets as well as 

cipher suite agility. The principal security concern is that when 

deploying RADIUS/TLS, the system will be vulnerable to bid-down attacks 

to RADIUS/UDP until either the RADIUS client or the RADIUS server 

disables support for RADIUS/UDP. This type of bid-down attack seems to 

be unavoidable and is well-documented in the security considerations.

I have a small number of additional comments below:

-- I would strongly advise changing all instances of the phrase 

"acceptable Certification Authority" to "trusted Certification 

Authority" in order to be consistent with terminology in TLS 1.2 (RFC 

5246). (I found instances of the phrase "acceptable Certification 

Authority" on the bottom of page 5 and the top of page 6.) I would also 

change "acceptable certificate" to "trusted certificate" in the 

fingerprint bullet on page 6.

-- In bulleted list number 2 on page 5 (Section 2.3), bullets 4 and 9 

seem to be redundant. Furthermore, I find it unusual to have a normative 

mandate that compliant implementations MUST NOT negotiate ciphersuites 

that do not provide confidentiality protection. (It is very common when 

discussing ciphersuite negotiation to mandate that implementations 

support certain ciphersuites offer confidentiality protection, but 

saying that a user MUST NOT be able to configure the implementation to 

use a NULL-encryption cipher suite is quite unusual.) After reading the 

security considerations section, I believe that the reason you have this 

normative requirement is because RADIUS packets include user-passwords 

which always require confidentiality protection. However, because the 

normative requirement is unusual, I would either add a sentence to 2.3 

explaining the requirement or else put a forward reference to Section 6 

(Security Considerations) for explanation.

-- I found the fingerprint bullet on page 6 to be a bit confusing. My 

understanding (after reading it several times) is that you are 

specifying a particular ASCII encoding for certificate fingerprints. In 

particular, you are mandating that each of the 20 bytes of the 

certificate fingerprint be encoded as a pair of hexadecimal digits and 

that the encoding for the fingerprint is the string "sha-1:" followed by 

the encodings of these 20 bytes separated by colons. I am not sure what 

the clearest way is to get across this meaning. However, the first time 

I read I read the current text it was not clear to me that the document 

was mandating a particular ASCII encoding of certificate fingerprints. 

(Question: Is there an interoperability failure if two RADIUS devices do 

not agree on the encoding of a certificate fingerprint? If the 

fingerprint is just something that is configured, calculated and used 

locally then it doesn't seem to matter whether one implementation uses 

the ASCII string: "sha-1:E1:2D:53 ... 9D" and another implementation 

uses the UTF-8 string "SHA-1:e1:2d:53 ... 9d".)