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

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

Nagi writes...

> *only* the end points who wish to understand the sub-types need to
> implement the parsing code ( almost similar to VSA parsing). Radius
> proxies treat these sub-types as a single unknown TLV.   That is
> acceptable, IMO.

I guess as long as the policy is to blithely ignore unknown attributes.
That might be an acceptable policy for a proxy, under certain
circumstances.  Recall that RADIUS clients MAY handle an unknown
attribute by treating the packet as if it were an Access-Reject.

There is almost always a policy decision to be made between the
interests of transparent plug and play and the interests of strict
security.

So are you saying that it's OK to treat a sub-class of RADIUS standard
attributes as if they were VSAs, in that only RADIUS product from
certain vendors who choose to support this functionality need to be able
to parse the attributes?  I think an attribute is either of limited
scope of application (a VSA), or it is of general applicability and all
RADIUS implementations SHOULD understand it.

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