RE: IEEE 802.11f Request for RADIUS NAS-Port-Type and Service-Typevalue allocation (fwd)

[Bernard Aboba <aboba@internaut.com>]

Yes, Dave for all the reasons you cite, IEEE 802.11f represents a
major change to RADIUS and IEEE 802.11f needs to file an IETF
draft for this, so that it can be reviewed.

In my opinion, this particular case stands out more than any of the
interactions with 3GPP -- at least the Diameter protocol was originally
conceived to be used for the purposes that 3GPP is looking at. Whereas
IEEE 802.11f is doing something dramatically different.

Is there any way to apply an IANA considerations change retro-actively?

On Tue, 21 Jan 2003, David Mitton wrote:

> I agree.
>
>          The Service-Type attribute really determines the type of service
> the rest of a RADIUS request is fulfilling.  And it determines the
> semantics of authorization the server must grant.
>
>          In the case of the TGf specification, they have describe a
> dynamic, stateful service which is not possible to provide from most RADIUS
> servers currently on the market.  (Most RADIUS servers have a fairly static
> database)
>
>          While I like the imagination they used in applying RADIUS to the
> problem, it's not a straightforward extention of current server
> functionality.  E.g. it can not be supported by merely adding a dictionary
> entry.  It requires a server to dynamically add and remove authentication
> objects and their parameters.
>
>          Wouldn't it be more appropriate if they filed an IETF draft/RFC on
> how this IEEE service is to be provided from a new and improved RADIUS
> server?  (that is describe the new service requirements)
>
> Dave.
>
>
> At 1/21/2003 01:49 PM -0800, Bernard Aboba wrote:
> >I am thinking that perhaps values of Service-Type should require a
> >specification, since they can be used to create entirely new
> >applications of RADIUS.
> >
> >David -- what do you think?
> >
> >On Tue, 21 Jan 2003, Michelle S. Cotton wrote:
> >
> > > Does the IANA then continue to allocate the attribute
> > > values via first-come, first serve basis or are you
> > > thinking something different.  Just double-checking.
> > >
> > > Thanks,
> > >
> > > Michelle
> > >
> > >
> > > -----Original Message-----
> > > From: iesg-admin@ietf.org [mailto:iesg-admin@ietf.org]On Behalf Of
> > > Bernard Aboba
> > > Sent: Monday, January 20, 2003 8:56 PM
> > > To: Michelle S. Cotton
> > > Cc: Randy Bush; iesg
> > > Subject: 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 -------
> > > >
> > > >
> > >
>