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

["Dan Harkins" <[e-mail]>]

  If the IESG doesn't want to hear opinions then maybe it shouldn't ask.
Since it did (this thread started with a post from "the IESG") then
it should listen to the opinions it solicited. With all due respect,
don't shut off this discussion with a "reminder" that these documents
went through IETF Last Call.

  The track of proposed publication really has nothing to do with my
comments (I can't comment on other people's comments). It is the content
of the documents, the haphazard manner in which they were constructed,
the disregard for standard ways of doing things they attempt to do,
and the blatant arrogance of the IANA considerations that really chaps
my hide.

  Can I instruct IANA to assign management of numbers in a newly created
registry to "The Daniel Harkins Trust"? No, probably not. I would expect
that  would generate lots of protests. And justifiably so. So let me ask
you (as a member of the IESG), why do you think it's OK to cede parts of
IANA's authority to Cisco Systems, Incorporated?

  Dan.

On Wed, February 4, 2009 11:33 pm, [e-mail] wrote:
> I would like to remind everyone that these documents did go through
> IETF Last Call, and have already been approved by IESG.
>
> 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.
>
> (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...)
>
> 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.
>
>
>
> _______________________________________________
> Emu mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/emu
>