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

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

Avi Lior writes...

> Why is that any different then encoding a string with AVP as in X.500
> encoding "a=1 b=3".  If that type of encoding is acceptable so should
the
> other.

[DBN] It IS different, and I don't know if I can come up with any
additional or different explanations of why, beyond what I have already
written on this topic.  But let me try:  You could, given the length
constraints of attributes, create an attribute of base-type
undistinguished octets (String) and include within the attribute value
field an entire IPv4 packet.  I think it is clear, in this somewhat
extreme example, that a string is not a simple string but a "stealth
protocol".  I am opposed to hiding "stealth protocols" in RADIUS
attributes.  We have one explicit example of an encapsulated protocol --
the EAP-Message attribute -- and that's fine because it is reasonable,
necessary and explicit. It is also fine because EAP messages are clearly
out-of-scope for RADIUS.  No RADIUS product would want to attempt to
parse them -- they are "foreign" entities.

The example you give in support of what I still call sub-types is X.500
addresses.  I have previously used a similar example of DNS FQDNs.  Each
of these is a multi-part data type.  The distinction is that they are
NOT a compendium of attributes that are within the scope of AAA, grouped
together.  They are, to a large extent, an opaque data type that the
RADIUS protocol engine itself does not attempt to parse.  They are
forwarded to external entities, such as name resolution engines, that
process them, and potentially return some useful result.  The only
exception to this, that I'm aware of, is the NAI usages, in which a
RADIUS proxy may parse the "realm" portion of an NAI to determine the
next hop server address.

> The point which is made over and over is that the attribute is to be
> interrperted only by endpoints and these would have code beyond the
> dictionary anyway to parse further.

[DBN] I fully understand that point, however I reject it.  This is not
quite the same situation as the EAPOL messages we encapsulate in
EAP-Message attributes. The items being debated are clearly, IMHO, AAA
attributes fully within the scope of RADIUS and Diameter.  Therefore any
attempt to "group" them in a fashion opaque to the majority of RADIUS
product simply fragments the multi-vendor interoperability of RADIUS.
The argument that only the RADIUS clients and servers from companies
that are promoting these proposals need to be able to "play", i.e. to be
able to parse the attributes if they wish, is antithetical to the
architecture of RADIUS.  Any such "limited scope" attributes MUST, IMHO,
be VSAs.  Otherwise we no longer have a single, interoperable RADIUS
standard.

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