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? .
- [secdir] draft-zorn-radius-pkmv1-05.txt Donald Eastlake
- Re: [secdir] draft-zorn-radius-pkmv1-05.txt Glen Zorn
- Re: [secdir] draft-zorn-radius-pkmv1-05.txt Donald Eastlake
- Re: [secdir] draft-zorn-radius-pkmv1-05.txt Glen Zorn
- Re: [secdir] draft-zorn-radius-pkmv1-05.txt Glen Zorn
- Re: [secdir] draft-zorn-radius-pkmv1-05.txt Glen Zorn
- Re: [secdir] draft-zorn-radius-pkmv1-05.txt Donald Eastlake
- Re: [secdir] draft-zorn-radius-pkmv1-05.txt Donald Eastlake
- Re: [secdir] draft-zorn-radius-pkmv1-05.txt Bernard Aboba