[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Crypto-agility requirement and draft-zorn-radius-encattr/draft-zorn-radius-keywrap
When working on the key wrap draft we did consider crypto-agility,
however we did not spend much time thinking about authenticating ciphers
that Dan is referring to.
> -----Original Message-----
> From: owner-radiusext@ops.ietf.org
> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of Glen Zorn (gwz)
> Sent: Wednesday, August 01, 2007 2:46 PM
> To: David B. Nelson
> Cc: radiusext@ops.ietf.org
> Subject: RE: Crypto-agility requirement and
> draft-zorn-radius-encattr/draft-zorn-radius-keywrap
>
> 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/>
>
--
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/>