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

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

The problem is that RFC 2716 specifies the use of TLS-PRF-128.  If TLS v1.2 negotiates a PRF where PRF-64 is not the same as the first 64 octets of PRF-128 (the IKEv2 PRF is an example of such a PRF), then RFC 2716bis implementations will not interoperate with RFC 2716 implementations.   

Subject: RE: [Emu] Issue with RFC 2716bis key generationDate: Thu, 7 Jun 2007 17:02:40 -0400From: [email-masked]: [email-masked]; [email-masked]: 

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 PMTo: [email-masked]: [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

---

From: "Hao Zhou \(hzhou\)" <[email-masked]>
Date: Thu, 7 Jun 2007 23:08:12 -0400

Sorry, I mistyped. I meant to say why not keep the approach used in
RFC2716? What's the reason for the change in 2716Bis?

________________________________

	From: Bernard Aboba [mailto:[email-masked]] 
	Sent: Thursday, June 07, 2007 5:29 PM
	To: Hao Zhou (hzhou); [email-masked]
	Subject: RE: [Emu] Issue with RFC 2716bis key generation

	The problem is that RFC 2716 specifies the use of TLS-PRF-128.
If TLS v1.2 negotiates a PRF where PRF-64 is not the same as the first
64 octets of PRF-128 (the IKEv2 PRF is an example of such a PRF), then
RFC 2716bis implementations will not interoperate with RFC 2716
implementations.   

________________________________

		Subject: RE: [Emu] Issue with RFC 2716bis key generation
		Date: Thu, 7 Jun 2007 17:02:40 -0400
		From: [email-masked]
		To: [email-masked]; [email-masked]
		CC: 

		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. 
			 
			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.

---

From: <[email-masked]>
Date: Fri, 8 Jun 2007 12:59:33 +0300

Bernard Aboba wrote:

> The problem is that RFC 2716 specifies the use of TLS-PRF-128.  If
> TLS v1.2 negotiates a PRF where PRF-64 is not the same as the first
> 64 octets of PRF-128 (the IKEv2 PRF is an example of such a PRF),
> then RFC 2716bis implementations will not interoperate with RFC 2716
> implementations.

I think this cannot happen in (current drafts of) TLS 1.2. We decided
that all PRFs for TLS 1.2 must use the same "API" as the current PRF
(arbitrary-length secret/label/seed as input, sufficiently
long byte string out).

And as far as I can tell, this cannot happen in IKEv2 either: the 
output bytes are calculated one block at a time, and the "amount 
of bytes (or blocks) needed" is not used in the calculation. 

Best regards,
Pasi