David,
Does FIPS-140-2 actually put this restriction on a KDF?
Yes, perhaps this may help explain the matter:
FIPS 140-2 is a prescriptive standard; vendors are not allowed to mix
and match elements of security functions, and no KDF is by itself an
approved security function. A KDF can therefore only be used as a
component to an existing allowed security function.
For example, currently FIPS modules can establish keys with TLS. TLS
uses a KDF, so the TLS-KDF may be used, but only in the context of
TLS. The draft you cited is a KDF used in within draft-SP800-56, as
well as in ANSI X9.63. The acceptability of the KDF depends on which
key establishment protocol it is used in.
To see a list of which key establishment protocols are allowed, look
at Annex D. You'll find that effectively NIST allows only asymmetric
key establishment. Within the framework of an allowed asymmetric key
establishment, multitudes of KDFs may be used, but not in LRW-AES.
I'm assuming here that we will not create a TLS style key agreement
scheme in which we generate keys from a KDF. Outside of asymmetric
crypto, you have to stick to generating keys from a PRNG or having
the keys loaded externally into your module.
That's certainly an unneeded restriction,
:)
and also it is at odds with Section 3.1 of http://www.ietf.org/
internet-drafts/draft-dang-nistkdf-00.txt, "(Key Derivation from)
Secret Values Established out of band". So even if the current
FIPS-140 docs have this restriction, it is clearly not the intended
direction of NIST.
No, Section 3.1 says that the values may be established with a
mechanism out of scope of the draft, in which case shared info values
must be provided by that mechanism. Section 3.1 does not discuss
whether the parent key establishment framework is or is not allowed
in FIPS 140-2.
Well, it's not necessary to leave KDFs out of the specs in order to
allow implementations to be FIPS-140 conformant. It is sufficient
to not have a mandatory-to-use KDF that is not FIPS-140
conformant. The spec could mandate a KDF that didn't conform to
FIPS-140, and it would still be possible to get a FIPS-140
validation, which would need to reference a security policy
describing how to operate the cryptomodule in a manner that didn't
use the non-coformant KDF.
Yes, I agree. However, I view the current LRW-AES document as the
definition of an encryption mode. It is unusual to mandate any type
of key management in an encryption mode definition -- even if the
mandate consists of a list of options. It's fine to have a discussion
of threats and advantages relating to keys, but to specify key
derivation algorithms is dangerous. First, you can't forsee how this
mode will be used, if successful, so there is a risk of hamstringing
vendors in the future. Also, suppose a vulnerability is announced in
a KDF -- does this kill AES-LRW? Tomorrow a hot KDF is announced, and
vendors want to use it instead of what is specified. In general
requirements on the keys should be stated in a mode document, not
mechanisms of achieving those requirements. Optimizations to
mechanisms, although valuable, are rarely robust.
Note that NIST has already issued SP-800-57 Part 1, General Key
Management Guidance. A discussion of how those requirements apply
when using LRW-AES in a stored data environment would be an important
document to have, but not incorporated into the specification of the
encryption algorithm.
Thanks,
Robert
