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

["Glen Zorn" <[e-mail]>]

Tim Polk [mailto:[e-mail]] writes:

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

I'm sure that the IESG views its essentially invertebrate response to this
outrageous behavior as stern but fair.  If this pirating of IANA allocated
parameters is actually allowed (as it appears that it will be), I suggest
that you keep this stern warning around (perhaps as a form-letter template
so you can easily fill in the blanks); even better, publish it (suitably
modified for generality) as an RFC so the next few hundred "designers" who
can't be bothered with IANA can just reference it.

> 
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/emu