RFC 2865 compatibility

[Bernard Aboba <aboba@internaut.com>]

> If all NAS's are not forced to upgrade, how will the server know whether
> it can include User-Alias?

Thank you for bringing up this very important issue, Barney.

RFC 2865 states in Section 5:

A RADIUS server MAY ignore Attributes with an unknown Type.
A RADIUS client MAY ignore Attributes with an unknown Type.

This means that if a new attribute cannot be safely ignored there
is a problem. An example would be a filter rule that if ignored, would
result in a security vulnerability.  In such a situation, the
security-critical attribute could be ignored by the RADIUS client,
granting the user filter-free access without the RADIUS server having
any inkling what has happened.  Not good.

RADIUS client and server configuration cannot fix this problem in a
scalable way.  In a large network it is not always possible to keep
track of the capabilities of every RADIUS client and if clients
ignore security-critical attributes without sending an error message
(as is allowable under RFC 2865), then some very ugly situations
can arise.

There are two possible avenues of repair:

a) Describe how the attribute can be safely ignored.  For example, the
RADIUS server might send *both* a new and old attribute and be guaranteed
some level of safety in case the new attribute is ignored.  Or the RADIUS
server could ignore the attribute when sent by a RADIUS client, with no
ill effect.

b) Respecify the attribute in a way that its use can be negotiated and
the RADIUS server can be guaranteed that if sent and not understood, the
right thing will happen (e.g. no service will be granted to the user).
There are proposals on the table that provide for this (e.g. Jari's
proposal for extended attributes).

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