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 protected]
https://www1.ietf.org/mailman/listinfo/emu
