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

[<[e-mail]>]

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.