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

From: Bernard Aboba <[email-masked]>
Date: Thu, 7 Jun 2007 16:39:11 -0700

The problem is that some PRFs generate a different stream if asked to provide 64 octets of output than they do if asked to provide 128 bytes of output.  As a result, the first 64 octets of TLS-PRF-128 (used in RFC 2716) is not the same as TLS-PRF-64 (what was used in RFC2716bis-09). 
 
Given this, an RFC 2716 implementation that utilizes TLS v1.2 will not interoperate with an RFC 2716bis implementation that utilizes TLS v1.2 if such a PRF is negotiated. > Subject: RE: [Emu] Issue with RFC 2716bis key generation> Date: Thu, 7 Jun 2007 15:10:22 -0700> From: [email-masked]> To: [email-masked]; [email-masked]> > 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> > > > 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 17:42:01 -0700

Doesn't 2716bis obsolete RFC2716?  Why would someone implement RFC2716
with TLS 1.2?  

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]] 
> Sent: Thursday, June 07, 2007 4:39 PM
> To: Joseph Salowey (jsalowey); [email-masked]
> Subject: RE: [Emu] Issue with RFC 2716bis key generation
> 
> The problem is that some PRFs generate a different stream if 
> asked to provide 64 octets of output than they do if asked to 
> provide 128 bytes of output.  As a result, the first 64 
> octets of TLS-PRF-128 (used in RFC 2716) is not the same as 
> TLS-PRF-64 (what was used in RFC2716bis-09). 
>  
> Given this, an RFC 2716 implementation that utilizes TLS v1.2 
> will not interoperate with an RFC 2716bis implementation that 
> utilizes TLS v1.2 if such a PRF is negotiated. 
> 
> > Subject: RE: [Emu] Issue with RFC 2716bis key generation
> > Date: Thu, 7 Jun 2007 15:10:22 -0700
> > From: [email-masked]
> > To: [email-masked]; [email-masked]
> > 
> > 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
> > > 
> > > 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.
> > > > > 
> > > > > 
> > > > > 
> > > >