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

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

 
> Dear EMU WG:
> 
> These two documents are in the RFC Editor queue:
> 
>    draft-cam-winget-eap-fast-provisioning-10.txt
>    draft-zhou-emu-fast-gtc-05.txt
> 
> The IESG has received a very late comment about these documents, and
> we seek your input on the proposed resolution.
> 
> The late comment raises a potential interoperability concern with
> existing implementations of EAP-MSCHAPv2 and EAP-GTC.
> 
> The draft-cam-winget-eap-fast-provisioning-10.txt document specifies
> a very specific way to generate the challenges used in EAP-MSCHAPv2
> that provides binding between the EAP-FAST tunnel and the EAP-MSCHAPv2
> exchanges.
> 
> The draft-zhou-emu-fast-gtc-05.txt describes EAP-FAST-GTC, which is
> uses EAP Type 6, originally allocated to EAP-GTC [RFC3748]. EAP-FAST-
> GTC
> employs a subset of the EAP-GTC formatting.
> 
> The IESG recognizes the difficulties caused by re-use of an EAP Type.
> Further, the IESG recognizes the concern about implementations that
> might not easily adapt to additional requirements.  However, the IESG
> also recognizes the significant value in documenting EAP methods that
> are implemented and deployed in the Internet today.
> 
> The IESG believes that the right thing to do in this situation is to
> proceed with the publication of these documents.  However, the IESG
> also
> sees value in warning future EAP method designers about this experience
> so that this pain might be avoided in the future.
> 
> The IESG is considering the additional informative paragraph in the
> IANA
> considerations section of both documents that says:
> 
>     IESG Note: EAP-FAST has been implemented by many vendors and it is
>     used in the Internet.  Publication of this is intended to promote
>     interoperability, even though the use of the EAP-MSCHAPv2 and
>     EAP-FAST-GTC EAP methods might be difficult in some software
>     environments.  If EAP-FAST were to be designed today, these
>     difficulties could be avoided by the assignment of new EAP Type
>     codes.
> 
> Please provide comments on the proposed way forward.

I am strongly opposed to the publication of these documents as RFCs in their
current form.  Not only is the "fast provisioning" for EAP-FAST what can
only be characterized as a security disaster, but EAP-FAST-GTC has nothing
whatsoever to do with the EAP-GTC type.  EAP-GTC was "defined for use with
various Token Card implementations which require user input" but
EAP-FAST-GTC is used solely to transfer a username/password combination, the
password in plaintext.  It's hard to see what this has to do with actual
token cards & appears to be a lazy misuse of an existing type.  Furthermore,
it's even harder to see how rewarding this kind of nonsense with publication
will serve as a warning of any kind; I would expect that the action of
publication (with or without IESG note) would be more likely taken as notice
that one can do whatever one please without fear.

> On behalf of the IESG,
>   Russ
> 
> _______________________________________________
> Emu mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/emu

_______________________________________________
Emu mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/emu