[secdir] Security review of draft-ietf-radext-radsec
Sam Hartman <hartmans@painless-security.com> Fri, 27 January 2012 19:47 UTC
Return-Path: <hartmans@painless-security.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 1564921F85F3; Fri, 27 Jan 2012 11:47:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.394
X-Spam-Level:
X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[AWL=-0.129, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
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 P5kCoMQNpC+L; Fri, 27 Jan 2012 11:47:49 -0800 (PST)
Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6AB21F8510; Fri, 27 Jan 2012 11:47:49 -0800 (PST)
Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id A9B42204AF; Fri, 27 Jan 2012 14:46:55 -0500 (EST)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 528A74690; Fri, 27 Jan 2012 14:47:42 -0500 (EST)
From: Sam Hartman <hartmans@painless-security.com>
To: radext@ietf.org, secdir@ietf.org, ietf@ietf.org
Date: Fri, 27 Jan 2012 14:47:42 -0500
Message-ID: <tslmx992aht.fsf@mit.edu>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Mailman-Approved-At: Sat, 28 Jan 2012 09:31:06 -0800
Subject: [secdir] Security review of draft-ietf-radext-radsec
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 19:47:50 -0000
Hi. I'm not the secdir reviewer assigned to this draft, but felt that this draft needed additional security review, so I decided to perform a secdir-like review. Overall, I think this is a much-needed specification and believe it is mostly ready for publication as an experimental RFC. I'd say a bit more clarity would be required if we wanted to move this to the standards track. General issues: 1) I'm reasonably sure that RADSEC MUST NOT be used with TLS versions prior to 1.1. The concern I have is that RADSEC has long-lived TLS connections under which an attacker could potentially observe ciphertext generated from some plaintext before sending additional plaintext. TLS 1.1 includes explicit IVs that prevent various attacks that may happen against earlier versions of TLS. There are implementation work arounds that can also prevent these attacks. However since all RADSEC implementations are required to support TLS 1.1, I'd prefer to add a requirement that RADSEC implementations MUST NOT negotiate TLS versions prior to 1.1 in order to avoid this issue. 2) Section 2.3 implies that you need to do cert validation all the time, even when you have a certificate fingerprint. I think it could more clearly indicate that multiple ways of figuring out if you have the right public key are provided. It's also not clear to me from section 2.3 whether there is a mandatory-to-implement strategy. You SHOULD support cert fingerprints. You MUST support cert path validation, but is there a required name form to support? There are discussions of several name forms but none seem mandatory. I see no discussion of RFC 6125, which I would have expected to see here. However, most of this is OK for an experimental spec. This is the big area where I'd expect to see more clarity before this could move to the standards track.
- [secdir] Security review of draft-ietf-radext-rad… Sam Hartman
- Re: [secdir] [radext] Security review of draft-ie… Sam Hartman
- Re: [secdir] [radext] Security review of draft-ie… Stefan Winter