On Thu, Oct 26, 2006 at 02:04:58PM -0400, Charles Clancy wrote: > Actually, the descriptions in chapter 6 are incorrect, and need be fixed > to reflect the changes in chapter 4.
OK. > The KDF in chapter 4 was changed to allow PSKs of variable length and > entropy. Using the PSK to directly key the KDF to generate the MK has > problems because most KDFs have fixed-length inputs for keys. Imagine > someone who uses a 50-character passphrase (English text has around 2.5 > bits of entropy per character, so that's roughly a 128-bit secure key). > If we follow what's currently in chapter 6, we truncate that to 16 bytes, > which would only be 40 bits of security. Not a good thing. Only with Ciphersuite 1.. Ciphersuite 2, i.e., HMAC-SHA256, should be able to handle arbitrary length keys. Does the following change match with your understanding? In 6.1.3, replace MK = GKDF-16 (PSK[0..15], RAND_Client || ID_Client || RAND_Server || ID_Server) with MK = GKDF-16 (Zero-String, PL || PSK || CSuite_Sel || RAND_Client || ID_Client || RAND_Server || ID_Server) (I did not find definition for how PL is to be represented here. Is it enough to limit to PSKs of up to 255 octets and define PL to be one octet?) In 6.2.3, replace MK = GKDF-32 (PSK, RAND_Client || ID_Client || RAND_Server || ID_Server) with MK = GKDF-32 (Zero-String, PL || PSK || CSuite_Sel || RAND_Client || ID_Client || RAND_Server || ID_Server) (Same comment about PL) As an alternative, this could be MK = GKDF-32 (PSK, CSuite_Sel || RAND_Client || ID_Client || RAND_Server || ID_Server) since HMAC-SHA256 should have no problems with variable length PSK. By the way, is the definition of Zero-String (KS octets of 0x00) really suitable for Ciphersuite 2? Why bother generating a sequence of 32 octets of 0x00 for HMAC-SHA256 key (which could as well be zero-length). -- Jouni Malinen PGP id EFC895FA _______________________________________________ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
