Subject: [eap] issue 121 (meaning of successful authentication)

From: [email-masked] (Jari Arkko)
Date: Mon, 02 Jun 2003 01:07:39 +0300

Suggested text, modified based on what the issue site
already contained. Add to the terminology section:

"Successful authentication

In the context of this document, "successful authentication"
is an exchange of EAP messages, as a result of which the
authenticator decides to allow access for the peer, and the
peer decides to use this access. Note that the authenticator's
decision typically involves both authentication and
authorization aspects; the peer may provide correct input
for the authentication method but not be allowed to access
due to policy reasons.

<add something here depending on whether failed auth means
you can still continue, see my other e-mail>"

Change the following text in Section 4.2 from:

"EAP Success or Failure packets MUST NOT be sent by an EAP server
prior to completion of the final round of a given method. A peer EAP
implementation receiving a Success or Failure packet prior to
completion of the method in progress MUST silently discard it. By
default, an EAP peer MUST silently discard a "canned" EAP Success
message (an EAP Success message sent immediately upon connection).
This ensures that a rogue authenticator will not be able to bypass
mutual authentication by sending an EAP Success prior to conclusion
of the EAP method conversation.

Implementation Note: Because the Success and Failure packets are
not acknowledged, the authenticator cannot know whether they have
been received. As a result, these packets are not retransmitted by
the authenticator. If acknowledged result indications
are desired, these MAY be implemented within individual EAP
methods. Since only a single EAP authentication method is
supported within an EAP conversation, a peer that successfully
authenticates the authenticator MAY, in the event that an EAP
Success is not received, conclude that the EAP Success packet was
lost and enable the link."

To:

"EAP Success or Failure packets MUST NOT be sent by an EAP server
prior to completion of the final round of a given method. A peer EAP
implementation receiving a Success or Failure packet prior to
completion of the method in progress MUST silently discard it. By
default, an EAP peer MUST silently discard a "canned" EAP Success
message (an EAP Success message sent immediately upon connection).
This ensures that a rogue authenticator will not be able to bypass
mutual authentication by sending an EAP Success prior to
conclusion of the EAP method conversation.

Implementation Note: Because the Success and Failure packets are
not acknowledged, they are not retransmitted by the authenticator,
and may be potentially lost. A peer MUST allow for this circumstance.
If acknowledged result indications are desired, these MAY be
implemented within individual EAP methods.

On the peer, once the method completes unsuccessfully, the EAP
conversation is terminated, the link is disabled, and a Success
packet MUST be silently discarded by the peer. As a result,
loss of a Failure packet need not result in a timeout.

As described in Section 2.1, only a single EAP authentication method
is allowed within an EAP conversation. A peer that successfully
authenticates the authenticator MUST silently discard Failure packets
and MAY, in the event that an EAP Success is not received, conclude
that the EAP Success packet was lost and enable the link.

Where the authenticator wishes to deny access even where the peer
authenticated successfully (e.g. where the peer is not currently
authorized to get access), this can result in lengthy timeouts unless
either the method provides authorization-related error messages or
a lower layer failure indication is provided. For example,
within EAP-TLS [RFC2716], the "access_denied" TLS alert can be
used to indicate that a valid certificate was received, but when
access control was applied, the authenticator decided not to proceed.
If a method provides such error messages, the authenticator SHOULD use
them and SHOULD provide information that agrees with the final
decision of the authenticator.

Section 3.4 provides guidance on the processing of lower layer
success and failure indications."