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

"Glen Zorn" <gwz@net-zen.net> Mon, 24 August 2009 17:16 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 6AC0E28C2C1 for <secdir@core3.amsl.com>; Mon, 24 Aug 2009 10:16:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.828
X-Spam-Level:
X-Spam-Status: No, score=-0.828 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_05=-1.11]
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 Z3ZMXtVjoZxF for <secdir@core3.amsl.com>; Mon, 24 Aug 2009 10:16:24 -0700 (PDT)
Received: from smtpout09.prod.mesa1.secureserver.net (smtpout09-01.prod.mesa1.secureserver.net [64.202.165.14]) by core3.amsl.com (Postfix) with SMTP id 41C3A28C16F for <secdir@ietf.org>; Mon, 24 Aug 2009 10:16:24 -0700 (PDT)
Received: (qmail 3448 invoked from network); 24 Aug 2009 17:16:27 -0000
Received: from unknown (71.231.55.1) by smtpout09.prod.mesa1.secureserver.net (64.202.165.14) with ESMTP; 24 Aug 2009 17:16:26 -0000
From: "Glen Zorn" <gwz@net-zen.net>
To: "'Donald Eastlake'" <d3e3e3@gmail.com>
References: <1028365c0908192046v39447878ha8c9459743ad8495@mail.gmail.com>
In-Reply-To: <1028365c0908192046v39447878ha8c9459743ad8495@mail.gmail.com>
Date: Mon, 24 Aug 2009 10:16:03 -0700
Organization: Network Zen
Message-ID: <00b701ca24de$8f53e4a0$adfbade0$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcohSMzAFHIb0qpxTrush0QZed5TLgC7jPbg
Content-Language: en-us
Cc: 'Dan Romascanu' <dromasca@avaya.com>, 'IETF Discussion' <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: Mon, 24 Aug 2009 17:16:25 -0000

Donald Eastlake [mailto:d3e3e3@gmail.com] writes:

> 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. 

Sorry for the rather slow response, but I honestly didn't know what to say.

> 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.

Your comments seem to suggest a lack of familiarity with RFC 2865 and the
RADIUS protocol in general.  Leaving aside the question of how one could
expect to usefully review a document that _extends_ a protocol w/o
understanding the protocol being extended, RADIUS is only defined between a
NAS (in this case, an 802.16 Base Station) and a RADIUS server.  

 
> 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.

I'm not at all sure what 802.16 security has to do with RADIUS, but I guess
I can add a reference to RFC 2869 in the Security Considerations section.

> 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?

No, apparently not.  I had originally thought that modifying the list of
supported cryptosuites would just result in DoS, but that's not right.  I'll
fix it.

> 
> 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
> that.

There is no way to do such a thing in standard RADIUS.

> 
> 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+". 

The relevant text from section 3.6 says "One or more instances of the
PKM-SA-Descriptor Attribute MAY occur in an Access-Accept message."  RFC
2119 says about the keyword "MAY", "This word, or the adjective "OPTIONAL",
mean that an item is truly optional"; this says to me that zero, one or more
instances of the PKM-SA-Descriptor Attribute can be in an  Access-Accept
message, just in a more compact and formal way.  If this is not clear,
however, I'm open to suggestions for alternate text.
 
> 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.

I can add notes to the table regarding the "logical" vs. "physical" nature
of the PKM-*-Cert Attributes, as well as a key to the meaning of "0+", etc.
Is that OK?

> 
> 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.

Fine.

...