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

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

Nancy Winget ([e-mail]) writes:

Dave and Dorothy:

We don't believe there are interoperability issues, as the intended
informational RFCs clearly describe the protocol and packet format over the
wire for these inner methods specifically when running inside EAP-FAST. The
so called "interoperability issue" raised is at most an implementation
issue, only applies to certain software environments where the same inner
methods are used both inside and outside EAP-FAST, and could be worked
around. This is demonstrated by the numerous existing client and server
implementations already deployed in the field (most of which support these
inner methods both inside and outside EAP-FAST), and lack of reporting of
this issue. The intent of these drafts is informational and to clearly
document the existing implementations started 5 years ago. Assigning new EAP
types isn't going to solve any interoperability problems, but is likely to
generate new ones.

It appears that you mistake the purpose of the IETF as being to enhance
proprietary protocols.  I, for one, couldn't care less if two
implementations of some Cisco Systems proprietary nonsense interoperate or
not; however, I do care about hijacking EAP type codes & subversion of the
IETF process for essentially marketing purposes.  It's hard to imagine what
interoperability problems could be caused for a pair of EAP-GTC
implementations by changing the type code and name of EAP-FAST-GTC to
something more appropriate (say, 666 & EAP-PAP ;-).

 If we were to redesign today, certainly we would probably take a different
approach to make the software implementation easier. We are open to all of
your suggestions for enhancements on the next version of EAP-FAST. 

Given that you've had 5 years to get it right & failed, it's hard to believe
that "suggestions for enhancements" would have much effect.

We believe these drafts have documented these potential points of confusion.
The difference between EAP-MSCHAPVv2 inside and outside EAP-FAST is
documented in draft-cam-winget-eap-fast-provisioning. As for EAP-FAST-GTC,
the draft-zhou-emu-fast-gtc documents the difference it has with EAP-GTC in
turns of handling password authentication. As for regular OTP or token
authentication, the implementation could strip the labels and pass the rest
to the regular EAP-GTC state machine. 

Sorry, I'm just ignorant: can you tell me where "the regular EAP-GTC state
machine" is defined?

How GTC handles the token exchanges is outside the scope of this draft
(under defined in RFC3748). If you do see areas of requiring more
description of the differences, we are certainly open to suggestions. 

 

  _____  

From: [e-mail] [mailto:[e-mail]] On Behalf Of David
Mitton
Sent: Tuesday, February 03, 2009 12:32 PM
To: [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [Emu] Potential Notes in EAP-FAST Documents

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


Feb 3, 2009 11:13:36 AM, [e-mail] wrote:

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

On Mon, Feb 2, 2009 at 6:56 PM, Glen Zorn <[e-mail]> wrote:


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

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.


> On behalf of the IESG,
>   Russ
>
> _______________________________________________
> Emu mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/emu

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

 

  _____  


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