Re: [secdir] draft-zorn-radius-pkmv1-05.txt

"Glen Zorn" <gwz@net-zen.net> Thu, 27 August 2009 01:31 UTC

Return-Path: <gwz@net-zen.net>
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 01F9728C18C for <secdir@core3.amsl.com>; Wed, 26 Aug 2009 18:31:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.758
X-Spam-Level:
X-Spam-Status: No, score=-1.758 tagged_above=-999 required=5 tests=[AWL=0.840, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 hLnORM8rcMdA for <secdir@core3.amsl.com>; Wed, 26 Aug 2009 18:31:02 -0700 (PDT)
Received: from p3plsmtpa01-09.prod.phx3.secureserver.net (p3plsmtpa01-09.prod.phx3.secureserver.net [72.167.82.89]) by core3.amsl.com (Postfix) with SMTP id C514C28C177 for <secdir@ietf.org>; Wed, 26 Aug 2009 18:31:02 -0700 (PDT)
Received: (qmail 6634 invoked from network); 27 Aug 2009 01:24:29 -0000
Received: from unknown (71.231.55.1) by p3plsmtpa01-09.prod.phx3.secureserver.net (72.167.82.89) with ESMTP; 27 Aug 2009 01:24:29 -0000
From: "Glen Zorn" <gwz@net-zen.net>
To: "'Bernard Aboba'" <bernard_aboba@hotmail.com>, "'Donald Eastlake'" <d3e3e3@gmail.com>
References: <BLU137-W143E886FA45D9D848217FA93F70@phx.gbl> <006b01ca2692$fcda3500$f68e9f00$@net>
In-Reply-To: <006b01ca2692$fcda3500$f68e9f00$@net>
Date: Wed, 26 Aug 2009 18:24:21 -0700
Organization: Network Zen
Message-ID: <00a001ca26b5$1b6e9b10$524bd130$@net>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A1_01CA267A.6F0FC310"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcombVTUQ7+mO5CJSm21fdbLMgEuJAAAojfwABEe+oA=
Content-Language: en-us
Cc: ietf@ietf.org, secdir@ietf.org
Subject: Re: [secdir] draft-zorn-radius-pkmv1-05.txt
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: Thu, 27 Aug 2009 01:31:03 -0000

.
PKMv1 has some fairly serious security problems that are described here:
http://www2.computer.org/portal/web/csdl/doi/10.1109/SNPD.2008.138

So I think the question is whether this document can make those serious
security problems even worse, in a way that has not already been 
documented. 

AFAICT, this is not the case.  The use of RADIUS doesn't improve the
security of PKMv2 but it doesn't seem to reduce it either .  The suggested
use of the MS-MPPE-Send-Key Attribute may be problematic but seems pretty
much unavoidable at present.



I'd suggest that the document reference the known security
issues that are covered in other documents, such as the ones above and
others (such as RFC 3579) that describe weaknesses in the MPPE-Key
attributes. 

OK

The Security Considerations section now looks like this:

7.  Security Considerations

 

   Section 4 of RFC 3579 [RFC3579] discusses vulnerabilities of the

   RADIUS protocol.

 

   Section 3 of the paper "Security Enhancements for Privacy and Key

   Management Protocol in IEEE 802.16e-2005" [SecEn] discusses the

   operation and vulnerabilities of the PKMv1 protocol.

 

   If the Access-Request message is not subject to strong integrity

   protection, an attacker may be able to modify the contents of the

   PKM-Cryptosuite-List Attribute, weakening 802.16 security or

   disabling data encryption altogether.

 

   If the Access-Accept message is not subject to strong integrity

   protection, an attacker may be able to modify the contents of the

   PKM-Auth-Key Attribute.  For example, the Key field could be replaced

   with a key known to the attacker.

 

   Although it is necessary for a plaintext copy of the Key field in the

   PKM-AUTH-Key Attribute to be transmitted in the Access-Accept

   message, this document does not define a method for doing so

   securely.  In order to transfer the key securely, it is RECOMMENDED

   that it be encapsulated in an instance of the MS-MPPE-Send-Key

   Attribute [RFC2548]; however, see section 4.3.4 of RFC 3579 [RFC3579]

   for details regarding weaknesses in the encryption scheme used.

Is that OK?
.