Re: [Re: Continued discussion of RADIUS Crypto-Agility]

["Dan Harkins" <dharkins@lounge.org>]

  Hi Leif,

On Fri, August 10, 2007 12:47 am, Leif Johansson wrote:
> Dan Harkins wrote:
>>   Hello,
>>
>> 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.
>>
>>   Dan.
>>
>>
> Another thing that bothers me is the direct reference to AES.
>
> Introducing a dependency on any one algorithm does not
> constitute agility in any sense of the word. The point (imho) is
> not to demonstrate how much we trust AES today but to make
> sure radius doesn't have to go through this again when AES
> needs replacing.
>
>     Cheers Leif

  It's the ciphersuite in TLS provides the crypto-agility. Similarly
the "enc-type" in the keywrap draft provides the crypto-agility. One
value of "enc-type" is for RFC3394 style AES Keywrap. A different value
could define RFC3217-style 3DES or RC2 keywrapping. There are many nice
things about AES though that make something like SIV-AES style keywrapping
even more appealing that RFC3394.

  Dan.




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