RFC 2716 used TLS-PRF-128, so the question is why RFC 2716bis is using
TLS-PRF-64.
> Subject: RE: [Emu] Issue with RFC 2716bis key generation> Date: Thu, 7 Jun
> 2007 14:36:52 -0700> From: [EMAIL PROTECTED]> To: [EMAIL PROTECTED];
> [email protected]> CC: > > 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: [email protected]> > 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>
> [email protected]> https://www1.ietf.org/mailman/listinfo/emu_______________________________________________
Emu mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/emu
