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. 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.
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. 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: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On
Behalf Of David Mitton
Sent: Tuesday, February 03, 2009 12:32 PM
To: dstanley1...@gmail.com
Cc: hous...@vigilsec.com; i...@ietf.org; emu@ietf.org
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, dstanley1...@gmail.com 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
<glenz...@comcast.net> 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
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
________________________________
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
