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

From: [email-masked] (Bernard Aboba)
Date: Wed, 7 May 2003 08:55:04 -0700 (PDT)

The text of Issue 121 is given below. It is also available on the EAP
Issues web page (http://www.drizzle.com/~aboba/EAP/eapissues.html).

Discussion of this issue has disclosed some inconsistencies between the
EAP state machine document and RFC 2284bis. I'd like to propose that we
fix this by editing the text of Section 4.2 of RFC 2284bis, rather than
attempting to mandate behavior via changes to the terminology section.

In going over this issue, I noticed that RFC 2284bis did not mandate
silent discard of Success/Failure packets when they are inconsistent with
the result of the EAP method, except in the case where the method
supports "strict interpretation." Mandating this has some drawbacks
because it can result in long timeouts on the peer, unless the
authenticator utilizes lower layer indications.

Here are some proposed fixes. Comments welcome.

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."

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, 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.

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.

Where the authenticator wishes to deny access even where the peer
authenticated successfully (e.g. where the peer may not be authorized
for reasons of policy), this can result in lengthy timeouts unless a lower
layer failure indication is provided. Section 3.4 provides guidance on the
processing of lower layer success and failure indications."

-----------------------------------------------------
Issue 121: Document meaning of successful authentication
Submitter name: Pasi Eronen
Submitter email address: [email-masked]
Date first submitted: May 2, 2003
Reference:
http://mail.frascone.com/pipermail/public/eap/2003-May/001115.html
Document: EAP-02
Comment type: T
Priority: 1
Section: 1.2 (and possibly others)
Rationale/Explanation of issue:

It seems that in EAP we're using the word "authentication"
in somewhat non-standard sense, and I feel we should document
it.

Here's a first draft of text for section 1.2 (terminology):

"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.

This definition differs from the usual definitions of
authentication (e.g. "verification of claimed identity"),
since the authenticator may decide to deny access even when
the identity of the peer is known and verified, or vice versa
(allow access when the identity of the peer is not verified).

Furthermore, even if the authenticator decides to allow access,
the peer may consider the exchange a failure if it has not
successfully verified that it is talking to the intended
authenticator."

Do you think this captures the meaning accurately?
(It might require some small changes somewhere else
in the document, I can try to find them...)

---

From: [email-masked] ([email-masked])
Date: Fri, 9 May 2003 17:54:59 +0300

Hi,

The current thinking in state machine is that=20

- The peer never sends any EAP Responses after "enabling" the
  link (or equivalently, the peer "enables" the link only after=20
  the state machine has ended).
- If the authenticator times out (after retransmissions),=20
  it does not allow access (even when it in principle would
  be satisfied with the peer).=20

These two limit the choices an EAP method on the peer has
(especially the latter). Thus, when an EAP method has concluded:

- If the peer doesn't want to talk to this authenticator, it
  disables the link and ends the conversation. It doesn't matter
  what the authenticator's decision is. (The current state
  machine (-02) does wait for success, failure, or timeout to
  occur, but at the end, the link is always disabled. I guess
  this should be changed to just disable the link immediately.)

- If the peer would be willing to talk to this authenticator,
  but the authenticator has signalled that it won't allow access
  (using some method-specific message), the peer disables the
  link and ends the conversation (it doesn't wait for
  EAP Failure packet or anything).
 =20
- If the peer is willing to talk to this authenticator, and
  the authenticator has signalled it will allow access (using
  some method-specific message), the peer doesn't enable the
  link immediately.
=20
  This is because it might have to retransmit the last response
  message. Instead, it waits until it receives a Success packet,
  timeout, or "lower-layer success indication", and then enables
  the link. (If it gets a Failure, it is silently discarded and
  the peer continues waiting.)

- If the peer is willing to talk to this authenticator, but is
  unsure about if the authenticator will allow access (note:
  "allow access", not "has authenticated the peer"), it doesn't
  enable the link but waits. (Again, this is necessary
  for retransmissions.)

  If it receives a Success packet, timeout, or "lower-layer
  success indication", it enables the link. If it gets a
  Failure, it disables the link.

Thus, answering your questions (combined from both recently
sent messages):

> Do you agree that if the peer cannot successfully authenticate
> the peer, then it should disable the link so the
> Success/Failure message is irrelevant to it and it need=20
> not wait to receive it?

I assume that "cannot successfully authenticate" means "I don't
want to talk to the authenticator, even though I might, or might
not, have verified who it is"). Yes, I agree; in this case, the
authenticator's decision does not matter, and the peer can
disable the link immediately.=20

> So I'm asking what happens in each case, and what the decision is
> based on:
>
> a. One-way method. Peer fails to authenticate to the
> authenticator and the authenticator sends an EAP failure. Does
> the Peer process the EAP Failure and disable its side of the
> link? Why or why not?

Yes, the peer disables the link and ends the EAP conversation.

The assumption is that when EAP is used without mutual
authentication, we assume the link is secure anyway=20
(and if it isn't, a DoS attack is the least of our concerns).=20
Besides, it's more user-friendly to inform the user immediately=20
instead of waiting for long timeout.

> b. Mutually authenticating method. Peer successfully
> authenticates the authenticator. Does the peer accept a
> subsequent EAP Failure? Why or why not?

The EAP Failure is accepted (and link disabled) UNLESS the
method in question has an internal "access allowed" message=20
(not the same as internal "I've authenticated you" message),=20
and we have received such a message.

I don't think any other behavior would increase resistance to
DoS attacks in any significant amount, and the user-friendliness
aspect is outweighs that. If DoS attacks would be a concern, we
should use a method that has internal "access allowed" message
(such as PEAP).

> c. Mutually authenticating method. Peer unsuccessfully
> authenticates the authenticator. Does it accept a subsequent
> EAP Success? Why or why not?

I assume "unsuccessfully" means "we have decided that we don't
want to talk to this authenticator". Obviously, then we don't
talk to it.

Do you think the reasoning above would cover all cases,
and is ok?=20

Best regards,
Pasi=20