On Tue, Feb 24, 2009 at 09:59:02AM -0800, Bernard Aboba wrote:
> 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)
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.
--
Jouni Malinen PGP id EFC895FA
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
