FWD: Re: IEEE, Radius, need a better relationship

[Thomas Narten <narten@us.ibm.com>]

I was putting together a note with the above subject, but I think
bernard's response to my attempt is a good starting point for
framing some issues.

Thomas
------- Forwarded Message

From: Bernard Aboba <aboba@internaut.com>
To: Thomas Narten <narten@us.ibm.com>
cc: Allison Mankin <mankin@psg.com>, <david@mitton.com>
Date: Thu, 30 Jan 2003 10:30:46 -0800 (PST)
Subject: Re: IEEE, Radius, need a better relationship

> I was putting the following together for the IESG and realized it
> would be better to get your help first in getting some of the details
> right. I can't recally the details of the copyright issue now (i.e.,
> which technology you worry the IETF won't be able to even do
> derivative works on).
>
> ================
>
> After speaking with Bernard, it seems clear there is serious trouble
> brewing that probably warrants a fairly formal liaison type message
> from the IETF to the IEEE. Bernard will no doubt clarify and add
> detail.
>
> 1) IEEE appears to be redefining the radius protocol in 802.1f. They
> have found a loop hole in the IANA considerations and have obtained a
> code point (via FCFS) that allows them to extend the protocol
> itself. [XXX: more details about what was allocated] What they are
> doing is modifying the protocol itself, something we really want IETF
> review of. There have been review comments on the approach from IETF
> people within 802.1f, but they have been completely ignored.

Specifically, IEEE 802.11f has allocated two new Service-Type values.
Since Service-Type describes completely new uses of RADIUS, it is a unique
attribute, and FCFS is not an appropriate IANA allocation policy -- though
that is what RFC 2865 says. Using those new values, plus lots of new IEEE
vendor-specific values, they are using RADIUS to register Access Points
and key IPsec SAs, as an alternative to IKE. They have also changed the
meaning of existing RADIUS attributes, using the User-Password attribute
in order to do a change-password operation. David Mitton has found some
other issues as well -- such as requiring the RADIUS server to be
stateful, which most current implementations are not.

Myself, Jesse Walker, Russ Housley and others have commented on the IEEE
802.11f draft at various stages, complaining about the RADIUS usage.
However, I had not voted in the previous ballot, so was not eligible to
participate in sponsor ballot and so my comments were discarded.

I then sent some email to Dave Bagby, Chair of IEEE 802.11f in order to
request that the new usage at least be published as an RFC. He responded,
and indicated he would take it up with the 802.11 Chair, Stuart Kerry, but
there has been no action yet.

The end result of this is that we have an extension to RADIUS that is not
publicly documented, is not available to IETF participants (as a former
IEEE 802.11 voter, I still have the archive password and can make it
available to you if you want to read it), and is copyright by IEEE 802.11.

That means that even if we like the extension, we would be unable to
duplicate large portions of the text (e.g. derivative work) in a
future Diameter specification. That makes it difficult to maintain
RADIUS-Diameter backward compatibility, and could hurt the viability of
Diameter in 802.11 uses (such as what 3GPP was talking about), assuming
that the extension catches on.

> IANA allocated the code point a week or so again (out of FCFS
> space). I wonder if it is possible to revoke that or put in some sort
> of request  to block or reconsider?
>
> 2) 802.1i is apparently including a lot of text that is radius
> specific in its documents. I.e., instead of saying generic things and
> including non-normative refererences to radius (as examples) the text
> includes specific references that implies a radius-only solution is
> mandated. Bernard indicated that it wasn't even clear that one could
> use diameter and be compliant.

Some of this may just be sloppy editing -- but it is worthwhile to ask
Dave Halasz in our next conf. call whether AAA references are considered
normative. IEEE 802.1aa has a clear statement that there are no AAA
requirements at all -- and that Appendices talking about AAA are
informative only. If IEEE 802.11i would include a similar statement, that
would help a lot.

> 3) We may be heading towards a log jam regarding copyrights on
> documents. IEEE doesn't really make in-progress draft documents
> available publically. In some of the WGs, the issue has been
> side-stepped because some WGs have agreed to allow this and the WG
> chairs have beeing giving OKs to making documents available.

The Chair of IEEE 802.1, Tony Jeffree, agreed to provide access to the
IEEE 802.1 archive to the EAP WG. He has also been allowing the EAP WG to
recommend resolution to EAP-related comments made in the IEEE 802.1aa
ballots, and allowing submission of ballot comments from EAP WG
participants. Also, Tony has for quite a while agreed to publish all SNMP
MIBs and AAA-related documents (such as draft-congdon-radius-8021x-22) as
IETF drafts to get around copyright issues. He was able to clear this with
IEEE 802 -- so that the reluctance of IEEE 802.11 appears to *not* be the
result of a global IEEE 802 policy -- but something unique to IEEE 802.11.

As an example, IEEE 802.11i refused to make the specification, which
includes sections relating to EAP key hierarchy available for analysis by
security experts. The spec is still restricted -- but without access, it
might be difficult for IETF reviewers to be able to determine whether they
believe that the EAP Keying Framework document we are developing in EAP WG
is really secure or not.

> But this
> varies from WG to WG and not everyone is so open. In the case of the
> radius extensions above, I believe (correct me if I have this wrong
> Bernard) the documents aren't available and it is not even clear the
> the IETF will ever be allowed to have access to them.

I believe this is accurate, yes. I even got a note from Dave Bagby
scolding me for giving out copies to the security community. They're not
quite as bad as the RIAA, but close :)

> Going forward:
>
> I think we need to consider sending a liaison statement to IEEE
> indicating that we are unhappy with 1) and believe an end-run is being
> done. We would like IEEE to reconsider what they are doing and
> coordinate better with the IETF (i.e, have the work reviewed/published
> in the IETF), as radius is an IETF technology.

Since this appears to be an IEEE 802.11 policy more than IEEE 802 as a
whole, we should consider who to send it to and how they will react. It
might be a good idea to talk to Tony Jeffree of IEEE 802.1 first, since he
has already implemented what we want IEEE 802 to do globally -- without
any objections from IEEE 802. In fact, Tony might be a very helpful ally
-- he is very influential in IEEE 802 and might help us to get the policy
he has put in place widely adopted within IEEE 802.

> The note could also indicate that we are moving towards diameter and
> are very uncomfortable with putting more into radius and continuing to
> use it. While we do recognize is use in legacy systems, we need to
> carefully consider any extensions and be working towards transtioning
> to diameter.

Actually, I'd shoot for "AAA agnostic" specifications -- specs that do not
require implementation of any particular AAA technology. RADIUS today is
pervasive, and until AAA WG finishes work on the applications (MIP,
NASREQ, EAP, CMS) we don't have a viable alternative to present.

> We request a meeting to discuss these issues and more general issues
> about how to have the two groups work together better (e.g., possibly
> by setting up more formal relationships).

We might also start by scheduling a conf. call with Tony Jeffree to
discuss the topic and get his opinion on how to proceed with IEEE 802 in
general.

> Separately, I also think we need a more clear plan for what we are
> doing with radius. I.e., what types of extensions, the review process,
> etc. This also ties in with the zorn appeal and
> draft-chiba-radius-dynamic-authorization-05.txt. In talking with tom
> hiller and 3GPP2, for instance, 3gpp2 wants this document. Tom was
> quite concerned about it being yanked from the RFC editor queue and
> whether that meant trouble for the document ever being published (or
> what sort of delay that implied).

In that particular case, 3GPP2 had originally referenced NASREQ, but had
to move to RADIUS and draft-chiba when the delivery slipped. However, I
also expect takeup of draft-chiba within IEEE 802 for similar reasons.
Cisco has indicated some interest in Diameter on 802.11 access points, but
is held up pending delivery of NASREQ and EAP applications.

Overall though, we should be realistic about how long it will take to get
significant Diameter takeup. I believe it will make a big difference once
the open source Diameter client and server implementations are done, since
several 802.11 APs now run Linux and could easily incorporate Diameter if
it were available. However, I do not know of any Linux APs that even
include support for RADIUS over IPsec, to give you an idea of what we are
up against.

Maybe the best way to get Diameter takeup is to publish a RADIUS Security
Analysis document and get some press to write about it. I can assure that
such a document can be made sufficiently scary to result in an uptake of
interest in Diameter :)

> I also chatted with Tom Hiller and made it clear that 3GPP2 needs to
> have an up-to-date dependency document (ala what 3GPP has) and that we
> need to using that document to talk about specific issues and be sure
> we are in sync on what is happening with any dependencies. I also
> pointed out that the current relationship is not really working
> because there is insufficient dialog among the right people. E.g., the
> lobbing of official liaison statements to us isn't really
> effective. If we get a statement that we didn't know was coming,
> that's probably an indication that things are broken. He seemed to
> agree and promised an update to the dependency in time for their next
> meeting (in two weeks). At that point, a conference call would
> probably be in order.
>
> Thomas
>

------- End of Forwarded Message