[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RADIUS FIXES] Authorize Only / RADIUS layering criteria
Hi,
On Thu, Jul 28, 2005 at 02:47:41PM +0300, Pasi.Eronen@nokia.com wrote:
> 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.
Ok, agreed.
But if you let go of the concept of all equal clients and all equal
servers for a moment, but see a client undergoing rapid upgrade cycles
(every time new AAA functionality is added, with the exception of EAP),
followed by a chain of very static proxies, followed by servers with
backends of varied complexity and wildly different policies and
applications, then you get a different picture, with varying shades of
gray.
Some standards violations are much more serious than others. If a proxy
does not properly forward certain characters, characters which clients
and servers are allowed to use according to the standard, then that's
extremely serious.
If a service provider and a proxy operator agree to attach meaning to an
attribute that the standard says must not be interpreted, then that has
no consequence for any code or anyone else in the chain.
Cheers,
Emile.
--
E-Advies - Emile van Bergen emile@e-advies.nl
tel. +31 (0)70 3906153 http://www.e-advies.nl
--
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/>