RE: RADIUS IANA -03

[Bernard Aboba <aboba@internaut.com>]

> The "situation" as I understand it is that people have appropriated type
> codes, ignoring IETF process.  This situation continues w/the Chivba
> draft & all this draft does is try to justify these violations, both
> after and before the fact.  The right thing to do in this document (if
> we're really interested in interoperability, rather than some type of
> organizational exercise in CYA) is to reserve the proprietary,
> unassigned type codes (including those used by the Chiba draft) pending
> a standards-track document fully describing their usage.

The draft does reserve the proprietary unassigned type codes, (with the
exception of the Chiba ones). Latest version is available here:

http://www.ietf.org/internet-drafts/draft-aboba-radius-iana-04.txt

With respect to draft-chiba, the issue is whether the document should be
Standards Track or Informational.

My personal vote is for Informational, because there are substantial
security issues with deployed implementations of this protocol. Things
like no replay protection, and no ability to determine whether the RADIUS server is
actually authorized to delete or change authorizations. These aren't small
things.

We've patched them up as best we could, but the reality is that existing
deployments have the vulnerabilities described in the Section 5, Security
Considerations:

http://www.drizzle.com/~aboba/IEEE/draft-chiba-radius-dynamic-authorization-11.txt

In addition, I would argue that the message sequence outlined in the
document is less than desirable, because it creates a semantic ambiguity
in whether attributes are used for identification or authorization
purposes.

If this were a standards track document, we'd probably have to
insist that it adopt the Diameter approach to disconnect and authorization
change -- having the server send a request that then starts a conventional
Access-Request/Reply sequence. This is considerably cleaner, because
attribute semantics would be well defined.