RE: RADEXT WG re-charter

["David B. Nelson" <d.b.nelson@comcast.net>]

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.

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

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

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

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

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

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