RE: RADIUS keywrap attributes

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

Glen Zorn writes...

> > So yes, keying attributes are within the RADEXT WG charter.
> 
> I suppose that, as David mentioned, this is a matter that is open to
> interpretation.  However, the current charter states that "No new
security
> mechanisms will be defined for protecting RADIUS."  Taking the
position
> (which I think reasonable) that RADIUS includes attributes and their
> allowable contents, it would seem to me that an attribute that
> cryptographically protects its contents is, in fact, a new security
> mechanism.

The intent of the charter prohibition on "new security mechanisms" was
to preclude the specification of incompatible revisions to RADIUS, that
would mandate upgrades to existing RADIUS implementations.  Since RADIUS
was designed without the benefit of a security method negotiation or
selection mechanism, it's likely quite difficult to add new PDU-level
security mechanisms in a backwards compatible fashion.  Since RADIUS
implementations have traditionally ignored new attributes, introduced
after the implementation, adding new security within the scope of a
single attribute does not present the same level of backwards
compatibility issues.

I would further suggest that *if* the issues at hand, i.e. modifications
to RADIUS to allow FIPS certification of systems that include RADIUS as
a component, are of sufficient importance to the Internet Community,
then we should consider amending the charter to allow that work in
RADEXT, understanding that backwards compatibility is still an issue.
It would, IMHO, be a Bad Idea (tm) for this work of this significance to
be undertaken as individual submissions, when we have a WG working in
this area.

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