[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Continued discussion of RADIUS Crypto-Agility



Dan Harkins writes ...

> On Wed, August 8, 2007 7:22 am, Leif Johansson wrote:
> [snip]
> > There are two fundamental ways to address this problem: reference
> > some work or roll your own. Radius+DTLS and RadSec fall into the
> > first category, keywrap falls into the second category.
> 
>   I have to disagree. Keywrap is not "roll your own". It uses RFC3394
> which itself describes a NIST specification of a mode of AES that came
> out of a draft standard from X9.102. It has received extensive vetting.
> The authors of the keywrap draft are proposing to use an existing
> standard to solve the problem it was created to solve-- cryptographically
> protecting keying material in transit.

It would be more accurate to portray the two approaches as (a) wrap all the
PDUs in a secure transport vs. (b) protect individual elements in selected
PDUs, i.e., external (to the protocol) vs. internal (to the protocol)
security.

The other fact to keep in mind is that the protection of keying material
does not address the complete scope of the RADEXT crypto-agility
requirements.  You need to consider both the keywrap draft and the encrypted
attribute draft.


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