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

Donald Eastlake <d3e3e3@gmail.com> Thu, 20 August 2009 03:46 UTC

Return-Path: <d3e3e3@gmail.com>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 515AF3A6992; Wed, 19 Aug 2009 20:46:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id 5iRssPYH3wMr; Wed, 19 Aug 2009 20:46:39 -0700 (PDT)
Received: from mail-ew0-f206.google.com (mail-ew0-f206.google.com []) by core3.amsl.com (Postfix) with ESMTP id DDDD23A6CC3; Wed, 19 Aug 2009 20:46:38 -0700 (PDT)
Received: by ewy2 with SMTP id 2so1626822ewy.43 for <multiple recipients>; Wed, 19 Aug 2009 20:46:28 -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=Maw1wDGAGoIuBvohk9UjYkXK2tAVE+BiRg+qWRCd/DI=; b=O6d9jumTiAa7v3KfIArvzZ1MWxAWDc5/XTG4x85Py4QzjeM+UzbrapzaPLH385esyn I4fDh5vMKy9QIPrIsBy9ZqoWlOeG2gHY4FdYmneDBpbaImENtHGC0Cyal0mYYeOI4IYy TSfSJbCIZQNCxc/y0mCrJnXMEgrUOlPYI7Jbc=
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=OL49p0M4KYlW+Zc3v8veDKF+vl7my9Z5G7g9HWjy5jeQI1GscdLRmfcypopum3EvAX lTc8JkjeeVz9uTDVpX9xSls9x5ZxrClumRI5A3uDy8+GZomXymSAMOoQ2FMVwnf9HiUh PdN3u/MfqARhVKTbsNTvSqMt1V+x0Wq3KWhKI=
MIME-Version: 1.0
Received: by with SMTP id u50mr1731517wee.73.1250739987617; Wed, 19 Aug 2009 20:46:27 -0700 (PDT)
Date: Wed, 19 Aug 2009 23:46:27 -0400
Message-ID: <1028365c0908192046v39447878ha8c9459743ad8495@mail.gmail.com>
From: Donald Eastlake <d3e3e3@gmail.com>
To: IETF Discussion <ietf@ietf.org>, secdir@ietf.org, Glen Zorn <gwz@net-zen.net>, Dan Romascanu <dromasca@avaya.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: [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, 20 Aug 2009 03:46:40 -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.  Document editors and WG chairs should treat these comments just
like any other last call comments.

This document defines seven RADIUS Attributes to support the
implementation of 802.16 (WiMax) PKMv1 (Privacy Key Management version
1). I would guess that RADIUS can be used between the 802.16 Base
Station and an authorization server but I don't know how you could
tell. Maybe I missed it but it looks like the RADIUS protocol isn't
mentioned anywhere in 802.16-2004. From the text in some of these
RADIUS attribute descriptions, it appears that they are not used
between the Subscriber Station and the Base Stations but may be the
basis of 802.16 Attributes that are used on that hop. Given this, I
think a paragraph is needed (maybe even accompanied by a little ASCII
art) at the beginning show what's going on would be useful.

Many document have security considerations section that only refer to
other documents and may be missing specifics to the document contents.
I think this document has the opposite problem good security specifics
in the security consideration section but could usefully add
references to the 802.16-2004 and RADiUS security sections.

The security considerations section rightly warns to protect against
modification of the PKM-Auth-Key attribute. But is it really clear
there is no problem with modification of the Security Association ID
attribute or the attribute listing cryptosuites?

The wording in Sections 3.1 and 3.2 see to almost be designed to allow
the possibility of the multiple *-Cert Attributes carrying a
certificate to appear in more than one Access-Request message. But I
would assume that's not meaningful and/or was not intended to allow

The table of attributes in Section 4 that gives the number of times
each attribute can occur in different message types seems to have
problems. Since there is no key giving it another meaning, I assume
"0-1" means zero or one. But PKM-SS-Cert and PKM-CA-Cert are described
and possibly occurring multiple times due to fragmentation of
certificates. If the table is supposed to be in terms of logical
attributes so that multiple PKM-SS-Cert attributes only count as one
if they have parts of one certificate, then the table should say so.
On the other hand, the PKM-SA-Descriptor attribute is shown as "0+",
which presumably means zero or more, but the text description in 3.6
clearly says it can occur one or more times, which presumably would be
written "1+". This whole table need to be carefully checked, the
inconsistencies resolved, and it should be clear if literal binary
attributes or some sort of logical aggregate attributes (in the case
of the "Cert" attributes at least), is being counted.

The text between the Section 6. header line and the Section 6.1 header
line as well as the Section 6.1 header line itself seem superfluous
and can be deleted.

I think this document still needs a little more work.

 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA