[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: RADEXT WG re-charter
> -----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/>