First, RFC5216 is about EAP-TLS, not sure it can be applied to EAP-MSCHAPv2 or other EAP method.
Second, in the EAP-MSCHAPv2 case, there are only two 16 octets MPPE keys generated, not the two 32 octets MSK (0.31) and MSK (32, 63) as described in RFC5216. So it's not really clear to me how to put these two 16 octet keys together to form the 64 octet MSK (as defined by RFC3748). It's conceivable that different interpretations could happen. Third, I probably agree with Jouni that it's best to define how MSK is derived in each EAP method documentation itself, as each recent EAP method RFC adheres to. That would leave no room for different interpretations that is specific to the tunnel method. > -----Original Message----- > From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On > Behalf Of Bernard Aboba > Sent: Thursday, February 12, 2009 10:52 AM > To: pasi.ero...@nokia.com; emu@ietf.org > Subject: Re: [Emu] Key derivation differences > > > > But Section 3.3 of RFC 3079 is not about EAP. It does > specify how to > > calculate a 128-bit MasterKey, a 128-bit MasterSendKey, a 128-bit > > MasterReceiveKey, a 128-bit SendSessionKey, and a 128-bit > > ReceiveSessionKey. But how to get an EAP MSK from those is not > > specified. > > RFC 5216 describes the relationship between the MSK and the > receive and send keys (which was how the MSK was originally > defined in RFC 2716): > > Enc-RECV-Key = MSK(0,31) = Peer to Authenticator Encryption Key > (MS-MPPE-Recv-Key in [RFC2548]). Also known as the > PMK in [IEEE-802.11]. > Enc-SEND-Key = MSK(32,63) = Authenticator to Peer Encryption Key > (MS-MPPE-Send-Key in [RFC2548] > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu > _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
