Subject: RE: [Emu] Issue with RFC 2716bis key generation

From: Bernard Aboba <[email-masked]>
Date: Thu, 7 Jun 2007 14:51:58 -0700

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-masked]> To: [email-masked]; [email-masked]> 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-masked]] > > Sent: Thursday, June 07, 2007 12:05 PM> > To: [email-masked]> > 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-masked]> https://www1.ietf.org/mailman/listinfo/emu

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

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Thu, 7 Jun 2007 15:10:22 -0700

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-masked]] 
> Sent: Thursday, June 07, 2007 2:52 PM
> To: Joseph Salowey (jsalowey); [email-masked]
> Subject: RE: [Emu] Issue with RFC 2716bis key generation
> 
> > Subject: RE: [Emu] Issue with RFC 2716bis key generation
> > Date: Thu, 7 Jun 2007 14:36:52 -0700
> > From: [email-masked]
> > To: [email-masked]; [email-masked]
> > 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-masked]]
> > > Sent: Thursday, June 07, 2007 12:05 PM
> > > To: [email-masked]
> > > 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.
> > > 
> > > 
> > > 
> >