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

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

<re-sending>

Wolfgang Beck writes...

> I could live without sub-attributes but I haven't heard a really
> convincing technical argument against them.

Well, I guess that begs the question of what constitutes "convincing"?
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.

I would offer an analogy.  Adding sub-types to RADIUS would be similar
to adding some sub-types (protocol-encoded information) as the data
value of an ASN.1 varbind in SNMP.  It is "tunneling" one protocol in
another.  In the case of SNMP, as in the case of RADIUS, we have a
simple and limited set of data types, and single level of TLV structure.
With SNMP, MIBs can be enrolled in SNMP management stations by a
mechanical process because you can't re-define the ASN.1/BER data
formats used in SNMP.  Should we settle for any less in RADIUS?

The one explicit case where we do tunnel a protocol in RADIUS is the
EAP-Message attribute.  If the information contained in the proposed
sub-types were as disparate from other RADIUS attributes as EAP frames
from RADIUS attributes, following this precedent would be reasonable.
However the sub-type attributes are not in any fundamental way different
from "normal" RADIUS attributes.  So what are the reasons offered for
treating them differently?  One reason seems to be "the convenience of
grouping".  RADIUS already has a recognized method of grouping
attributes.  A second reason seems to be "we will run out of attribute
number space".  Let's take a head count of new attributes that fall
within the scope of the charter before we deiced that, shall we?

While I do find the backwards compatibility reasons for NOT allowing
sub-types to be compelling, I don't find the two reasons I have listed
for allowing them to be compelling.

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