Subject: [eap] This week's position papers

From: [email-masked] (Bernard Aboba)
Date: Sat, 5 Oct 2002 08:47:43 -0700 (PDT)

Position Paper: When can Notificaton, Identity, NAK, Success
                            and Failure messages be sent and accepted?
            10/2/02
            Bernard Aboba
            [email-masked]

When can a NAK be sent?

A Nak is sent by the peer in response to a method proposal by the
authenticator.

The authenticator proposes a method. The peer can accept the proposal (by
replying with an EAP method of the same type), or NAK the proposal. Once
the proposal is accepted, a NAK cannot be sent by the peer until a new
method has been proposed. NAKs are never sent by the authenticator, nor
are they sent by the peer in response to a method whose proposal has
already been accepted.

When can a Notification be sent?

EAP Notification Requests can be sent by the authenticator at any time.
EAP Notification Responses MUST be sent by the peer in response to a
Notification Request sent by the authenticator.

EAP Notification is *not* an error message, and so sending or receiving
Notification Request/Responses does not change the state of the peer or
authenticator.

It is assumed that Notification Responses are sent automatically by the
EAP layer, so that it cannot be assumed that a Notification Request is
delivered to the running EAP method.

When can an Identity Request be sent and accepted?

The rules for sending an Identity Request are the same as with any other
method. An Identity Request may be sent multiple times within a single EAP
conversation, as is the case for any other method.

As with any other method, an Identity Request can be NAK'd by the peer.

When is the Success or Failure message sent?

EAP Success or Failure messages are sent by the authenticator EAP
layer. When it completes, an EAP method residing on the
authenticator indicates the result of the authentication to the EAP layer
(Success or Failure). If the method is not the final one in the sequence,
then the authenticator EAP layer will propose another EAP method to the
peer. The Success message, if sent at all, is only sent after the
successful completion of all the authentication methods in a sequence.

Note that some EAP methods do not permit other methods to be used
afterward as part of a sequence. For example, an EAP method that
terminates after sending an EAP Request cannot be followed by another
method, since no EAP Response will be forthcoming, and therefore the EAP
conversation cannot be continued. This implies that a sequence involving
such a method cannot be terminated with an EAP Success or Failure message.
This does not cause a problem, assuming that the method supports its own
Success and Failure indications.

When can a Success or Failure message be accepted?

EAP methods may include their own (protected) success and failure
indications. Since EAP does not provide support for error messages, several methods
have implemented method-specific error message capabilities. For example,
TLS-based methods utilize TLS alerts, which are protected within the TLS channel,
in order to transmit error messages.

Similarly, methods also implement method-specific success indications. For
example, a method suporting mutual authentication will expect the
authenticator to complete authentication prior to completion of the method.

As a result, a method specification may indicate that the method only
expects to receive cleartext EAP Failure and Success messages under
certain conditions. For example, a cleartext Success message is only expected
once mutual authentication has been completed, or a cleartext Failure
message is only expected after receipt of a protected failure
indication such as a TLS alert.

These directives can be indicated via a filter interface between the
method and the EAP layer.  An EAP method can install a filter in the EAP
layer, causing the mux to silently discard EAP packets not meeting the
filter criteria while the EAP method is in operation. The operation of the
filter MUST be described in detail within the EAP method specification, to
enable interoperability. Filters installed by methods are automatically
removed once the method terminates operation.

For example, an EAP method can negotiate a key early on, and after that,
may want to require that all EAP packets be protected using the derived
key until a protected success/failure indication is received. To achieve
this, the method on the peer may install the following filter:

(1) ACCEPT: Code = Request, Type=MyMethod
(2) DENY: all

This will cause the peer mux to silently discard messages of types Identity, Notification,
Success and Failure until the filter is removed or the method terminates.
Once a protected Success indication is received (e.g. the authenticator
completes mutual authentication), the filter list can be changed to:

(1) ACCEPT: Code = Request, Type=MyMethod
(2) ACCEPT: Code = Success
(3) DENY: all

Similarly, once a protected failure message is received, a filter can be
plumbed enabling the reception of an EAP Failure:

(1) ACCEPT: Code = Request, Type=MyMethod
(2) ACCEPT: Code = Failure
(3) DENY: all

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.