Re: [Emu] Key derivation differences

[Jouni Malinen <[e-mail]>]

On Wed, Feb 11, 2009 at 03:56:08PM -0800, Bernard Aboba wrote:

> You are saying that in addition to the interoperability issues described in
> Tim's note with respect to the EAP-FAST-MSCHAPv2, that this document
> also does not conform to the key derivation specified in EAP MS-CHAPv2, 
> and that as a result it can't interoperate with existing implementations of
> EAP MS-CHAPv2, for regular non-provisioning uses?  

I'm not sure I would go as far as saying it does not conform to a
specification taken into account the unclear situation on how MSK
derivation for EAP-MSCHAPv2 is defined. More exact statement would be
that EAP-FAST ISK and PEAPv0/cryptobinding ISK derivations use different
order of MS-MPPE-Send-Key and MS-MPPE-Recv-Key in the EAP-MSCHAPv2 MSK.

In other words, implementations that try to use the same EAP-MSCHAPv2
implementation (including the rules for MSK derivation) would not
interoperate with both deployed EAP-FAST and EAP-PEAPv0/cryptobinding
implementations. Depending on the Send/Recv key order in the MSK, one of
the tunnel methods using the MSK from EAP-MSCHAPv2 would need to swap
the keys. In my particular case, I ended up implementing EAP-FAST first
and found the issue when trying to interoperate with EAP-PEAPv0
cryptobinding after that.

As far as which use is correct is concerned, it is not exactly trivial
thing to figure out, but my current interpretation of various
specifications related to MS-MPPE keys is that the order used in
PEAPv0 cryptobinding would match with the order used in other methods.

Anyway, having a single document describing EAP-MSCHAPv2, including MSK
derivation, would be a useful thing to have for anyone who wants to
implement these things. The use of MS-MPPE Send/Recv keys that are
different for server and peer side instead of defining the same
derivation of full MSK for both server and peer make it very easy to get
this wrong. I ended up having to figure this out by testing against
deployed implementations and getting surprised that the same code does
not work with both uses.

Anyway, like I mentioned before, this EAP-MSCHAPv2 MSK difference is not
strictly speaking an issue that would be specific to
draft-cam-winget-eap-fast-provisioning; it would have been useful to
describe it in RFC 4851. Anyway, it looks like the authors are willing
to include the additional description in
draft-cam-winget-eap-fast-provisioning and for the goal of describing a
deployed protocol and allowing vendors to implement it in interoperable
way, it is useful to get this described somewhere and this draft looks
like the best place to do so at this point.

-- 
Jouni Malinen                                            PGP id EFC895FA