All,
My suggestion is adding the following to the GPSK document:
- For AES ciphersuite say keys MUST be 128 bits in length or longer, and
longer keys be truncated to 128 bits for use
- For HMAC ciphersuite say keys MUST be 256 bits in length or longer,
and longer keys be truncated to 256 bits for use
- RECOMMEND that 256 bit keys be provisioned in all cases to provide
enough entropy for all current and many possible future ciphersuites
- Add a new section describing requirements on future ciphersuites that
addresses necessary security requirements and describes their need to
specify PSK sizes and how they deal with different-length keys
--
t. charles clancy, ph.d. | [EMAIL PROTECTED] | www.cs.umd.edu/~clancy
Tschofenig, Hannes (NSN - DE/Germany - MiniMD) wrote:
Hi all,
What is the issue? The derivation of MK uses "0x00" as a key for the
KDF.
Here is the key derivation step:
MK = GKDF-16 (zero, PL || PSK || CSuite_Sel || inputString)
^^^^^
Here is the problem.
Here is what Charles recognized during the discussion:
"
I just looked though the definition of CMAC, the MAC used in one of our
two ciphersuites, and the zero key looks like it might cause some
problems. Unlike the HMAC ciphersuites, it doesn't simply concatenate
the key with the data input. The first step is to compute:
k0=E_k(0x00)
k1=k0*x mod p(x)
k2=k1*x mod p(x)
These values would always be fixed. During the CBC operation, they are
XOR'd with the final message block. k1 is XOR'd if the final message
block's length matches the encryption block length. k2 is used
otherwise on a message padded with 1000...0000b.
I think what using an all-zero key does is reduce the security of CMAC
to the security of CBC-MAC with an all-zeros IV. While the
ramifications of this are debatable for our applications, it's still
probably not a great idea.
Currently we can't use the PSK as the input to the first KDF because its
length may not match the selected ciphersuite's block length. We wanted
to try to do was have a ciphersuite that could be implemented using only
AES.
"
Do you agree that the problem is real?
If yes, then we believe that there are the following solution steps:
1) We would need some way to normalize the length of the PSK for the
selected ciphersuite. We could define an additional cryptographic
primitive in every ciphersuite that does this derivation, such as
SHA256-128 for the AES ciphersuite and SHA256 for the HMAC ciphersuite.
2) We could switch to a different KDF, for example to the one used for
IKEv2.
Can you come up with other solution approaches?
Which solution approach should we pick?
Ciao
Hannes
_______________________________________________
Emu mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/emu
_______________________________________________
Emu mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/emu
