Subject: [eap] Proposed EAP WG Charter

From: [email-masked] (Bernard Aboba)
Date: Thu, 21 Feb 2002 08:58:43 -0800 (PST)

To have an EAP WG, we need to have a Charter. Here's a first cut at an EAP
WG Charter. The goal is to focus on cleaning up the EAP specification for
the first 6 months, after which we can re-charter to work on additional
items. 

----------------------------------------------------------------
EAP Working Group (EAP)

Chair(s):
   This space for rent

Area Director(s):
   Thomas Narten <[email-masked]>
   Erik Nordmark <[email-masked]>

Security Advisors:
   Bill Arbaugh <[email-masked]>

Mailing Lists:

General discussion: [email-masked]
To subscribe: ?
Archive: ?

The EAP working group will restrict itself to the following short-term
work items in order to fully document and improve the interoperability of
the existing EAP protocol:

1.  IANA considerations. 
2.  Threat model and security considerations.
3.  EAP state machine.
4.  Clarification and documentation of EAP key usage.
5.  Documentation of interaction between EAP and lower layers.   
6.  Resolution of interoperability issues. 
7.  Type space extension to support an expanded Type space.
8.  Requirements for cryptographic protection of EAP. 
9.  Update of RFC 2869 (RADIUS/EAP)

Goals and Milestones

Jun  02   IANA considerations draft to RFC Editor.
Jun  02   EAP type extension section for RFC 2284bis. 
Jun  02   EAP Security considerations section for RFC 2284bis.
Jun  02   EAP state machine section for RFC 2284bis.
Sep  02   RFC 2869bis published as Proposed Standard RFC.
Sep  02   RFC 2284bis published as Proposed Standard RFC.
Sep  02   EAP keying framework doc published as Informational RFC.

---

From: [email-masked] (Glen Zorn)
Date: Thu, 21 Feb 2002 22:16:07 -0800

> the first 6 months, after which we can re-charter to work on additional

It seems rather wildly inappropriate to ignore the question of
analyzing/standardizing EAP types for six months (or, worse, as John V.
suggested, bail on performing any security analysis on them at all).  More
below...

I'll volunteer to chair the BOF (I have experience in the field ;-)

> General discussion: [email-masked]

Send a message containing the word "subscribe" in either the subject or body
to [email-masked]

> Archive: ?

http://mail.frascone.com/pipermail/eap/

> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
>

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 21 Feb 2002 22:23:02 -0800 (PST)

> suggested, bail on performing any security analysis on them at all).  More

There is a difference between working to clarify RFC 2284 and
"ignoring" work on additional EAP Types. Presumably, as issues are
clarified in RFC 2284bis, authors of EAP Methods will be updating their
drafts to conform to the newly clarified specification. The evidence so 
far is that a *lot* of that kind of clarification is needed. 

So rather, I think of the first six months as clarifying RFC 2284 and
the overall functionality of EAP so that it can be implemented
interoperably, and simultaneously bringing methods into conformance with
the newly clarified spec. 

Thus, while the WG may not be considering new methods, the authors will
presumably be doing quite a bit of work in the background. I also expect
the authors to be active in the discussion of RFC 2284bis -- asking
questions about how things are supposed to work, and debating whether this
or that practice is legal. 

Ultimately, I think this will *save* a lot of time -- because as it is, if
we were to try to analyze submitted methods, we would find ourselves
continually running into interoperability issues and fundamental
questions about how EAP works which we would need to clarify before we
could move forward. It makes more sense to try to address the major
issues up front, rather than piece meal. 

I also think that by focussing on getting the fundamentals done up front,
we have a much better chance of completing that work in an expeditious
way. If we were to try to analyze/standardize methods at the same time,
it's likely that we wouldn't have enough focus, and the fundamental work
would drag out.

---

From: [email-masked] (Glen Zorn)
Date: Fri, 22 Feb 2002 00:02:29 -0800

> "ignoring" work on additional EAP Types.

The distinction escapes me.

> Presumably, as issues are

Presumably, they would be doing that anyway...

> the newly clarified spec.

I could have sworn that it _had_ been implemented interoperably...

> or that practice is legal.

Why would they be doing this more than if there was no WG?

> could move forward.

Maybe, maybe not.  Hopefully, the people designing EAP types ahve _some_
idea of how it works already...

> It makes more sense to try to address the major

I have a feeling that the IESG would probably kill the group immediately
after this "fundamental" work was complete; the idea of an on-going group
that works on extensions doesn't fit neatly w/the IETF way.  Of course, this
would result in yet another WG that accomplishes something that's nice, and
useful, while ignoring the urgent and important.

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 21 Feb 2002 23:49:29 -0800 (PST)

> I could have sworn that it _had_ been implemented interoperably...

Unfortunately, there isn't enough data from the surveys we've gotten back
to demonstrate that many of the features have even been implemented by two
implementations, let alone that they interoperate. And in practice, quite
a few of the methods that have been proposed will *not* interoperate with
one or more AAA servers, NASes or clients. Some reasons:

a. Use of NAK or NOTIFICATION as part of the method
b. Data in EAP Success
c. Use of ciphersuite-specific key derivations in the method
d. Key derivation without key hierarchy support
e. Use of multiple Types within a single method
f. Sending of multiple EAP frames within a single round trip

> Why would they be doing this more than if there was no WG?

Presumably the WG will provide guidance on how the methods can developed
so that they will interoperate. Whereas if there were no WG this wouldn't
happen. 

> Maybe, maybe not.  Hopefully, the people designing EAP types have _some_

Unfortunately, the "idea" seems to vary according to the author's reading
of RFC 2284. Based on results, it seems that RFC 2284 is unclear in quite
a few places. 

> useful, while ignoring the urgent and important.

Well, even if that happens, we'll still be a *lot* better off than we are
now, because people will understand how to write EAP methods that will
interoperate. 

BTW, what methods do you consider "urgent and important" and why? And what
do those methods need to do? The charter can probably also include
development of requirements for what those methods need to do.