Subject: [Emu] Key derivation differences

From: Bernard Aboba <[email-masked]>
Date: Wed, 11 Feb 2009 13:29:34 -0800

Jouni Malinen said:

"This looks like an appropriate text to add. However, I would request a
small clarification on the exact scope of the different EAP-MSCHAPv2 and
EAP-GTC behavior. As far as EAP-FAST-MSCHAPv2 vs. EAP-MSCHAPv2 is
concerned, I would expect that EAP-FAST-MSCHAPv2 is actually used both
for unauthenticated (anonymous) and server-authenticated provisioning
while the proposed note seemed to indicate that the different behavior
is implied by the use of an anonymous tunnel. See below for suggested
changes to resolve this.

I'm assuming that the implicit challenges derived from the TLS handshake
are not used in the EAP-FAST authentication, i.e., normal authentication
would be using something that is closer to EAP-MSCHAPv2, not
EAP-FAST-MSCHAPv2. However, I think that even that use of EAP-MSCHAPv2
differs a bit from the way it is used in other protocols, e.g., as far
as key derivation is concerned, but this would have been more of a
comment for RFC 4851 than these two drafts that are now discussed.
Anyway, since the key derivation from inner method is used also during
provisioning, it would be useful to specify the exact process used to
derive ISK from EAP-FAST-MSCHAPv2 (especially the order of send/recv
MS-MPPE keys which seems to differ from the way this is used in PEAPv0
with cryptobinding).
"

Are you suggesting that the version of EAP-MSCHAPv2 described in the document differs in terms
of the MSK/EMSK derivation?  Or are you suggesting that further details are needed on how padding
is accomplished with respect to ISK derivation?  

In general, ISK derivation doesn't relate to an EAP method so much as the tunneling method that
utilizes the keys exported by the inner method.  So if the issue is purely in the ISKs, then this
doesn't really relate to EAP-FAST-MSCHAPv2 or EAP-MSCHAPv2 so much as to EAP-FAST
provisioning mechanism.

---

From: Jouni Malinen <[email-masked]>
Date: Thu, 12 Feb 2009 00:12:36 +0200

> is accomplished with respect to ISK derivation?  

Former (for MSK part) as far as using EAP-MSCHAPv2 inside EAP-FAST is
concerned (the document itself does not describe EAP-MSCHAPv2 MSK
derivation).

> doesn't really relate to EAP-FAST-MSCHAPv2 or EAP-MSCHAPv2 so much as to EAP-FAST

What I noticed when implementing EAP-FAST and cryptobinding support for
EAP-PEAPv0 is that I have to swap the order of MS-MPPE send/recv keys
(i.e., swap octets 0..15 with 16..31) of the MSK from EAP-MSCHAPv2
between PEAPv0 and EAP-FAST uses in order to interoperate with other
implementations.

In other words, EAP-FAST and EAP-PEAPv0(with cryptobinding) seem to use
different derivation of ISK when using EAP-MSCHAPv2 as the inner method.
I do not see need for similar swapping of the ISK octets with EAP-TLS as
the inner method, so I would assume the difference is indeed in how the
EAP-MSCHAPv2 MSK derivation is defined. After reviewing the description
of the MS-CHAPv2 key derivation, I think I ended up agreeing with the
way this is done in PEAPv0+cryptobinding and the order used in deployed
EAP-FAST implementations would thus not match with the EAP-MSCHAPv2
definition for MSK derivation.

-- 
Jouni Malinen                                            PGP id EFC895FA

---

From: <[email-masked]>
Date: Thu, 12 Feb 2009 14:17:53 +0100

Bernard Aboba wrote:
> Are you suggesting that the version of EAP-MSCHAPv2 described in the
> document differs in terms of the MSK/EMSK derivation?  Or are you
> suggesting that further details are needed on how padding is
> accomplished with respect to ISK derivation?

Hmm.. it seems the EAP-MSCHAPv2 specification (on msdn.microsoft.com)
itself does not really specify how the MSK is derived. The spec says:

   3.1.5.1 Master Session Key (MSK) Derivation

   Upon successful authentication, Extensible Authentication Protocol
   Method for Microsoft CHAP derives the Master Session Key
   ([RFC3748]), as specified in [RFC3079], section 3.3.

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.

The PEAP specification (also on msdn.microsoft.com) specifies how
to derive an "ISK" from MS-MPPE-Send-Key and MS-MPPE-Recv-Key produced
by the inner method (but not from inner method MSK!).

   3.1.5.6.2.2 Intermediate PEAP MAC Key (IPMK) and Compound MAC Key (CMK)
   [..]
   Peer ISK = MS-MPPE-Send-Key | MS-MPPE-Recv-Key
   Server ISK = MS-MPPE-Recv-Key | MS-MPPE-Send-Key

So even PEAP seems to use both orders of send/recv keys...

(But I agree that it wouldn't hurt to say which order is used
where.)

Best regards,
Pasi

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 12 Feb 2009 07:51:44 -0800

> ReceiveSessionKey. But how to get an EAP MSK from those is not

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]

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 12 Feb 2009 08:14:50 -0800

Interesting, so it looks like EAP-MSCHAPv2 isn't fully defined except
within a tunnel method, so its behavior is specific to the tunnel
method...  

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Thursday, February 12, 2009 5:18 AM
> To: [email-masked]; [email-masked]
> Subject: Re: [Emu] Key derivation differences
> 
> Bernard Aboba wrote:
> Hmm.. it seems the EAP-MSCHAPv2 specification (on 
> msdn.microsoft.com) itself does not really specify how the 
> MSK is derived. The spec says:
> 
> 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.
> 
> The PEAP specification (also on msdn.microsoft.com) specifies 
> how to derive an "ISK" from MS-MPPE-Send-Key and 
> MS-MPPE-Recv-Key produced by the inner method (but not from 
> inner method MSK!).
> 
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu
>

---

From: "Hao Zhou (hzhou)" <[email-masked]>
Date: Thu, 12 Feb 2009 11:25:47 -0500

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. 

> Behalf Of Bernard Aboba
> Sent: Thursday, February 12, 2009 10:52 AM
> To: [email-masked]; [email-masked]
> 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):
>

---

From: <[email-masked]>
Date: Thu, 12 Feb 2009 17:26:30 +0100

>                   (MS-MPPE-Send-Key in [RFC2548]

Right, but this formula assumes that MS-MPPE-Recv-Key and -Send-Key
are 32 bytes (256 bits). The keys produced by RFC 3079 Section 3.3
are only 128 bits, so concatenating any two of them (in any order)
doesn't produce an EAP MSK (which is at least 64 octets).

Best regards,
Pasi

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 24 Feb 2009 09:59:02 -0800

> doesn't produce an EAP MSK (which is at least 64 octets).

Does the following more accurately describe what you are seeing?

At the end of successful authentication, EAP-MSCHAPv2 derives two 16-byte

MPPE keys as specified in [RFC3079] Section 3.3.  The Master Session Key ([RFC3748])

is derived from the two MPPE keys as follows:

MSK = 16-byte MPPE-Send-Key + 16 bytes zeroes (padding) + 16-byte MPPE-Receive-Key + 16 bytes zeroes (padding)

---

From: Jouni Malinen <[email-masked]>
Date: Tue, 24 Feb 2009 20:33:41 +0200

> MSK = 16-byte MPPE-Send-Key + 16 bytes zeroes (padding) + 16-byte MPPE-Receive-Key + 16 bytes zeroes (padding)

This does not match with the way ISK is generated in either EAP-FAST or
EAP-PEAPv0 with cryptobinding. The main problem is in there being no
clear description on how to derive a 64-octet MSK from EAP-MSCHAPv2.
Anyway, ISK is only going to use up to 32 octets of MSK (the first
octets; anything beyond that will be ignored). Consequently, the zero
padding in the MSK must not occur in that part to match the current
uses.

In addition, the Send vs. Recv key concept is problematic since the EAP
peer and server (or well, more likely authenticator and supplicant) have
different directions for sending and receiving.

If we want to define EAP-MSCHAPv2 MSK derivation in a way that matches
with the normal ISK generation rules (take first 32 octets) in
EAP-PEAPv0 with cryptobinding, we would get something like this:

MSK = 16-byte server/authenticator MS-MPPE-Send-Key |
    16-byte server/authenticator MS-MPPE-Recv-Key |
    32 bytes of something (e.g., zeroes; ISK does not care, some other
    uses might, so likely better to use something else than zeroes..)

On the peer, the first keys would be peer MS-MPPE-Recv-Key | peer
MS-MPPE-Send-Key (i.e., reverse Recv/Send).

If we want to define EAP-MSCHAPv2 MSK derivation in a way that matches
with the normal ISK generation rules in EAP-FAST, we would have to swap
Send and Recv in the above description for EAP-PEAPv0 due to the other
order of Send/Recv MPPE keys used there.

In other words, we cannot come up with a EAP-MSCHAPv2 MSK derivation
rules that would cleanly fit into all deployed uses and there will
unfortunately be need for tunnel method specific exception in either
EAP-PEAP with cryptobinding or EAP-FAST. Either way, it would be useful
to get this documented clearly so that all future uses of EAP-MSCHAPv2
would be able to refer to an existing specification instead of having to
come up with their own MSK/ISK derivation rules as was done with
EAP-PEAP cryptobinding and EAP-FAST.