[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IEEE 802.11f Request for RADIUS NAS-Port-Type and Service-Type value allocation (fwd)
RADIUS attribute values are indeed first come, first served, according
to RFC 2865 IANA considerations section.
However, in the past we've also typically at least gotten a statement
saying what the values (or attributes) actually *do*. In most cases this need
only be a sentence or two, so it's hardly worth making a big deal over.
But values for the Service-Type attribute are a bit different. They define
entire new uses for the RADIUS protocol.
In this particular case, a new use of RADIUS is being defined for
registration and management of Access Points, and an existing attribute
(User-Password) is redefined.
Use of the allocated values (and the IEEE vendor-specific attributes
defined to go with them) is contained within the IEEE 802.11f specification Draft
5, which is not publicly available now, and will not be available for free
until 12 months after publication.
Copyright is vested in IEEE, so that it would not be possible to republish
the specification, or even adapt it for use in Diameter, without
permission. That's why in the past IEEE 802.1 has published their MIBs
and AAA related work as Internet-Drafts.
Asking the IETF to allocate AAA parameters for an "extension" that cannot
even be reviewed by IETF participants for 12-18 months without paying a
fee is somewhat over the top.
I suggest we invite David Bagby, Chair of IEEE 802.11f to our IEEE 802.11
Liason conference call on February 3, 2003.
BTW, for those of you interested in reading it, I've made it available at:
http://www.drizzle.com/~aboba/IEEE/80211f.pdf
============================================================================
Date: Wed, 11 Dec 2002 19:25:01 -0800
From: David Bagby <david.bagby@ieee.org>
To: Bernard Aboba <aboba@internaut.com>
Subject: RE: 802.11f/IETF liason issues
Bernard -
thanks for your email. I have been out for a couple of weeks and will not
be back to the office for a while (had to take a small schedule diversion
for some unanticipated surgery).
I'll see what we can do re your suggestions. Do you know how .1x got
around the IEEE copyright issues in order to put portions of the IEEE
draft in an IETF doc?
Dave
Date: Mon, 7 Oct 2002 13:09:56 -0700 (PDT)
From: Bernard Aboba <aboba@internaut.com>
To: randy@psg.com
Cc: john.loughney@nokia.com, david@mitton.com, mankin@isi.edu
Subject: Proposal for IEEE 802 usage of AAA attributes (fwd)
FYI... the issue of SDO usage of AAA attributes is not confined to
3GPP. IEEE is allocating attributes out of their vendor-specific space
(for 802.11f, and possibly other task groups, such as 802.1aa).
-----Original Message-----
From: CONGDON,PAUL (HP-Roseville,ex1) [mailto:paul_congdon@hp.com]
Sent: Sunday, October 06, 2002 1:57 PM
To: Bernard Aboba
Subject: RE: IEEE 802.1X and 802.1ad scenarios
Bernard,
Missed you in NOLA... Anyway, I did NOT present the following, but was
thinking about it. I'd be curious to hear your comments. Also, where
can we find a list of the 802.11 attributes being defined, and where are
they being specified?
Paul
On Fri, 17 Jan 2003, Michelle S. Cotton wrote:
> FYI too.
>
> The IANA made the registrations for the below request as they
> were for RADIUS Attribute Values, which according to RFC2865
> (section 6.2) are first-come, first-serve.
>
> Just informing you as a related topic.
>
> Michelle
>
>
> -----Original Message-----
> From: iesg-admin@ietf.org [mailto:iesg-admin@ietf.org]On Behalf Of Randy
> Bush
> Sent: Wednesday, January 15, 2003 10:59 PM
> To: iesg
> Subject: Fwd: IEEE 802.11f Request for RADIUS NAS-Port-Type and
> Service-Type value allocation (fwd)
>
>
> ------- start of forwarded message -------
> From: Bernard Aboba <aboba@internaut.com>
> To: randy@psg.com
> cc: mankin@psg.com
> Subject: Fwd: IEEE 802.11f Request for RADIUS NAS-Port-Type and Service-Type
> value allocation (fwd)
> Date: Wed, 15 Jan 2003 19:26:31 -0800 (PST)
>
> FYI.
>
> An interesting case of an SDO "extension" of an IETF protocol. IEEE 802.1
> has had a longstanding policy of co-publishing MIBs and AAA attributes as
> Internet-Drafts, so as to allow IETF review and comment.
>
> In this particular case, IEEE 802.11f is extending RADIUS for use in
> Internet Access Point Protocol (IAPP). This includes new values for
> existing attributes (below), new IEEE vendor-specific attributes and in
> some cases, redefinition of existing RADIUS attributes.
>
> So overall, this is more like an "extension" than just a "usage profile".
>
> As I had cc'd you, I had made a request of the IEEE 802.11f chair to
> allow IETF review of the "extension" but did not get a reply.
>
> Some amount of IETF review seems essential, even if it's only posting as
> an Internet Draft.
>
>
> ---------- Forwarded message ----------
> Date: Wed, 15 Jan 2003 18:24:18 -0500
> From: Robert Moskowitz <rgm@trusecure.com>
> To: IANA <iana@iana.org>
> Cc: Bernard Aboba <aboba@internaut.com>
> Subject: Fwd: IEEE 802.11f Request for RADIUS NAS-Port-Type and
> Service-Type value allocation
>
> I really need this expedited. We need to publish the next (and perhaps
> last) draft of 802.11f tomorrow by 5pm EST and we need these assignments.
>
> Perhaps Stuart was given old information on where to direct the request
> from the IANA pages...
>
> At the end is additional explanation from Justin McCann.
>
> >From: "Stuart Kerry" <stuart.kerry@philips.com>
> >To: <cdr@telemancy.com>, <acr@merit.edu>, <wsimpson@greendragon.com>,
> > <steve@livingston.com>
> >Cc: "John Vollbrecht" <jrv@interlinknetworks.com>,
> > "Bob O'Hara" <bob@bstormnetworks.com>,
> > "Robert Moskowitz" <rgm@trusecure.com>, <jrosdahl@ieee.org>,
> > "Dave Bagby" <david.bagby@ieee.org>,
> > "'Justin McCann'" <jmccann@karlnet.com>
> >Subject: IEEE 802.11f Request for RADIUS NAS-Port-Type and Service-Type
> >value allocation
> >Date: Mon, 13 Jan 2003 14:47:14 -0500
> >
> >
> >Carl, and other RADIUS authors,
> >
> >The members of IEEE 802.11 Task Group F (Recommended Practice for the
> >Inter-Access Point Protocol, aka IAPP) request that official values for
> >the following RADIUS attributes be allocated with the descriptions as
> >follows:
> >
> >Attribute Value Description
> >------------- -----------------
> >NAS-Port-Type IAPP
> >Service-Type IAPP-Register
> >Service-Type IAPP-AP-Check
> >
> >Our earlier attempts to have these attribute values allocated appear to
> >have gone through the wrong channels. We are trying to get a final draft
> >ratified, and are currently in session this week. We would like for
> >these values to be officially allocated immediately, if possible. If an
> >official allocation is not possible by Wednesday, in the interim we
> >would like to be informed of the "values-to-be", i.e. what will be the
> >official values when the official allocation is made.
> >
> >I request that you also send a copy of your reply to Justin McCann
> >(jmccann@karlnet.com) and Bob O'Hara (bob.ohara@ieee.org) on behalf of
> >the 802.11 Task Group.
> >
> >Thank you for your time,
> > Stuart J. Kerry
> > IEEE 802.11 Chair
>
> From: "Justin McCann" <jmccann@karlnet.com>
> To: "Robert Moskowitz" <rgm@trusecure.com>
> Subject: FW: IEEE 802.11f Request for RADIUS NAS-Port-Type and Service-Type
> value allocation
> Date: Wed, 15 Jan 2003 17:33:25 -0500
>
>
> We are adding new VALUES to already existing RADIUS ATTRIBUTES.
>
> We need the new NAS-Port-Type value of "IAPP" to distinguish the 'users'
> coming in for IAPP from regular dial-in/ISDN/Wireless users (which may
> be a user name like 'jmccann' for dialin, or a STA's MAC Address
> '02-03-04-05-06-07' for some currently shipping proprietary 802.11
> authentication mechanisms).
>
> We need the new Service-Type value of "IAPP-Register" to denote that the
> service that is being offered to the 'user' in question is for
> registering the AP/BSSID with the RADIUS Server (through the IAPP
> extension) so that IAPP interaction with the RADIUS extension will work.
>
> We need the new Service-Type value of "IAPP-AP-Check" to denote that the
> service that is being offered to the 'user' in question is to check if
> the RADIUS Client (New AP) can have a valid security association with
> the 'user' (Old AP/BSSID).
>
> Does this help?
>
> Justin
>
>
> Robert Moskowitz
> Senior Technical Director
> ICSA Labs
> (248) 968-9809
> Fax: (248) 968-2824
> rgm@trusecure.com
>
> There's no limit to what can be accomplished
> if it doesn't matter who gets the credit
>
>
> ------- end of forwarded message -------
>
>