Subject: [eap] Position paper on completeness

From: [email-masked] (Bernard Aboba)
Date: Fri, 4 Oct 2002 04:37:02 -0700 (PDT)

EAP State Machine Completeness
Position Paper, Oct 1, 2002
Jari Arkko, Ericsson Research NomadicLab

1. INTRODUCTION

The completeness of the state machine from draft-payne-eap-sm-00.txt
was analyzed. By completeness, we mean that the state machine contains
a description of what to do for all possible events in all states.

Note that in some cases we may well ignore an event, but this
should be done on purpose and we should document it clearly.
If not, we often tend to forget some events that should have
been handled with something else than silent discard. We
have already debated a number of issues which are specific
examples of the current underspecification that the original
RFCs as well as the state machine proposals have, such as
when can NAKs come.

2. EVENTS

The events that can come to a peer are:

- ID Request
- Method Request (many types and subtypes)
- Notification
- Success
- Failure
- Protocol error (i.e. anything else, such as a NAK
   sent to the client -- this could be debatable
   whether we need to deal with this. But some
   protocols make a state transition e.g. close
   connection upon getting these.)

The events that can come to an authenticator are:

- ID response
- Methods response
- Notification ack
- NAK
- Protocol error

3. PEER STATE MACHINE

Some states in this state machine are just temporary transitions,
such as the peer identification state, where we simply respond
with an identity response and return back to unauthenticated state:

- Initialized
- Peer identification
- Invalid request
- Authenticated

The states on which some waiting of events occur are as follows:

- Unauthenticated
- Method state machine

We will study these two states in detail. We note that the Unauthenticated
state does not handle the Failure, Notification, or protocol error events.

The method state machine state does not handle Identity request, Method
request (perhaps this is thought to be on a lower level at the specific
method state machine), Notification, and protocol error events.

3. AUTHENTICATOR STATE MACHINE

Again, the states which aren't real states in the usual definition
of the term are:

- Initialization
- Failure
- Authenticated

The real states which we will study are:

- Unauthenticated
- Peer identification
- Method state machine

The Unauthenticated state does not handle Notification Response,
NAK, and protocol error events (we suspect the right action
in these cases would be silent discard).

The Peer identification state does not handle
Method response, NAK, Notification, or protocol error
events. Note that we have already discussed the situation
where NAK might be used to signal that we don't want to
give an identity.

The Method state machine state does not handle Notification response,
Identity response, or protocol error events. It also doesn't
really handle Method response event, but again we suspect this
was expected to be done at the lower layer, in the specific
method state machine.

4. FURTHER WORK

It is necessary to ensure that the state machines are complete and
we have knowingly decided to ignore the events that currently are
ignored. We have already begun to debate some of the individual
issues around this, such as when can NAKs come.

In the above analysis, we have not yet taken a final stand
on whether the right action in some of these cases is something
else than silent discard. If the right action is silent discard,
then everything is currently OK.

It is also necessary to take a similar look at the 802.1aa D3
state machines.