RE: FW: HTTP digest and RADIUS; new version of the Sterman draft

["Nelson, David" <dnelson@enterasys.com>]

Alan DeKok writes...

> > The technical arguments that I have heard (and advanced) against
> > sub-types are that it changes the RADIUS architecture (simple TLV
> > structures), requires changes to the RADIUS dictionary, and breaks
> > backwards compatibility with a large deployed base of RADIUS
products.
> 
>   ... which we already know won't understand the new attributes.

Yes, but they could by updating their dictionary file (or equivalent
dictionary implementation).  I guess that was the point of my admittedly
imperfect analogy with SNMP -- data dictionary driven protocol parsing,
as opposed to code driven parsing.  I argue that adding sub-types means
changing the parsing code.  RADIUS implementations have been designed
from day-one to deal with new attributes, in the standard single-layer
TLV format.

I do understand that a NAS or RADIUS server that actually wants to do
something useful with the semantics of a new attribute will need added
or changed code somewhere, even if not in the core RADIUS protocol
engine.

>   The only hard requirement I can see for backwards compatibility is
> that old servers MUST be able to act as proxies for requests with new
> attributes.  We've seen this behaviour with EAP-Message, so we know it
> works.

I suppose I draw a distinction that not everyone will agree with.  EAPOL
frames are not RADIUS attributes in the classic sense of the definition.
I see tunneling EAP in RADIUS as a natural thing to do.  Many of the
other proposed new attributes seem like any other RADIUS attribute to
me, and thus I resist the notion of tunneling, or sub-typing.

>   If tagged attributes are sufficient, then I see no reason to add new
> sub-types.

That works for me.  Let's see if it works for others.

-- Dave



--
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/>