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

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

Pasi Eronen ([e-mail]) writes:

 

I would like to remind everyone that these documents did go through
IETF Last Call, and have already been approved by IESG.

Given the quality of the documents in question, perhaps that's not something
that you should be bragging about.

If folks are opposed to publishing descriptions of deployed EAP method
when they're less than perfect (or even ugly hacks with bad architecture), 

and may not offer perfect security in all circumstances (but accurately 

document their limitations), they should have said so much earlier.

No offense, but I'm getting the real feeling that you're just not paying
much attention.  The major problems I've heard WRT publication as-is have to
do with the misuse of IANA registries, not ugly hacks or "imperfect
security". 

(In hindsight, publishing these via the RFC Editor independent submission

route, and including the vendor's name in the document title, might

have been better idea. Since the intent was to describe what existing

implementations do, the IETF does not realistically have much change

control...)

Publishing them as individual submissions would have been a better idea I
don't see how that would solve the IANA problem.    

Best regards,
Pasi

 


  _____  


From: [e-mail] [mailto:[e-mail]] On Behalf Of ext
Bernard Aboba
Sent: 04 February, 2009 21:25
To: [e-mail]
Subject: Re: [Emu] Potential Notes in EAP-FAST Documents

"

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





Although I concur with the assessments of Glen Zorn, Dan Harkins,


David Mitton and Dorothy Stanley in many respects, I would suggest that


those concerns are outweighed by the IETF's mission to make information


on deployed protocols available to the community.  As a result, I 


believe that the documents should be published, provided that the


following concerns can be addressed:





a. Name confusion.  The use of the term "EAP-FAST-GTC" instead of


EAP-GTC helps clarify that the two protocols are significantly


different.  Similarly, the use of the term "EAP-FAST-MS-CHAPv2"


would help clarify differences between the implementations of


EAP MS-CHAPv2, which I believe go beyond just the use of the


challenge field (e.g. internationalization support). 





b. EAP architecture changes.  Suggesting that EAP methods behave


differently when run within a TLS tunnel negotiating a particular


ciphersuite represents a major change to the EAP architecture


as well as to tunneling methods other than EAP-FAST.  This 


suggestion, if made at all, needs to be restricted solely to


use within EAP-FAST. 





c. EAP negotiation issues.  Neither the IESG note nor the


text explicitly states what is wrong with using an EAP Type 


Code for incompatible versions of an EAP method that does not


support version negotiation.  Indeed, it would appear that some


members of the IESG think that method overloading is required


by EAP tunneling methods desiring to incorporate support for


cryptographic binding.  Saying that this "might be difficult


in some software environments" isn't a good characterization. 


Would the IESG use the same words to describe the reuse of


IP protocol numbers within an IP tunnel?  I doubt it. 


Glen Zorn said:

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


David Mitton said:

I'm sorry,  I haven't responded earlier either, but I would like to pile on
with some of my comments.
When I read the Cisco EAP-FAST GTC description and was similarly shocked by
the nature of the changes, and how poorly they technically met their own
rationale.
Encoding the "REQ=" and "RESP=" into Request and Response text, is
absolutely useless, since the data flow is unidirectional and known to the
requester/responder peers.
And then claiming that is more efficent because the username and OTP are
combined in one response, really ignores the issue that GTC doesn't define
what the appropriate response is.  And they did nothing to clue the client
as to what is being requested, or the format of the response.
Given that, a Client can only strip the useless cybercrud, and continue with
the normal GTC state machine which is let the user type something in and
send it.
A more robust OTP implementation may have several different inputs that it
wants from the user besides for username and OTP.  (BTW; username could be
derived from the EAP Identity)   There are possible next token challenges,
new PIN assignment (user or system generated)  and followup
re-authentications.   Their protocol did nothing to codify a standard for
interoperation where a sequence of requests were enumerated or named, and
response items were described.  
I'm all for documenting practice, but this design/implementation doesn't
really seem to solve anything and just creates more confusion.
Dave Mitton

Dan Harkins said:

  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.