Subject: [eap] RE: Potential Resolution to Issue 121: Potential meaning of successful authentication

From: [email-masked] ([email-masked])
Date: Thu, 8 May 2003 11:59:21 +0300

Bernard Aboba wrote:

> Since only a single EAP authentication method is allowed 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. Failure packets MUST be silently discarded by
> the peer.

I think it would be clearer to document that EAP methods on the
peer can actually have three different end results, not just two
(success and failure). This would also explain why in some=20
circumstances the peer should discard Success or Failure packets,=20
or enable the link in case of timeout or link-layer indication.

How about this?

   "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, an EAP method can conclude with three different
   end results.

   [1] Failure: Either the authenticator has indicated that it
       will not allow access to the peer, or the peer does not wish
       to use this access (for instance, the peer has not
       successfully verified the server's identity, but its security
       policy requires this).

       In this case, the EAP conversation is terminated, and the
       link is disabled. As a result, loss of a Failure packet
       need not result in a timeout, and a Success packet MUST
       be silently discarded by the peer.

   [2] Unconditional success: The authenticator has indicated that
       it will allow access to the peer, and the peer wishes
       to use this access.

       The peer SHOULD, in the event that an EAP Success is not
       received, conclude that the EAP Success packet was lost
       and enable the link. Failure packets MUST be silently
       discarded by the peer.

   [3] Conditional success: The peer wishes to use the access,
       but it does not know if the authenticator will allow access=20
       or not.

       The peer MAY, in the event that an EAP Success is not
       received, conclude that the EAP Success packet was lost
       and enable the link. Failure packets MAY be silently
       discarded, but this can result in lengthy timeouts unless
       a lower layer failure indication is provided."

Best regards,
Pasi

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 8 May 2003 05:19:37 -0700 (PDT)

>        but it does not know if the authenticator will allow access
>        or not.
>

In the event that an EAP Success is not received, what is the difference
between 2 and 3?  Doesn't the peer *always* enable its link based on
whether it authenticated the authenticator within the method? If so, then
it would seem like the last sentence would apply to #2 as well, no?