Subject: [eap] RE: Creating a design team for EAP state machine

From: [email-masked] (CONGDON,PAUL (HP-Roseville,ex1))
Date: Fri, 6 Sep 2002 12:58:20 -0700

I am interested in participating on this team.  I will be traveling next
week, but should be within reach of email now and then

Paul

+------------------------------------------+
Paul Congdon
HP ProCurve Networking
Hewlett Packard Company
8000 Foothills Blvd - M/S 5662
Roseville, CA   95747
phone: 916-785-5753
email: [email-masked]
+------------------------------------------+

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Friday, September 06, 2002 12:57 PM
> To: [email-masked]; [email-masked]; 
> [email-masked]; Glen Zorn; [email-masked]; 
> [email-masked]; Robert Moskowitz; CONGDON,PAUL 
> (HP-Roseville,ex1); William Arbaugh
> Cc: Bernard Aboba
> Subject: Creating a design team for EAP state machine
> 
> 
> 
> RFC 2284 does not include a state machine, and as a result, 
> questions have arisen about the behavior of the protocol, 
> which are not addressed in that document. Given the revision 
> to the specification RFC 2284bis, the desire is to develop a 
> separate document describing in detail the state machine 
> behavior of EAP.
> 
> We have considered various ways to organize the production of 
> the state machine. A draft about the state machine exists, 
> but some work still remains on e.g. harmonizing the state 
> machine with IEEE work. We considered an interim meeting, but 
> it proved to be hard to get a sufficient number of people in 
> the same place at the same time.
> 
> Bernard and I have decided that we would like to create a 
> short-term design team to work on the state machine. We are 
> soliciting members for the design team. If you are willing to 
> help, let us know. We are hoping the design team could be in 
> place within a week or so, and could include those who have 
> worked on the current state machine as well as folks who have 
> knowledge of other aspects of the problem. Note that as 
> participation in IETF is open, folks working on EAP-related 
> issues in other standards bodies are also welcome.
> 
> The output of the design team is an IETF draft on the EAP 
> state machine, to be presented to the EAP WG at IETF 55. 
> Desirable aspects of the state machine include:
> 
> a. Rationalized with the IEEE 802.1aa D3 state machine, so that either
>     the two state machines are compatible, or the differences are well
>     understood and it can be explained why the IEEE 802.1aa D3 state
>     machine needs to change.
> 
> b. Compatible with all aspects of RFC 2284bis, including:
> 
>      1. Optional Identity exchange. The state machine should 
> not assume
>         that an identity exchange will always occur, since RFC 2284bis
>         does not make this assumption.
> 
>      2. Support for multiple authentication methods within a 
> single session.
> 
>      3. Support silent discard of EAP Success prior to authentication
>         completion.
> 
>      4. Compatibility with RFC 2869bis -- backend state 
> machine determined
>         solely by Accept/Reject AAA indication, not encapsulated EAP
>         packet, if any.
> 
>      5. Compatibility with reauthentication and retransmission.
> 
> It is expected that the design team can solve the
> above issues. If there are remaining problems by IETF 55, the 
> design team should describe them and the alternatives for 
> resolving them.
>