Subject: [eap] Issue 116: Success and Failure fixes

From: [email-masked] (Bernard Aboba)
Date: Sat, 26 Apr 2003 18:02:49 -0700 (PDT)

Issue 116: Success and Failure fixes
Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: April 25th, 2003
Reference:
Document: EAP-02
Comment type: T
Priority: S
Section: 4.2, 4.2.1
Rationale/Explanation of issue:

Delete Section 4.2.1 and change Section 4.2 to:

"4.2 Success and Failure

The Success packet is sent by the authenticator to the peer
after completion of an EAP authentication method
(Type 4 or greater), to indicate that the peer has authenticated
successfully to the authenticator. The authenticator MUST
transmit an EAP packet with the Code field set to 3 (Success). If
the authenticator cannot authenticate the peer (unacceptable
Responses to one or more Requests) then after unsuccessful
completion of the EAP method in progress, the implementation MUST
transmit an EAP packet with the Code field set to 4 (Failure). An
authenticator MAY wish to issue multiple Requests before sending a
Failure response in order to allow for human typing mistakes. Success
and Failure packets MUST NOT contain additional data.

EAP Success or Failure packets MUST NOT be sent by an authenticator
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.

A summary of the Success and Failure packet format is shown below.
The fields are transmitted from left to right.

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Code       |    Identifier |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Code

3 for Success
4 for Failure

Identifier

The Identifier field is one octet and aids in matching replies to
Responses. The Identifier field MUST match the Identifier field
of the Response packet that it is sent in response to.

Length

4"