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

From: Jari Arkko <[email-masked]>
Date: Sun, 01 Feb 2009 23:31:48 +0200

Speaking as an individual, I'm fine with this. It is important to 
document the EAP methods as they actually exist in wide deployment. That 
being said, we should also recognize the problems that codepoint 
overloading causes (even if the overloading issues are somewhat 
mitigated by the context ie tunnel in this case).

And we should definitely NOT follow the same type of overloading in 
future work. Obviously not in IETF work, but I also hope that the main 
vendors have gotten the message that it is a bad idea.

Jari

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

---

From: The IESG <[email-masked]>
Date: Sun, 1 Feb 2009 12:46:29 -0800 (PST)

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

---

From: Chris Hessing <[email-masked]>
Date: Mon, 02 Feb 2009 11:14:35 -0700

Jari Arkko wrote:
> document the EAP methods as they actually exist in wide deployment. 
> That being said, we should also recognize the problems that codepoint 

While I strongly disagree with overloading of EAP types, I have to agree 
with Jari.   I would like to see the IETF take a strong stance on not 
allowing overloading of EAP types in the future.  However, at this point 
there are probably too many implementations to try to change, so it 
seems documentation of existing behavior may be the only reasonable 
course of action.

That said, I would still like to see the provisioning document call out 
the security issues related to the use of anonymous provisioning.
_______________________________________________
Emu mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/emu

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 3 Feb 2009 09:56:46 +0700

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

---

From: Dorothy Stanley <[email-masked]>
Date: Tue, 3 Feb 2009 08:13:29 -0800

The interoperability concern with existing EAP-MSCHAPv2 and EAP-GTC
implementations and incorrect re-use of EAP Types must be
addressed/corrected prior to publication.

One solution is to

(a) Get a new, correct type number for use by the method in the published
document, and change the name of the method
(could use "name-CR" for "corrected/revision", or similar). This eliminates
the interoperability concern with existing methods,
and uniquely identifies the IETF published method.

and

(b) Add descriptive text in the document to explain the difference between
this IETF published method and similar  deployed
methods - to meet the desire to document deployed methods.

Dorothy Stanley

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 3 Feb 2009 12:59:50 -0800 (PST)

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.