Subject: [eap] Additional 09/25/02 Design Team Minutes

From: [email-masked] (Bernard Aboba)
Date: Wed, 25 Sep 2002 14:59:54 -0700 (PDT)

EAP Design Team Tele-conference Minutes

Date: 11am-12pm, September 25, 2002

Participants: Bernard Aboba, Jari Arkko, Paul Congdon*,
              Robert Moskowitz, Yoshihiro Ohba*+, Bryan Payne,
	      Nick Petroni, John Vollbrecht

              *Minutes takers
              +Minutes taker of this memo

(Please point out if your name is missing or you were not
 participated in the conference call.)

Minutes:

All participants agreed on the proposed approach based on two position
papers, one for reviewing 802.11a (topic a) and the other for reviewing
the EAP state machine draft (topic b).  Both position papers include
comparison with the RFC2284bis draft.

The following issues related to topic b were discussed (the issues are
described in a write-up posted on the EAP design team mailing list by
Yoshihiro Ohba):

o  Notational conventions for state diagrams
o  Optional identity support
o  NAK message handling

1.  Notational conventions for state diagrams

Precise definition for notational conventions is required for the
state machine.  It was agreed that using the conventions used in the
IEEE 802.1X specification with allowing some augmentation is better
for the following reasons:

  - 802.1X conventions are precise

  - By using 802.1X conventions, EAP state machine
    would be better aligned with 802.1X state machine.

  - On the other hand, boolean variable-based event transition
    defined in 802.1X might not be useful if we consider simplicity
    for the state machine description.  So some augmentation by
    allowing "real-event" based state transition would be better.

It is pointed out that in the Authenticator SM (State Machine) there
are multiple entrance points from a sub-SM (i.e., Method Authenticator
SM) and there is a question that the sub-SM behavior may depend on
which entrance point is used.  However, in the case of EAP, the
sub-state machine behavior should not depend on where the transition
came from, meaning that some additional convention for describing each
method SM (e.g., every method SM starts from a single initialization
state) might be necessary.

There is another issue on what information is available from each
method SM (e.g., each method SM may require Identity information).
This might be an issue of EAP abstract API.

2. Optional identity support

The RFC2284bis draft describes that Identity message exchange
is an option, but the EAP state machine is not sufficient
to support the option.

A flag variable "NeedID" is needed to indicate whether identity
exchange is required or not.  The variable is initialized within
initPolicy().  It is also necessary to be able to change the value of
this flag in the mid of authentication (at the beginning of each
method) when multi-authentication is used, since some methods in a
multi-authentication session may require identity exchange while
others may not.

There is an open issue on whether the state for handling Identity
exchange should be defined in a distinct method SM or in the
multiplexer SMs (i.e., outside of any method SM, as described in the
current state machine draft).

3.  NAK message handling

There is an issue on where to define the state for handling NAK
message.

A NAK message MUST NOT be used for "aborting" the current method in
the mid of the method and should be used for the first EAP Request
message of the current method only.

There are two approaches to achieve this:

- define a state for handling NAK message outside of each method SM,
  perhaps with defining a global variable that indicates whether the
  NAK message can be processed or not (the value of the variable can
  be set by each method SM).

- define a state for handling NAK message in each method SM.

4.  Candidate issues to be discussed in the next tele-conference:

o  Remaining issues described in the write-up by Yoshihiro Ohba

o  Position paper from UMD

o  EAP multiplexer issues posted by John Vollbrecht

o  Any discussion on topic a.