[secdir] SECDIR review of draft-ietf-radext-radsec-11

Matt Lepinski <mlepinsk@bbn.com> Fri, 27 January 2012 21:27 UTC

Return-Path: <mlepinsk@bbn.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E509E21F861F; Fri, 27 Jan 2012 13:27:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1lXTQPZKh-G; Fri, 27 Jan 2012 13:27:20 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1192521F8577; Fri, 27 Jan 2012 13:27:20 -0800 (PST)
Received: from [128.89.253.251] (port=1820) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from <mlepinsk@bbn.com>) id 1RqtKI-0001dW-Vp; Fri, 27 Jan 2012 16:27:19 -0500
Message-ID: <4F2316C3.2010405@bbn.com>
Date: Fri, 27 Jan 2012 16:27:31 -0500
From: Matt Lepinski <mlepinsk@bbn.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, draft-ieft-radext-radsec.all@tools.ietf.org
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Sat, 28 Jan 2012 09:31:06 -0800
Subject: [secdir] SECDIR review of draft-ietf-radext-radsec-11
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Jan 2012 21:27:21 -0000

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