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

[Bernard Aboba <[e-mail]>]

Tim --

This works for me. 

Thanks (to you and other members of the IESG) for putting in the time to get this right. 


=======================================
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