Is there any reason not to use the approach in RFC2716Bis? This
guarantees backward compatibility and require less computation.
________________________________
From: Bernard Aboba [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 07, 2007 3:05 PM
To: emu@ietf.org
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
Emu@ietf.org
https://www1.ietf.org/mailman/listinfo/emu
