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

From: Bernard Aboba <[email-masked]>
Date: Thu, 7 Jun 2007 12:05:22 -0700

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

---

From: "Hao Zhou \(hzhou\)" <[email-masked]>
Date: Thu, 7 Jun 2007 17:02:40 -0400

Is there any reason not to use the approach in RFC2716Bis? This
guarantees backward compatibility and require less computation.

________________________________

	From: Bernard Aboba [mailto:[email-masked]] 
	Sent: Thursday, June 07, 2007 3: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. 

	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.  

	   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.

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Thu, 7 Jun 2007 14:36:52 -0700

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-----
> Sent: Thursday, June 07, 2007 12:05 PM
> To: [email-masked]
> formula specified in RFC 2716bis could cause backward 
> compatibility problems once TLS v1.2 is introduced. 
>  
>  However, this is not necessarily true for all PRFs that 
> could conceivably be negotiated within TLS v1.2.  
>  
>    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:
>    pseudorandom function (PRF) defined in the specification for the
>    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
>    of these two output strings.  The EAP server encryption 
> key (the one
>    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
>    to the correct length the third 32 bytes of this same PRF output
>    to the correct length the fourth 32 bytes of this same PRF output
>    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
>    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.
> 
> 
>