Subject: RE: [Emu] EAP-GPSK & Key Derivation Function

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 3 Oct 2007 21:24:53 -0700

I think this is a good approach.  

> -----Original Message-----
> From: Charles Clancy [mailto:[email-masked]] 
> Sent: Thursday, September 20, 2007 4:11 AM
> To: Tschofenig,Hannes (NSN - DE/Germany - MiniMD)
> Cc: [email-masked]
> 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-masked]  |  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-masked]
> > https://www1.ietf.org/mailman/listinfo/emu
> 
> 
> 
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/emu
> 

_______________________________________________
Emu mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/emu

---

From: "Paul Rowe" <[email-masked]>
Date: Sun, 21 Oct 2007 10:36:16 -0400

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

> t. charles clancy, ph.d.  |  [email-masked]  |  www.cs.umd.edu/~clancy<http://www.cs.umd.edu/%7Eclancy>
>