Is there a reason why we changed to TLS-PRF-128 for the MSK? Is this a huge issue given that there are not likely any existing implementations of EAP-TLS using TLS 1.2?
Joe > -----Original Message----- > From: Bernard Aboba [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 07, 2007 12:05 PM > To: [email protected] > Subject: [Emu] Issue with RFC 2716bis key generation > > It has been pointed out by Paul Funk that the key generation > formula specified in RFC 2716bis could cause backward > compatibility problems once TLS v1.2 is introduced. > > The formula in -09 is as follows: > > MSK(0,63) = TLS-PRF-64(TMS, "client EAP encryption", > client.random || server.random) > EMSK(0,63) = second 64 octets of: > TLS-PRF-128(TMS, "client EAP encryption", > client.random || server.random) > IV(0,63) = TLS-PRF-64("", "client EAP encryption", > client.random || server.random) > > The issue here is that RFC 2716 Section 3.5 specifies a > different approach: > > MSK(0,63) = first 64 octets of: > TLS-PRF-128(TMS, "client EAP encryption", > client.random || server.random) > EMSK(0,63) = second 64 octets of: > TLS-PRF-128(TMS, "client EAP encryption", > client.random || server.random) > IV(0,63) = TLS-PRF-64("", "client EAP encryption", > client.random || server.random) > > With the current TLS PRF, these two approaches are identical. > However, this is not necessarily true for all PRFs that > could conceivably be negotiated within TLS v1.2. > > The text from RFC 2716 Section 3.5 reads as follows: > > Since the normal TLS keys are used in the handshake, and therefore > should not be used in a different context, new encryption keys must > be derived from the TLS master secret for use with PPP encryption. > For both peer and EAP server, the derivation proceeds as follows: > given the master secret negotiated by the TLS handshake, the > pseudorandom function (PRF) defined in the specification for the > version of TLS in use, and the value random defined as the > concatenation of the handshake message fields > client_hello.random and > server_hello.random (in that order), the value PRF(master secret, > "client EAP encryption", random) is computed up to 128 > bytes, and the > value PRF("", "client EAP encryption", random) is computed up to 64 > bytes (where "" is an empty string). The peer encryption key (the > one used for encrypting data from peer to EAP server) is > obtained by > truncating to the correct length the first 32 bytes of the > first PRF > of these two output strings. The EAP server encryption > key (the one > used for encrypting data from EAP server to peer), if > different from > the client encryption key, is obtained by truncating to the correct > length the second 32 bytes of this same PRF output string. The > client authentication key (the one used for computing MACs for > messages from peer to EAP server), if used, is obtained by > truncating > to the correct length the third 32 bytes of this same PRF output > string. The EAP server authentication key (the one used for > computing MACs for messages from EAP server to peer), if > used, and if > different from the peer authentication key, is obtained by > truncating > to the correct length the fourth 32 bytes of this same PRF output > string. The peer initialization vector (IV), used for > messages from > peer to EAP server if a block cipher has been specified, > is obtained > by truncating to the cipher's block size the first 32 bytes of the > second PRF output string mentioned above. Finally, the server > initialization vector (IV), used for messages from peer to > EAP server > if a block cipher has been specified, is obtained by truncating to > the cipher's block size the second 32 bytes of this second PRF > output. > > > _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
