Subject: [radext] FW: SECDIR review of draft-ietf-radext-radsec-11

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 29 Jan 2012 17:45:30 +0100

-----Original Message-----
From: Matt Lepinski [mailto:[email-masked]] 
Sent: Friday, January 27, 2012 11:29 PM
To: [email-masked]; [email-masked]
Subject: SECDIR review of draft-ietf-radext-radsec-11

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

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 29 Jan 2012 17:45:30 +0100

-----Original Message-----
From: Matt Lepinski [mailto:[email-masked]] 
Sent: Friday, January 27, 2012 11:29 PM
To: [email-masked]; [email-masked]
Subject: SECDIR review of draft-ietf-radext-radsec-11

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".)
_______________________________________________
radext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/radext