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

This looks like a good resolution. Thanks Tim.

Gabriel

----- Original Message ----
> From: Tim Polk <tim.polk@nist.gov>
> To: emu@ietf.org
> Cc: "iesg@ietf.org IESG" <iesg@ietf.org>
> Sent: Wednesday, February 11, 2009 6:26:14 AM
> Subject: Re: [Emu] Potential Notes in EAP-FAST Documents
> 
> Folks,
> 
> As the AD that sponsored publication of the EAP-FAST documents under discussion,
> I have been trying to find the best way forward.  I believe that the best course 
> of action
> involves some clarifications to draft-cam-winget-eap-fast-provisioning to 
> distinguish
> the modified and unmodified use of EAP-MSCHAPv2, and IESG notes to ensure these
> publications do not establish precedent for future reuse of EAP type codes with
> different semantics.
> 
> First, I support revising draft-cam-winget-eap-fast-provisioning so that the 
> modified
> form of EAP-MSCHAPv2 is consistently referred to as EAP-FAST-MSCHAPv2.  The
> authors offered to make this change earlier in the thread, and I have seen some
> support and no opposition to this suggestion.
> 
> 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.
> 
> ------ draft-cam-winget-eap-fast-provisioning -----
> 
>     EAP-FAST has been implemented by many vendors and it is used in the
>     Internet.  Publication of this specification is intended to promote
>     interoperability by documenting current use of existing EAP methods
>     within EAP-FAST.
> 
>     The EAP method EAP-FAST-MSCHAPv2 reuses the EAP type code assigned to
>     EAP-MSCHAPv2 (26) for authentication within an anonymous TLS tunnel.  In
>     order to minimize the risk associated with an anonymous tunnel, changes
>     to the method were made that are not interoperable with EAP-MSCHAPv2.
>     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.  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. If
>     EAP-FAST  were to be designed today, these difficulties could be avoided
>     by utilization of unique EAP Type codes. Given these issues, assigned
>     method types must not be re-used with different meaning inside tunneled
>     methods in the future.
> 
> ----  draft-zhou-emu-fast-gtc  ------
> 
>     EAP-FAST has been implemented by many vendors and it is used in the
>     Internet.  Publication of this specification is intended to promote
>     interoperability by documenting current use of existing EAP methods
>     within EAP-FAST.
> 
>     The EAP method EAP-FAST-GTC reuses the EAP type code assigned to
>     EAP-GTC (6).  The reuse of previously assigned EAP Type Codes is
>     incompatible with EAP method negotiation as defined in RFC 3748.  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. This behavior may cause problems in implementations where
>     the use of another vendor's EAP-GTC is required.  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. If EAP-FAST were to be designed today, these
>     difficulties could be avoided by utilization of unique EAP Type codes.
>     Given these issues, assigned method types must not be re-used with
>     different meaning inside tunneled methods in the future.
> 
> I am not under the illusion that this text will be entirely satisfactory to 
> anyone,
> but I believe that it is an *appropriate* resolution to the problem.
> 
> Thanks,
> 
> Tim Polk
> _______________________________________________
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu