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

[Jouni Malinen <[e-mail]>]

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