Donald Eastlake [mailto:d3e3e3(_at_)gmail(_dot_)com] writes:
...
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.
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.
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
you don't reference, does begin to touch on this by at least
specifying how EAP fits into 802.16.
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.
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.
Why not?
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.)
As I mentioned above, that's because neither EAP nor RADIUS fit into
802.16-2004, which is the only standard that is relevant.
"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.
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...
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.
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.
As I mentioned above, 802.16e-2005 is completely irrelevant to this 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?
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.
...
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.
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.
Fine.
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".
Fine.
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
as 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.
The wording is OK but I would suggest making it one letter longer so
it starts "Zero or more ...".
Isn't that redundant?
...
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf