RE: RADIUS keywrap attributes

["Glen Zorn \(gwz\)" <gwz@cisco.com>]

Nelson, David <mailto:dnelson@enterasys.com> supposedly scribbled:

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

Hmm.  Since RADIUS clients and servers are required to ignore unknown packet types (by specification, not tradition), I don't really understand why this same logic would not apply to the protocol in general. 
 
Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

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