Subject: [eap] Minutes from 9/25/02 EAP Design team meeting

From: [email-masked] (Bernard Aboba)
Date: Wed, 25 Sep 2002 10:34:07 -0700 (PDT)

EAP Design Team Meeting Minutes
Paul Congdon, HP
09/25/02

Yoshi's Paper

1.	Issue 1 - How to handle notational conventions within state
diagrams.  There is also an issue relating to handling of the timing.
"	Suggest two solutions - use an already defined convention (e.g.
IEEE 802.1X) or use other current and more formal conventions.    Chuck
believes current format is less formal and unclear on how steps within a
state are executed and whether they are atomic or not.  Paul suggests
adding words from 802 documents that clarify.  Other believe that real
events should be noted in the transitions not just variables.
"	Bernard raises a question about sub-machine interactions and the
entrance points.  Unclear what information is available to methods. For
example, is information in an Identity exchange available to the method?
What about Nak? Notification?  Wording can be added to clarify entry
points.
"	Do methods need to know about one another?  If so, how is
communication facilitated?  We don't want to allow this to be an exercise
for the reader.  Perhaps RFC2284bis needs an abstract API to allow this?
"	The concept of an EAP mux helps clarify how the state machines
interact.
"	Seems to be some agreement that we can slightly deviate from the
802 machine format, but keep the spirit intact such that it is obvious to
the reader. This makes it easier to synch the EAP and 802.1X state
machines.
2.	Issue 2 - Identity exchange is optional, but the authenticator
machine doesn't really support it well.
"	Some would prefer to see ID exchange as simply one of the methods.
However, would the ID method ever occur without other methods invoked?
Not likely, but certainly multiple IDs exchanges could be possible.
Methods can't interrupt other methods.  There is an assumption that a
variable exists that controls the authenticator to send or not the ID.
This variable is not specified in 802.1X or the EAP state machine
document.
"	From the Radius server's point of view, the ID exchange starts out
as a method, but RADIUS servers often receive the Access Request after the
ID Request has been sent by the Authenticator, answered with an ID
Response from the Supplicant, and the Identity placed in a User-Name
attribute.  So the RADIUS server typically does not request an Identity
exchange.
"	There is a need for a needID variable that drives the backend
state machine as well.  It actually describes what the first step is for
each method.  How is this variable controlled when multiple methods are
changed. For example, if needID is set then the Authenticator starts out
by sending an Identity Request. If not, then it sends an Access-Request to
the RADIUS server (which can't contain a User-Name attribute because the
identity isn't known yet).
"	Consensus that a needID is needed, but unclear how it is
controlled still.  Still unclear if ID exchange should be thought of as a
method.  If it is a method, do we still need needID?   If it is a method,
it should fold into the current proposed machines without significant
disruption.   No conclusion yet if ID exchange is a method.
3.	Issue 3 - Inconsistency when processing NAK.
"	Can't a NAK break the in-progress EAP method?  Typically this
means the supplicant doesn't want to run this method, so he NAKs with
alternatives.  It is up to the authenticator to decide what method will
run next if any.
"	It appears that currently the NAK can be sent anytime, so perhaps
it should be its own machine.  It can be sent in the middle of a method to
abort is, but some don't like this behavior, because it allows an attacker
to stop an authentication in progress.  The objective of the Nak message
is to negotiate a method (it has also been used for negotiation of a
sub-method within the method, but not clear it is appropriate for that),
but should it be used to abort the method?  The NAK as an abort doesn't
fully describe why the abort is taking place, so perhaps an error or abort
message needs to be created.   There is no notification message from the
peer to the authenticator.   Sending anything in the middle of an exchange
could be an issue anyway from a security point of view.  If you simply
stop responding to the exchange in the middle, it will timeout eventually
and another method proposal will come along.  This could be NAKed at that
time.
"	There seems to be consensus that NAK should only be used for
method negotiation.  For aborting we should do something different.
Choices include keep it the same, timeout, new message, NAK with
parameter, etc.  These choices need to be explored further.
"	It was noted that the method really starts with the first message
and the NAK is a response to the first message of the method, so reception
of the NAK is really just a condition of the method.  However, each method
really needs to start out in a proposal phase where NAK is one possible
response.  How does the mux know what is going on here?   Does the mux
keep state, and know when the proposal phase has ended (after which NAK is
no longer allowed)?
"	Another topic to discuss is acknowledgements of success and
failure messages. This isn't possible in RFC 2284, but perhaps a new
message is needed?
"	Timer events in the state machines aren't described.  This is
tricky because user input changes all the timing.
"	Another issue raised is how much constraint can we put on all EAP
methods?  Is the EAP method state machine a black box or must it conform
to some more specific guidelines or some specific required states. For
example, is there an abstract API that describes how an EAP method
interacts with the mux and the EAP state machine? For example, are there
variables set within the method that influence behavior of the mux? For
example, the method might tell the mux whether authentication had
succeeded or failed, etc.