Hi,
This is certainly an interesting thread and one I have a deep interest
in :-) I understand that we are still solidifying the method
requirements for this group so it is timely to be raising and discussing
requirements.
I also agree with Alan that we can discuss how EAP-FAST meets (or does
not) the requirements, though, without having an agreed upon
requirements document, the discussion seems premature. I greatly
appreciate the discussion on EAP-FAST thus far and welcome the continued
feedback directly to me (or my co-authors) as I understand the use of
EAP-FAST in provisioning mode is not in this group's scope and charter;
especially if you find issues with the current documents and in
particular, discrepancies between specifications and implementation.
Nancy.
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
Alan DeKok
Sent: Monday, January 26, 2009 11:47 PM
To: Chris Hessing
Cc: [email protected]
Subject: Re: [Emu] Potential Issues with EAP-FAST
Chris Hessing wrote:
> Then I must ask a stupid question. Who is the group that decides what
> should and shouldn't be allowed?
The chairs determine the focus of the group, guided by the WG charter.
> While I understand that the changes
> EAP-FAST makes to existing EAP methods are already published and have
> many implementations, it seems that allowing future EAP methods to
> make random changes is something that will ultimately lead to
> interoperability problems. It is just a bad precedent to allow to
> continue. I would be happy to raise this issue on a different list if
> there is one more appropriate. But where this is an EAP related issue
> this seemed to be the right list.
While this is the currently the only EAP WG in the IETF (IIRC), it has
a charter that specifies WG work items. Re-visiting EAP-FAST is not a
work item.
That being said, a discussion of EAP related issues *is* welcome on
this list, so long as it does not distract from work items. In relation
to EAP-FAST, the RFC was not a WG work item (from any WG). It did not
follow the normal WG review process, and may have issues caught by
additional reviewers.
>... For EAP-FAST provisioning anonymous provisioning is clearly
>spelled out as a possible mode of operation.
i.e. A "possible" mode of operation. Provisioning is not part of the
scope of this WG (see the charter). If EAP-FAST is chosen as the
tunneled method, it would be appropriate to forbid anonymous
provisioning in the EMU document describing the tunneled method.
> Further it bothers me more when
> I see a NIST document that indicates that EAP-FAST is the best choice
> for a secure, but easy to deploy, EAP method.
Do the NIST documents permit anonymous provisioning?
> However, again, if I am trying to get this discussion going in the
> wrong forum, please point me to a better one.
Discussions as to how EAP-FAST meets (or does not) the tunneled method
requirements are needed on this list. However, discussions of the
tunneled method requirements document are a higher priority right now,
because that document is unfinished.
Alan DeKok.
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
