So TLS 1.2 won't change the PRF for TLS 1.1-. Shouldn't existing implementations based on RFC2716 interoperate with RFC2716bis implementations using TLS 1.1 and 1.0?
What we define in 2716bis is what EAP-TLS implementations based on TLS 1.2 will use. These implementations should interoperate with one another. I'm not sure where the problem is. Joe > -----Original Message----- > From: Bernard Aboba [mailto:[EMAIL PROTECTED] > Sent: Thursday, June 07, 2007 2:52 PM > To: Joseph Salowey (jsalowey); [email protected] > Subject: RE: [Emu] Issue with RFC 2716bis key generation > > RFC 2716 used TLS-PRF-128, so the question is why RFC 2716bis > is using TLS-PRF-64. > > > > > Subject: RE: [Emu] Issue with RFC 2716bis key generation > > Date: Thu, 7 Jun 2007 14:36:52 -0700 > > From: [EMAIL PROTECTED] > > To: [EMAIL PROTECTED]; [email protected] > > CC: > > > > 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 > > > _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
