Pasi Eronen (pasi.ero...@nokia.com) 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: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of ext Bernard Aboba Sent: 04 February, 2009 21:25 To: emu@ietf.org 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.
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu