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

Bernard Aboba <bernard_aboba@hotmail.com> Thu, 27 August 2009 06:45 UTC

Return-Path: <bernard_aboba@hotmail.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 1F4933A6A58; Wed, 26 Aug 2009 23:45:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.082
X-Spam-Level:
X-Spam-Status: No, score=-1.082 tagged_above=-999 required=5 tests=[AWL=1.516, 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 5ah5GNV0EitU; Wed, 26 Aug 2009 23:45:42 -0700 (PDT)
Received: from blu0-omc2-s30.blu0.hotmail.com (blu0-omc2-s30.blu0.hotmail.com [65.55.111.105]) by core3.amsl.com (Postfix) with ESMTP id 7AD813A67AC; Wed, 26 Aug 2009 23:45:42 -0700 (PDT)
Received: from BLU137-W26 ([65.55.111.71]) by blu0-omc2-s30.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 23:45:49 -0700
Message-ID: <BLU137-W263D60314C6C1DF8CA82D893F60@phx.gbl>
Content-Type: multipart/alternative; boundary="_34923521-8e13-4155-a168-27cdd70bea90_"
X-Originating-IP: [97.120.168.211]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: <d3e3e3@gmail.com>, <gwz@net-zen.net>
Date: Wed, 26 Aug 2009 23:45:48 -0700
Importance: Normal
In-Reply-To: <1028365c0908261936k4ca79f30i5051be4ae8f11699@mail.gmail.com>
References: <BLU137-W143E886FA45D9D848217FA93F70@phx.gbl> <006b01ca2692$fcda3500$f68e9f00$@net> <00a001ca26b5$1b6e9b10$524bd130$@net> <1028365c0908261936k4ca79f30i5051be4ae8f11699@mail.gmail.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 27 Aug 2009 06:45:49.0331 (UTC) FILETIME=[034CCE30:01CA26E2]
X-Mailman-Approved-At: Thu, 27 Aug 2009 00:23:38 -0700
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 06:45:44 -0000

Yes, this looks good. 




> Date: Wed, 26 Aug 2009 22:36:42 -0400
> Subject: Re: draft-zorn-radius-pkmv1-05.txt
> From: d3e3e3@gmail.com
> To: gwz@net-zen.net
> CC: bernard_aboba@hotmail.com; ietf@ietf.org; secdir@ietf.org
> 
> Looks OK to me,
> Donald
> 
> On Wed, Aug 26, 2009 at 9:24 PM, Glen Zorn<gwz@net-zen.net> wrote:
> > …
> > 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?
> > …