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

[Tim Polk <[e-mail]>]

Folks,

I have been sorting through the email trail on this one.  In my  
opinion, there is *rough* consensus for the notes and approach that I  
proposed in this email.  Minor revisions were suggested, but the  
subsequent email thread seems to show the stated text was acceptable.

I have also reviewed the "key derivation differences" thread.  To  
quote Jouni's email from
24 February:
> In other words, we cannot come up with a EAP-MSCHAPv2 MSK derivation  
> rules that would cleanly fit into all deployed uses and there will  
> unfortunately be need for tunnel method specific exception in either  
> EAP-PEAP with cryptobinding or EAP-FAST. Either way, it would be  
> useful to get this documented clearly so that all future uses of EAP- 
> MSCHAPv2 would be able to refer to an existing specification instead  
> of having to come up with their own MSK/ISK derivation rules as was  
> done with EAP-PEAP cryptobinding and EAP-FAST.

I agree that it will be good to get this documented clearly for future  
specs, but do not see an impact on current specs, so I am not  
requesting any further changes to the documents.

Accordingly, I have asked the IESG Secretary to forward the proposed  
IESG notes to the RFC
Editor.

Thanks,

Tim Polk

On Feb 11, 2009, at 9:26 AM, Tim Polk wrote:

> 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