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

  I strongly recommend against publication of these two documents.
They represent essentially proprietary hacks on established protocols.
The benefit in documenting use of EAP in the Internet today is far
outweighed by the damage done to existing protocol specification and
implementations. They will serve only to create spagetti code and
unnecessary complexity.

  In addition to the issues noted by others I will also point out that
information is being extracted from TLS for use in (the exchange
erroneously described as) "EAP-MSCHAPv2" in a way that is different than
the way being proposed by the TLS WG and does not include a binding to
the application.

  I don't believe a stable reference of these proprietary hacks is
necessary because the lack of an RFC to reference them has not stopped
them from being implemented. Whatever process has been used in the
past to convey their specification can be used going forward.

  draft-cam-winget-eap-fast-provisioning claims a reference to RFC 5226
but nowhere in that RFC can I find description of the following label
for an initial assignment of repository values:

  "allocated for management by Cisco"

yet the draft instructs IANA to set aside values 11-63 for just that
purpose. I think that's very inappropriate. Not only is it telling IANA
to cede some of its authority to a large multinational corporation but
it is decidedly *NOT* documenting existing use! If this whole exercise
is to document existing use then where are the specifications for these
PAC attribute types?

  The recommended note does nothing to stop this kind of abuse in the
future because the pain you mention is not felt by the one doing
the abuse.

  To condone one transgression is to invite one thousand more.

  regards,

  Dan.

On Sun, February 1, 2009 12:46 pm, The IESG wrote:
> 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.
>
> On behalf of the IESG,
>   Russ
>
> _______________________________________________
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>