[secdir] Review of draft-ietf-radext-design-07

Phillip Hallam-Baker <hallam@gmail.com> Wed, 06 May 2009 13:53 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 022163A6BAD for <secdir@core3.amsl.com>; Wed, 6 May 2009 06:53:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.289
X-Spam-Level:
X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjcYzWLQi9sf for <secdir@core3.amsl.com>; Wed, 6 May 2009 06:53:03 -0700 (PDT)
Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by core3.amsl.com (Postfix) with ESMTP id 721A03A67A3 for <secdir@ietf.org>; Wed, 6 May 2009 06:52:26 -0700 (PDT)
Received: by yx-out-2324.google.com with SMTP id 8so99843yxb.49 for <secdir@ietf.org>; Wed, 06 May 2009 06:53:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=OdIiAIo/BY7ivV2kv7IDrosdFyWwGTfGaAniTbDhGX4=; b=EwgStgF/jZcQPQdTGqU4cM5fl/nu4dibwZY5dmgnQv5hbKPO+aWSEeM2PCws2pf9E8 kNWe4WIEZOdgK7NcduDIM4WHn0JgaLkkzKMdFUiQZC+Jm7U88twopg4ief6q1n1EIV/p cq42CUfCf4IDOmNK3BtzdX/LCVKIc481YFMnc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=w3eHx3p4ASYk3bACqBXsUJUCCUXu04r8sCnSUKPpyQuPmK2DzZsuKPStgLu7ltGRQr 2oDsVeEQUs8PdEL/uOdfGZiAKeWaSiLbLBvdv4QZb7CDloa5gCXjJGdUheFB0drNHIaj vOt2jIzkIiKAHeZImlrcjeoj/DeARalobG2F0=
MIME-Version: 1.0
Received: by 10.100.109.13 with SMTP id h13mr3011308anc.16.1241618031061; Wed, 06 May 2009 06:53:51 -0700 (PDT)
Date: Wed, 06 May 2009 09:53:51 -0400
Message-ID: <a123a5d60905060653s7cff39eam783b8cf9aee78615@mail.gmail.com>
From: Phillip Hallam-Baker <hallam@gmail.com>
To: secdir@ietf.org, gdweber@gmail.com, aland@freeradius.org
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Wed, 06 May 2009 22:34:53 -0700
Subject: [secdir] Review of draft-ietf-radext-design-07
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Wed, 06 May 2009 13:53:11 -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.

As always with Radius documents it is somewhat hard to do a security
review of a security protocol that admits that the protocol does not
offer security.

While the security is provided through layering on another protocol
(e.g. IPSEC), the mix and match approach is unsatisfactory. Security
is a property of a system. It is really not possible to analyze the
security of a system when one half of the system is unspecified.

The Security Considerations section is adequate and given the purpose
of this draft it is appropriate to cite external documents where the
security issues are discussed in detail rather than repeat the caveats
here. But the question does have to be asked why we have so many
security caveats in what is a foundational security protocol.

While IPSEC security is certainly adequate for some applications, I
have a really hard time accepting it as the security layer for a
foundational security protocol. I prefer basic authentication and
authorization protocols to have security built in. In particular I
want to know what happens at the RADIUS protocol level when there is
an error at the IPSEC layer or vice versa. IPSEC is not secure against
active attack unless error conditions are appropriately handled.



-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/