RE: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap

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

David B. Nelson <> allegedly scribbled on Wednesday, August 01, 2007
1:28 PM:

> Dan Harkins writes...
> 
>> If you're submitting a draft that only does AES Key wrap with no
>> capability to substitute anything else then you can mandate other
>> attributes that may be necessary. This isn't crypto-agile though.
> 
> That's a good point.  True crypto-agility is about modularly
> interchangeable cipher suites, not simply replacing a fixed, but
> compromised, cipher suite with another fixed, but currently robust,
> cipher suite. 

I guess that I haven't been a model of clarity here ;-); I apologize &
will try to clarify things now.  This draft has been around for a long
time, long enough I think that the term "crypto-agility" didn't exist
when the work was begun.  The purpose of our work was to enable the use
of IEEE 802.11i networks in FIPS 140-2 environments, while providing a
higher level of security RADIUSoIPsec.  We accomplished that goal.
Again, although we made provisions for variations in the cryptographic
algorithms used, crypto-agility was _not_ a primary goal.  The fact that
implementations of earlier versions of our draft (of necessity using
vendor-specific equivalents to the attributes defined in the draft) have
been certified by NIST obviously does not entail (or even imply) that
the final product of this WG will also be thus certifiable, even if it
is based upon our work.  I think that what it _does_ say is that our
overall approach is valid.  If our draft is chosen as the basis for the
radext crypto-agility work, it will certainly be changed: the first
thing _I_ think should be done is to modify the attributes to align with
the attribute extension work, which (along with some minor editorial
adjustments) take care of Dan's concerns.  Of course, that would be up
to WG consensus: the point I'm trying to make is that there's no need to
worry about backward compatibility with existing implementations of our
draft going forward since (whether it is accepted or not) we will likely
publish an Informational RFC including the actual VSAs used in the
implementation, purely for the convenience of other vendors that might
wish to build their own version of the existing protocol.

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