Regarding the Key Derivation Function in EAP-GPSK: The proposed solution is to use the long term key PSK as the key for the KDF instead of the constant 0x00. Along with this the draft will include guidelines governing key length for different ciphersuites (including truncating long keys to the appropriate length) as stated in the following:
http://www1.ietf.org/mail-archive/web/emu/current/msg00671.html This option looks like a good idea. It seems to appropriately address the concern of using the constant "key" 0x00 while also addressing issues in compatibility of key lengths. Andre Scedrov, John Mitchell, Arnab Roy, Paul Rowe > -----Original Message----- > From: Charles Clancy [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 20, 2007 4:11 AM > To: Tschofenig,Hannes (NSN - DE/Germany - MiniMD) > Cc: [email protected] > Subject: Re: [Emu] EAP-GPSK & Key Derivation Function > > 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<http://www.cs.umd.edu/%7Eclancy> > > 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 >
_______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
