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

["Alan DeKok" <aland@ox.org>]

Bernard Aboba <aboba@internaut.com> wrote:
> In general, the server does not need to understand attributes that it
> sends, although the NAS does need to understand those it receives.
> If the server is sending an attribute it doesn't understand, why should
> the server require code changes?

  For attributes like IP addresses, text strings, or integers, I agree.

  For attributes which require some kind of calculation (e.g. md5, or
authentication calculations), the server *must* be upgraded.

> While one could argue that the server could just create a "String" type,
> the reality is that many RADIUS implementations don't support entering
> arbitrary binary data into "String" attribute types.

  Which is an implementation limitation, in *addition* to those
imposed by the RFC's.  Many attributes are defined or suggested to be
"undistinguished octets".  If a server does not support that, I don't
see why it would be fully RFC compliant.  And I don't see why we would
handcuff ourselves for new attributes, just because of non-compliant
implementations.  There's a simple solution: upgrade.

> Do we have concrete examples of where this will *not* work?

  My previous post mentioned IP addresses.  They also won't work (or
will be difficult) when the encapsulated data is undistinguished
octets.  If the first octet is 0x01, is it a tag, or part of the
atribute data?

  I've always thought that the design of tagged attributes was
problematic.  The tags may, or may not, exist.  The value in the first
octet may, or may not, be a tag.  You can't have tagged IP addresses.
Tagged integers can only be 24 bits, etc.

  All of these limitations and different ways of doing the same thing
make implementation more difficult.  I'm not a party to any draft
which proposes new attributes, but I will be implementing support for
them.  Being lazy, I'd rather see an attribute design which has a
simple implementation, than one which gives me 2-4 ways of doing the
same thing, and also prevents me from doing other things which are
currently possible.

  Alan DeKok.

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