Re: draft-zorn-radius-pkmv1-05.txt
Bernard Aboba <bernard_aboba@hotmail.com> Wed, 26 August 2009 16:50 UTC
Return-Path: <bernard_aboba@hotmail.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C1293A67F9 for <ietf@core3.amsl.com>; Wed, 26 Aug 2009 09:50:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.132
X-Spam-Level:
X-Spam-Status: No, score=0.132 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_40=-0.185, 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 g2kEelCbE2rX for <ietf@core3.amsl.com>; Wed, 26 Aug 2009 09:50:26 -0700 (PDT)
Received: from blu0-omc2-s24.blu0.hotmail.com (blu0-omc2-s24.blu0.hotmail.com [65.55.111.99]) by core3.amsl.com (Postfix) with ESMTP id A6E3D3A67C0 for <ietf@ietf.org>; Wed, 26 Aug 2009 09:50:26 -0700 (PDT)
Received: from BLU137-W14 ([65.55.111.73]) by blu0-omc2-s24.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 26 Aug 2009 09:50:33 -0700
Message-ID: <BLU137-W143E886FA45D9D848217FA93F70@phx.gbl>
Content-Type: multipart/alternative; boundary="_7632c264-b72c-43a1-bb4c-a5799f147e3b_"
X-Originating-IP: [192.160.73.254]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: ietf@ietf.org, gwz@net-zen.net, d3e3e3@gmail.com
Subject: Re: draft-zorn-radius-pkmv1-05.txt
Date: Wed, 26 Aug 2009 09:50:33 -0700
Importance: Normal
MIME-Version: 1.0
X-OriginalArrivalTime: 26 Aug 2009 16:50:33.0218 (UTC) FILETIME=[53C4D620:01CA266D]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Aug 2009 16:50:28 -0000
Donald Eastlake said: "Doing a little more research, 802.16e-2005, which you don't reference, does begin to touch on this by at least specifying how EAP fits into 802.16." [BA] As I understand it, this document is focused entirely on PKMv1, which does not support EAP. So it does not apply to IEEE 802.16e-2005. That's quite an important point, since there are existing specifications (from WiMAX forum) that deal extensively with IEEE 802.16e/AAA interactions. If that point is not very clear from the document, then it needs to be. [Donald Eastlake] If above you are saying that the security of these new RADIUS attributes can be evaluated entirely based on a knowledge of RADIUS, I do not agree with this. [BA] 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. 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. [Donald Eastlake] If above, you are saying is that there is no need for there to be some explanation, in your draft or in some document referenced by it, of how RADIUS fits into 802.16 and that people who don't have an a priori knowledge of this should just keep their noses out of your document, I don't agree with that either. [BA] I would suggest that the document could reference the RADIUS specifications from WiMAX forum that relate to IEEE 802.16e-2005 to make it clear that operation with that updated specification is out of scope. [Donald Eastlake] "RADIUS can be used by an IEEE 802.16 Base Station, acting as an EAP Authenticator, to communicate with a remote Authentication Server to authenticate 802.16 Subscriber Stations and support 802.16 Privacy Key Management Version 1. This document defines a set of additional RADIUS Attributes which are designed to enable this support." [BA] Since PKMv1 does not support EAP, mentioning EAP in the abstract doesn't make sense. [Donald Eastlake] Is it really such a burden, to provide some security context for what you are doing, to say something like: "Security consideration for IEEE 802.16 appear in Section 7 of 802.16-2004 and of 802.16e-2005. Security considerations for RADIUS extensions appear in RFC 2869." or the like? " [BA] Since this document applies only to PKMv1, mentioning IEEE 802.16e would probably be confusing. Mentioning RFC 3579 (which supercedes RFC 2869 with respect to EAP/RADIUS) might make sense. EMAILING FOR THE LEAST WORST BAD Join me
- draft-zorn-radius-pkmv1-05.txt Donald Eastlake
- RE: draft-zorn-radius-pkmv1-05.txt Glen Zorn
- Re: draft-zorn-radius-pkmv1-05.txt Donald Eastlake
- Re: draft-zorn-radius-pkmv1-05.txt Bernard Aboba
- RE: draft-zorn-radius-pkmv1-05.txt Glen Zorn
- RE: draft-zorn-radius-pkmv1-05.txt Glen Zorn
- RE: draft-zorn-radius-pkmv1-05.txt Glen Zorn
- RE: draft-zorn-radius-pkmv1-05.txt Glen Zorn
- Re: draft-zorn-radius-pkmv1-05.txt Donald Eastlake
- Re: draft-zorn-radius-pkmv1-05.txt Donald Eastlake
- RE: draft-zorn-radius-pkmv1-05.txt Bernard Aboba