Re: [Emu] Potential Notes in EAP-FAST Documents

[Jouni Malinen <[e-mail]>]

On Wed, Feb 11, 2009 at 10:05:57PM -0500, Hao Zhou (hzhou) wrote:

> To clarify, EAP-FAST-MSCHAPv2 is only being used during anonymous
> provisioning mode, in other cases, the normal EAP-MSCHAPv2 is being
> used. This is mentioned in draft-cam-winget-eap-fast-provisioning
> Section 3.2.3 and reflects current implementations. The design is to
> specifically minimize the risk associated with an anonymous tunnel,
> which does not apply to an authenticated tunnel.  

Thanks. Apparently, I looked at my implementation bit too quickly and
assumed it was using the implicit challenges for both provision cases,
but you are correct, the draft does indeed state this only for anonymous
provisioning and I now confirmed that that was also what my
implementation was doing. In other words, the changes I asked for the
note for draft-cam-winget-eap-fast-provisioning for the topic of when to
use EAP-MSCHAPv2 vs. EAP-FAST-MSCHAPv2 should not be made and only the
change request for draft-zhou-emu-fast-gtc would be suitable.

> As for the ISK derivation from EAP-MSCHAPv2, a further clarification is
> probably helpful. As discussed, EAP-MSCHAPv2 documentation doesn't
> really describe how MSK is generated, only referencing RFC3079. RFC3079
> only describes how two 128-bit keys are generated, but leaves out how
> these two keys are combined to form the MSK. This leaves it to be
> defined in a tunnel method specific way. It seems that EAP-FAST may have
> defined a combining algorithm different with the other method. 

I agree for the part that MSK derivation for EAP-MSCHAPv2 is not very
well defined and it did require going through multiple documents to
figure out the order.

As far as MSK derivation for an inner method being tunnel method
specific is concerned, I do not agree with that. It should be up to the
inner method specification to define how MSK is derived and tunnel
method ISK should just use that MSK.

I do not remember anymore where exactly I found this, but probably
based on the MSCHAPv2 documents and the way MS-MPPE keys are used in
other methods, I ended up with EAP-MSCHAPv2
    MSK = server MS-MPPE-Recv-Key | server MS-MPPE-Send-Key

This is the order used in EAP-PEAPv0 cryptobinding derivation.

In EAP-FAST, the opposite order is used:
    MSK = server MS-MPPE-Send-Key | server MS-MPPE-Recv-Key

> Here is what we propose to add to draft-cam-winget-eap-fast-provisioning
> Section 3.2.3 to clarify the issue. 
> 
> "The inner session key (ISK) generation for EAP-FAST-MSCHAPv2 and
> EAP-MSCHAPv2 used inside EAP-FAST MUST follow the steps below. Two 128
> bit master keys MasterSendKey and MasterReceiveKey are generated
> according to the RFC3079. They are combined to form the ISK, with
> MasterSendKey taking the first 16 octets and MasterReceiveKey taking the
> last 16 octets. "

Taken into account that MasterSendKey in RFC 3079 is defined as the
server MS-MPPE-Send-Key, this matches with the order I described above
and including this note in the draft would indeed be a helpful
clarification.

-- 
Jouni Malinen                                            PGP id EFC895FA