Subject: draft-zorn-radius-pkmv1-05.txt

From: Donald Eastlake <[email-masked]>
Date: Wed, 19 Aug 2009 23:46:27 -0400

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

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.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 24 Aug 2009 10:16:03 -0700

> like any other last call comments. 

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

> tell. 
> Maybe I missed it but it looks like the RADIUS protocol isn't

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.  

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

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

> would assume that's not meaningful and/or was not intended to allow

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

> 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

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?

> line as well as the Section 6.1 header line itself seem superfluous

Fine.

...

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 26 Aug 2009 09:22:27 -0400

Hi Glen,

See below...

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

OK.

> NAS (in this case, an 802.16 Base Station) and a RADIUS server.

You have missed my point entirely. To evaluate extensions to RADIUS
whose purpose is to support 802.16 seems to me to require not just a
knowledge of RAIDUS but some knowledge of how RADIUS fits into 802.16
and what is needed for RADIUS, with these extensions, to support
802.16 security. My point was that, so far as I can tell, how RADIUS
fits into 802.16 isn't documented in your draft or any document
referenced by it. 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.

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. 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. RFCs
are supposed to be for the Internet community and there is presumably
a reason that, for example, the RFC Editor requires acronyms that are
not widely known to be expanded. Of course, it is not necessary or
possible for most RFCs to be self contained and understandable in
isolation, but I think it is reasonable to expect them to refer to
other documents so that someone willing read enough and follow the
reference chains can get a clear picture of what is going on.

Thinking about it, I suggest that the Abstract be changed to something
like the following and a similar change be made in the Introduction.
(I note that the Introduction has a fairly long paragraph giving many
details about 802.16 PKMV1 while failing to shed much light on how
RADIUS or EAP fit into 802.16.)

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

If you make this change and, due to my inferior knowledge, I've made
any errors in the above paragraph, I'm sure you can fix it.

> I can add a reference to RFC 2869 in the Security Considerations section.

Because you are extending RADIUS for the express purpose of supporting
the 802.16 base station security function of authenticating subscriber
stations. This is a base station function whose mechanism, as far as I
can see, is glossed over in IEEE Standard 802.16-2004, which you
reference but which has absolutely no mention RADIUS, NAS, AAA, EAP,
Authentication Server, or anything along those lines. As above, by
further research, I found that the IEEE 802.16e-2005 amendment to
802.1-2004 at least mentions EAP. I believe that 802.16e-2005 should
be added to the references in the draft.

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?

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

That's what I thought and why I was puzzled as to why there was a more
complex wording that appears to permit this. I suppose it is just the
way the words struck me at the time I read them. But I would, instead
of

          If multiple PKM-SS-Cert
      Attributes are contained within an Access-Request packet, they
      MUST be in order and MUST be consecutive attributes in the packet.

have said

      These multiple PKM-SS-Cert Attributes MUST appear consecutively
      and in order within an Access-Request packet.

and similarly for PKM-CA-Cert.

Looking at this more closely now, I also think that the final "s"
should be removed from "instances of the PKM-SS-Cert Attributes" and
"instances of the PKM-CA-Cert Attributes".

>> as possibly occurring multiple times due to fragmentation of

The wording is OK but I would suggest making it one letter longer so
it starts "Zero or more ...".

>> This whole table needs to be carefully checked, the

Yes.

Thanks,
Donald

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 26 Aug 2009 09:58:49 -0700

...

> referenced by it. 

Right, that's because, as you have discovered & is the raison d'être of this
draft, RADIUS does not fit in with 802.16-2004 at all.  The relationship
between RADIUS and 802.16-2004 is basically identical to that between RADIUS
& PPP: RADIUS is a simple bolt-on allowing the centralization of
authentication & authorization data (& concomitant scaling & configuration
benefits).  You can search the set of RFCs defining PPP for a mention of
RADIUS, but that search would be in vain even though RADIUS has been (&
still is) used in virtually every PPP (PPPoE, PPPoA, ...) deployment.

> Doing a little more research, 802.16e-2005, which

I don't reference 802.16e-2005 because it's irrelevant to the draft; in
fact, it's an almost completely different protocol.  802.16-2004 defines
what is colloquially referred to as "fixed WiMAX", while 802.16e-2005 forms
the basis of "mobile WiMAX".  Mobile WiMAX has a lot more features, is
arguably more secure and is just generally sexier (mobility is all the rage,
you know ;-).  For all these reasons & undoubtedly more of which I am
unaware, the 802.16 WG has moved on & is no longer interested in fixed
WiMAX; that doesn't mean that it is not useful, though.  For example, the
public access network at the recent Olympic games in Beijing was based upon
802.11 using 802.16 backhaul to a pre-existing FDDI ring.  This made
networking basically the entire city a project of months rather than years,
since the nearly impossible task of running physical cables was unnecessary.
As it stands, fixed WiMAX is well suited for this kind of relatively static
application, since the appropriate credentials, authorization data, etc. can
be configured into the base stations and left pretty much alone.  However,
this kind of network design (.11<->.16<->some kind of wire) is also very
appropriate in more dynamic situations; for example, building access
networks in developing countries where the challenges & costs of running
physical cabling would be even more problematic.  Tack up a few .11/.16
gateways, plug in a .16 base station & voila!  Instant Internet.  So why not
just use mobile WiMAX & just not move (much ;-)?  The problem is that all
those sexy mobility features make designing, testing & manufacturing mobile
WiMAX equipment much more expensive (obviously a major consideration).  The
problem is that these instant networks are also quite dynamic & the base
stations themselves may not be conveniently located, so it would be nice to
not have to configure the BS every time somebody hangs a new .11/.16 gateway
on a tent pole or schoolhouse wall.  RADIUS support solves this problem for
fixed WiMAX in the same way it did for PPP.

> do not agree with this. 

Why not?

> If above, you are saying is that there is no

As I mentioned above, that's because neither EAP nor RADIUS fit into
802.16-2004, which is the only standard that is relevant.

> any errors in the above paragraph, I'm sure you can fix it.

Fine.  The thing is that, except for the "acting as an EAP Authenticator"
part (which is false), I can't really see how this imparts much more
information than the existing text (assuming familiarity w/RADIUS).  But if
it will make you happy...

> be added to the references in the draft.

As I mentioned above, 802.16e-2005 is completely irrelevant to this draft.  

> extensions appear in RFC 2869." or the like?

No, it's not much of a burden for me.  OTOH, I've read section 7 of
802.16-2004 a bunch of times & really haven't found anything like the
Security Considerations section of an RFC.  Furthermore, there's a huge
amount of stuff (e.g., traffic encryption key management, etc.) in there
that is, again, irrelevant to the draft and potentially confusing to the
non-experts that I assume would be the intended audience.

...

Fine.

Fine.

> it starts "Zero or more ...".

Isn't that redundant?

...

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 26 Aug 2009 18:40:37 -0700

...

OK.

...

> > of the PKM-*-Cert Attributes, as well as a key to the meaning of

You were right, the entries for the PKM*Cert Attributes should have been 0+
instead of 0-1.  The Table of Attributes now looks like this:

   The following table provides a guide to which attributes may be found
   in which kinds of packets, and in what quantity.

     Request Accept Reject Challenge Acct-Req  #   Attribute
     0+      0      0      0         0        TBD1 PKM-SS-Cert [Note 1]
     0+      0      0      0         0        TBD2 PKM-CA-Cert [Note 2]
     0       0-1    0      0         0        TBD3 PKM-Config-Settings
     0-1     0      0      0         0        TBD4 PKM-Cryptosuite-List
     0-1     0      0      0         0        TBD5 PKM-SAID
     0       0+     0      0         0        TBD6 PKM-SA-Descriptor
     0       0-1    0      0         0        TBD7 PKM-Auth-Key

   [Note 1]
      No more than one Subscriber Station Certificate may be transferred
      in an Access-Request packet.

   [Note 1]
      No more than one CA Certificate may be transferred in an Access-
      Request packet.

   The following table defines the meaning of the above table entries.

   0   This attribute MUST NOT be present in packet
   0+  Zero or more instances of this attribute MAY be present in packet
   0-1 Zero or one instance of this attribute MAY be present in packet
   1   Exactly one instance of this attribute MUST be present in packet

Is that OK?

...

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 26 Aug 2009 21:47:30 -0400

Yes, the changes below look good to me.

Thanks,
Donald