RE: [RADIUS FIXES] Authorize Only / RADIUS layering criteria

[<Pasi.Eronen@nokia.com>]

Emile van Bergen wrote
>
> Of course, if two parties (eg. a service provider and a
> roaming broker) contractually agree that the service provider
> sets class to a particular value in particular cases so that
> the roaming broker can perform some form of special accounting
> based on it, then that's a contractual issue between two
> parties that already need to have a contractual relationship
> (because they need a shared secret, and the service provider
> needs to pay the roaming broker, and so on).
> 
> But I'd say that that is entirely within the freedom granted
> by the standard that defines Class.

I'm not sure it is; RFC 2865 explicitly says that "The client
MUST NOT interpret the attribute locally."

Of course, IETF is not a protocol police, and two parties can
agree to do whatever they want. They could, for instance, agree
to send User-Name in EBCDIC character set instead of
ASCII/UTF-8.  But IMHO that would not be RADIUS as specified in
RFC 2865 anymore.

Although that example doesn't really make sense, it's not that
extreme. People are calling all sorts of things "RADIUS" just
because the packet format resembles something in RFC 2865.

Here an explicit layering model, saying that "these things are
part of the RADIUS transport layer" and "these other things you
must define in a RADIUS application layer" would help. (And most
of the attributes would probably belong in the "application
layer".)

Unfortunately, RFC 2865 mixes both the transport parts and
"network access authentication" application parts in the same
document, creating endless confusion when people would like to
use RADIUS transport parts for something like "PE-Based VPN
Discovery" (honest, I'm not making this up :-)

I'm not saying there's nothing wrong in using RADIUS for VPN
discovery; just that it would IMHO be more accurate to say that
they've developed a new protocol for VPN discovery that just
happens to run over RADIUS transport. After all, if they had
decided to use SOAP-over-HTTP for transport instead, we probably
wouldn't call the document "Using HTTP for PE-based VPN
Discovery" or "Using SOAP for PE-based VPN discovery", but
something like "PE-based VPN discovery protocol".

Best regards,
Pasi

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>