RE: [Emu] Issue with RFC 2716bis key generation
Hao said: Sorry, I mistyped. I meant to say why not keep the approach used in RFC2716? What's the reason for the change in 2716Bis? [BA] I would agree that the approach used in RFC 2716 is preferrable. As to how the change got into RFC 2716bis, it appears to have been introduced in -01; -00 Section 2.5 contained the original text from RFC 2716. The text inserted into -01 appears to have been taken from the EAP Key Management Framework document, which included similar text in Appendix C in -00, and included an Appendix A on EAP-TLS key management up to version -09 (e.g. see http://www.watersprings.org/pub/id/draft-ietf-eap-keying-09.txt). As you noted, the formula in RFC 2716bis appears to imply that two PRFs need to be computed (TLS-PRF-64 and TLS-PRF-128) when in fact only one is needed (a single TLS-PRF-128). ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
RE: [Emu] Issue with RFC 2716bis key generation
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 ___ Emu mailing list Emu@ietf.org https://www1.ietf.org/mailman/listinfo/emu
RE: [Emu] Issue with RFC 2716bis key generation
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
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 generationDate: Thu, 7 Jun 2007 17:02:40 -0400From: [EMAIL PROTECTED]: [EMAIL PROTECTED]; [EMAIL PROTECTED]: 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 PMTo: [EMAIL PROTECTED]: [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
RE: [Emu] Issue with RFC 2716bis key generation
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 PROTECTED] Sent: Thursday, June 07, 2007 12: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
