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

Jouni:

Thanks for the feedback.

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.  

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. 

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. "

As for the GTC comment, you are right that EAP-FAST-GTC is being used in
all cases inside EAP-FAST. So your suggestion of removing "during
authentication" or changing it to "always" is fine.  

> -----Original Message-----
> From: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On 
> Behalf Of Jouni Malinen
> Sent: Wednesday, February 11, 2009 3:13 PM
> To: Tim Polk
> Cc: emu@ietf.org; iesg@ietf.org IESG
> Subject: Re: [Emu] Potential Notes in EAP-FAST Documents
> 
> On Wed, Feb 11, 2009 at 09:26:14AM -0500, Tim Polk wrote:
> 
> > Second, I will be offering the following text for IESG 
> notes on both 
> > documents.  The notes clearly state the drawbacks for EAP type code 
> > reuse and define an acceptable path for future protocol developers.
> 
> 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).
> 
> > ------ draft-cam-winget-eap-fast-provisioning -----
> >     The EAP method EAP-FAST-MSCHAPv2 reuses the EAP type 
> code assigned to
> >     EAP-MSCHAPv2 (26) for authentication within an 
> anonymous TLS tunnel.  
> 
> s/an anonymous TLS tunnel/the EAP-FAST tunnel during provisioning/
> 
> > In
> >     order to minimize the risk associated with an anonymous tunnel, 
> > changes
> >     to the method were made that are not interoperable with EAP- 
> > MSCHAPv2.
> 
> This use of "anonymous tunnel" sounds fine.
> 
> >     Since EAP-MSCHAPv2 does not support method-specific version 
> > negotiation,
> >     the use of EAP-FAST-MSCHAPv2 is implied by the use of 
> an anonymous
> >     EAP-FAST tunnel.
> 
> s/of an anonymous EAP-FAST tunnel/inside the EAP-FAST tunnel 
> during provisioning/
> 
> >  This behavior may cause problems in implementations
> >     where the use of unaltered EAP-MSCHAPv2 is needed inside an 
> > anonymous
> >     EAP-FAST tunnel.  Since such support requires special case 
> > execution of
> >     a method within a  tunnel, it also complicates implementations 
> > that use
> >     the same method code both within and outside of the tunnel
> >     method.
> 
> That "anonymous" should likely be replaced, too, but I don't 
> have a good proposal for this one. Maybe s/an anonymous/the/
> 
> The implementation complexity comes both from different 
> tunneling methods using different versions of EAP-MSCHAPv2 
> and from the different use within EAP-FAST depending on state 
> (provisioning vs.
> authentication).
> 
> 
> > ----  draft-zhou-emu-fast-gtc  ------
> 
> > Since
> >     EAP-GTC does not support method-specific version 
> negotiation,  the 
> > use of
> >     EAP-FAST-GTC is implied when used inside the EAP-FAST 
> tunnel during
> >     authentication.
> 
> s/ during authentication//
> 
> I'm not sure whether this "during authentication" was 
> referring to the case where EAP-FAST provisioning is not used 
> (i.e., normal authentication after PAC has been previously 
> provisioned). Anyway, it is probably clearer to just specify 
> that EAP-FAST-GTC is used in all cases inside EAP-FAST tunnel 
> since the draft seems to indicate that this is indeed the 
> case (just note that EAP-FAST-GTC is not allowed in 
> unauthenticated/anonymous provisioning, but it is allowed in 
> server-authenticated provisioning).
> 
> -- 
> Jouni Malinen                                            PGP 
> id EFC895FA
> _______________________________________________
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
> 