Subject: [eap] Position paper: When can Notification, Identity, etc. be sent and accepted?

From: [email-masked] (Bernard Aboba)
Date: Sat, 28 Sep 2002 09:35:31 -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?

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 is *not* an error message, and so sending or receiving
Notification Request/Responses does not change the state of the peer or
authenticator. The peer MUST send a Notification Response to a
Notification Request sent by the authenticator.

An EAP Notification Request may be sent at the behest of an EAP method
running on the Authenticator, as part of the method. This implies that a
Notification Request may only be sent after a method has been proposed
by the authenticator and accepted by the peer.

Use of EAP Notification messages MUST be described as part of the method
specification. Since the EAP Response does not contain any data, and no state changes
result from receipt of a Notification message, it should not be assumed that the
Notification Request message is processed by the EAP method on the peer; the
Notification Response is sent automatically.

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.

When are Success or Failure message sent?

EAP Success or Failure messages are sent by the authenticator EAP
layer. When it completes, an EAP method indicates the result of the
authentication to the EAP layer, by setting the Result=Success or Failure.
If the method is the last in a sequence of methods, then the authenticator
EAP layer will send the corresponding EAP Success or Failure message to the
peer. If the method is not the final in the sequence, then the
authenticator EAP layer will propose another EAP method to the peer.

Note that in order for a method to be usable within a sequence of methods,
the final message sent within the method (prior to transmission of an EAP
Failure or Success) MUST be an EAP Response. Otherwise, since EAP is an
ACK/NAK protocol, there would be no way for the authenticator to send an
EAP Request proposing another method.

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, requesting it to discard EAP packets not meeting the filter
criteria prior to completion of the EAP method. 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 completes.

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 within the
EAP layer:

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

This will cause the peer EAP layer to silently discard messages of types
Identity, Notification, Success and Failure until the filter is removed or
the method completes. 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