RE: RADEXT WG re-charter

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

  A very intersting discussion....

  Yes, bulk data protection with the current key wrapping scheme (RFC3394)
is problematic. It requires things to be 64-bit aligned, it doesn't
allow "associated data" (AD) which is authenticated but not encrypted, and
while it is probably secure it does not have a formal proof of security
behind it. All of these problems can be addressed by the SIV mode of AES.

  SIV can provide deterministic "key wrapping" when a component of the
plaintext is random, and it can provide nonce-based bulk data encryption.
In both variants it allows AD. It also provides security even in the
presence of nonce reuse. This last issue is especially critical when one
does not have a dynamic key exchange but, instead, uses statically
provisioned keys on the client and server. If one side crashes and loses
state (like a counter value or knowledge of previously used nonces) the
security of the system must not suffer, nor is it realistic to require
each side to checkpoint state in some non-volatile storage.

  Secure key wrapping with AD plus bulk data encryption with AD that is
resistant to nonce reuse, all in one cipher mode. That sounds useful....

  Dan.

On Wed, April 16, 2008 3:28 pm, Joseph Salowey (jsalowey) wrote:
>
>
>> -----Original Message-----
>> From: owner-radiusext@ops.ietf.org
>> [mailto:owner-radiusext@ops.ietf.org] On Behalf Of David B. Nelson
>> Sent: Wednesday, April 16, 2008 5:52 AM
>> To: radiusext@ops.ietf.org
>> Subject: RE: RADEXT WG re-charter
>>
>> Joseph Salowey writes...
>>
>> > There are a few reasons why you would want to wrap keys separately
>> > from other data.  As you mentioned, the recommended
>> algorithms for key
>> > wrap may not be suitable for encrypting bulk data without special
>> > consideration  ...
>>
>> Yes, because in those cases you are *relying* on the
>> randomness of the key material.
>>
> [Joe] That's at least part of the problem, but in general these
> algorithms were not designed for bulk data encryption so there may be
> other issues that I don't know about.
>
>> > ... and some bulk data encryption algorithms may not be recommended
>> > for key wrap without special consideration.
>>
>> That's the part I still don't understand.  The only
>> "consideration" I've heard so far is that "NIST hasn't
>> blessed it", which is political and not technical.  Of
>> course, if you think that a critical goal of RADIUS
>> Crypto-Agility is to facilitate creating FIPS certifiable
>> products, then maybe this should be listed in the RADIUS
>> Crypto-Agility Requirements draft.
>>
> [Joe] I wouldn't say this is just political.  NIST has designed an
> algorithm for the purpose of wrapping keys.  While this may not be
> everybody's favorite solution it seems silly to design a crypto-agility
> solution that cannot accommodate it. I would say the requirement is to
> support key wrapping.
>
>> > Another reason is that you may want the entity that handles
>> the keys
>> > and their context to be different from the entity that handles the
>> > rest of the attributes.
>>
>> Perhaps.  You could provide that enforced "separation of
>> concerns" by using a separate KEK for the keys and a DEK for
>> the data.  The algorithm and mode need not be different to
>> provide the isolation.  Since the key management and
>> distribution, e.g. automated key management, is currently out
>> of scope for RADIUS Crypto-Agility, that shouldn't present an
>> impediment.
>>
> [Joe] Yes, at the very least the keys must be different, but for the
> reasons discussed above you may want to vary the algorithms as well.  I
> would think if you can figure out how to have different keys you can
> also figure out how to support different algorithms.
>
>
>> > Neither of these reasons forces you to have encryption tied
>> directly
>> > to the key attribute.  It is convenient since one is very often
>> > interested in encrypting keys, but you can achieve the same
>> thing with
>> > a generic encryption attribute if you take care.
>>
>> OK.  What care do we need to take?
>>
> [Joe] That's what I scribbled about on parenthesis below.
>
>> > You need to support multiple pieces of data encrypted with
>> different
>> > keys (key IDs, alg IDs, message boundaries, etc.) in the
>> same message
>> > and you need to make sure that the various supported encryption
>> > algorithms are used correctly (type of cleartext, sufficient
>> > randomization, integrity protection, etc.).
>>
>> If we determine that the algorithm and mode that do not
>> depend upon a random payload, but are still strong when the
>> payload happens to be random, what's the issue?
>>
> [Joe] As stated above the issues are using the algorithms for what they
> are designed for and support separation between keys and their context
> from other attributes.  There can be multiple ways we can design this
> which would work out fine by pushing some of the inconvenient bits to
> different places.
>
>> > If you don't consider keys as part of the data you are wrapping for
>> > crypto agility, I'm not sure you will end up with a result that is
>> > very useful.
>>
>> Sure.  We need to have a method that works for keys, too.
>> I'm trying to figure out if there is a "one size fits all"
>> algorithm and method (assuming a separate KEK), and if not,
>> why not.  So far the only impediment that I see remaining is
>> the "it's not blessed by NIST" for that particular
>> application, e.g. key wrap.
>>
> [Joe] NIST as defined a key wrapping algorithm, it may not be the best
> thing for all purposes, but it is good enough for key wrapping and it
> has been implemented for this purpose in various solutions.  Designing a
> crypto-agility solution that cannot support this seems short-sighted
> since NIST validation is an important part of many customer's
> requirements.  This is especially true since one of the main pieces of
> data people are concerned about protecting in today's deployments are
> keys.  While I favor a specific attribute for key wrap solution, I do
> not think it is necessary to design it this way.  If we support
> different encrypted payloads in the same message with different keys and
> different algorithms you have effectively the same thing (you just
> wouldn't know that it was a key and its context that was wrapped).  We
> should limit the usage of key-wrap specific algorithms to the purpose
> they were designed for.
>
>> BTW, thank you very much for a *technical* discussion of the
>> issue.  It's quite refreshing.  :-)
>>
>>
>>
>> --
>> 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/>
>



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