Subject: [eap] Another stab at resolving Issue 121

From: [email-masked] (Bernard Aboba)
Date: Tue, 10 Jun 2003 22:23:07 -0700 (PDT)

Here's another try at resolving Issue 121. Comments welcome.

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 as
described in this note. See also Section 3.4 for guidance on the
processing of lower layer success and failure indications.

As described in Section 2.1, only a single EAP authentication method
is allowed within an EAP conversation. EAP methods MAY
implement acknowledged result indications.
After the authenticator sends a method-specific failure indication
to the peer, regardless of the response from the peer, it MUST
subsequently send a Failure packet. After the authenticator
sends a method-specific success indication to the peer, and
receives a method-specific success indication from the peer,
it MUST subsequently send a Success packet.

On the peer, once the method completes unsuccessfully (that is, either
the authenticator sends a method-specific failure indication, or the
peer decides that it does want to continue the conversation), the
peer MUST terminate the conversation and avoid sending data on the
link. The peer MUST silently discard Success packets and MAY
silently discard Failure packets. As a result,
loss of a Failure packet need not result in a timeout.

On the peer, after successful acknowledged result indications
are exchanged by both sides, a Failure packet MUST be silently
discarded by the peer. The peer MAY, in the event that an EAP Success is
not
received, conclude that the EAP Success packet was lost and
that authentication concluded successfully.

A mutually authenticating method (such as EAP-TLS [RFC2716])
that provides authorization error messages provides
acknowledged result indications for the purpose
of this specification. Within EAP-TLS, the peer always
authenticates the authenticator, and may send a TLS-alert message
in the event of an authentication failure. The authenticator,
which authenticates the peer, may use the "access denied"
TLS aert to indicate that a valid
certificate was received from the peer, but when
access control was applied, the authenticator decided not to proceed.
If a method provides authorization error messages, the authenticator
SHOULD use them so as to ensure consistency with the final access
decision and avoid lengthy timeouts.

If the authenticator has not sent a method-specific result
indication, and the peer is willing to continue the conversation,
once the method completes the peer waits for a Success or Failure
packet and MUST NOT silently discard either of them. In the event that
neither a Success nor Failure packet is received, the peer SHOULD
terminate the conversation to avoid lengthy timeouts in case the
lost packet was an EAP Failure.

If the peer attempts to authenticate to the authenticator and fails
to do so, the authenticator MUST send a Failure packet and MUST NOT
grant access by sending a Success packet. However, an authenticator
MAY NOT require that the peer authenticate to it in situations where
limited access is offered (e.g. guest access). In this case the
authenticator MAY send a Success packet.

Where the peer authenticates successfully to the authenticator, but
the authenticator does not send a successful result indication
(such as in a method in which the authenticator authenticates the peer
but the peer does not authenticate the authenticator), the authenticator
MAY deny access by sending a Failure packet where the peer is not
currently authorized for network access."

---

From: [email-masked] (Joseph Salowey)
Date: Tue, 10 Jun 2003 23:12:19 -0700

Looks better comments inline:

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Bernard Aboba
> Sent: Tuesday, June 10, 2003 10:23 PM
> To: [email-masked]
> Subject: [eap] Another stab at resolving Issue 121
> 
> 
> "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 
> 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 
> enable the link."
> "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 
> 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 as described in this note. See also 
> Section 3.4 for guidance on the processing of lower layer 
> success and failure indications.
> 
> As described in Section 2.1, only a single EAP authentication 
> method is allowed within an EAP conversation. EAP methods MAY 
> implement acknowledged result indications. After the 
> authenticator sends a method-specific failure indication to 
> the peer, regardless of the response from the peer, it MUST 
> On the peer, once the method completes unsuccessfully (that 
> is, either the authenticator sends a method-specific failure 
> indication, or the peer decides that it does want to continue 
> the conversation), the peer MUST terminate the conversation 
> and avoid sending data on the link. The peer MUST silently 
> discard Success packets and MAY silently discard Failure 
> packets. As a result, loss of a Failure packet need not 
> result in a timeout.
> 
> are exchanged by both sides, a Failure packet MUST be 
> silently discarded by the peer. The peer MAY, in the event 
> that an EAP Success is not received, conclude that the EAP 
> Success packet was lost and that authentication concluded 
> successfully.
> 
> acknowledged result indications for the purpose of this 
> specification. Within EAP-TLS, the peer always authenticates 
> the authenticator, and may send a TLS-alert message in the 
> event of an authentication failure. The authenticator, which 
> authenticates the peer, may use the "access denied" TLS aert 
> to indicate that a valid certificate was received from the 
> peer, but when access control was applied, the authenticator 
> decided not to proceed. If a method provides authorization 
> error messages, the authenticator SHOULD use them so as to 
> ensure consistency with the final access decision and avoid 
> lengthy timeouts.
> 
> indication, and the peer is willing to continue the 
> conversation, once the method completes the peer waits for a 
> Success or Failure packet and MUST NOT silently discard 
> either of them. In the event that neither a Success nor 
> Failure packet is received, the peer SHOULD terminate the 
> conversation to avoid lengthy timeouts in case the lost 
> packet was an EAP Failure.
> 
> If the peer attempts to authenticate to the authenticator and 
> fails to do so, the authenticator MUST send a Failure packet 
> and MUST NOT grant access by sending a Success packet. 
> However, an authenticator MAY NOT require that the peer 
> authenticate to it in situations where limited access is 
> offered (e.g. guest access). In this case the authenticator 
> MAY send a Success packet.
> 

[Joe] If the authenticator wants to change the access granted to the
peer it MUST send an EAP-Success. 

> Where the peer authenticates successfully to the 
> authenticator, but the authenticator does not send a 
> successful result indication (such as in a method in which 
> the authenticator authenticates the peer but the peer does 
> not authenticate the authenticator), the authenticator MAY 
> deny access by sending a Failure packet where the peer is not 
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
>

---

From: [email-masked] (Yoshihiro Ohba)
Date: Tue, 10 Jun 2003 07:32:58 -0700

In the penultimate paragraph of the new text, the key word "MAY NOT" 
is used but that particular key word is actually not defined in RFC 2119.
I think "MAY not" is more appropriate than "MAY NOT".

Yoshihiro Ohba

---

From: [email-masked] (Alper Yegin)
Date: Wed, 11 Jun 2003 21:53:16 -0700

> link. 

Do we really have to say "peer MUST avoid sending data on the link"?
We can note that EAP failure signals failed attempt to authorize, but I
don't think we need to limit the actions of peer to simple going away.
Also, "disabling link" concept applies to using EAP over link-layers, but
not necessarily to PANA and IKEv2, unless we re-define the term "link" in
here.

> The peer MUST silently discard Success packets and MAY

> authenticator MAY send a Success packet.

I'm not sure when this Success packet is sent. If authentication is not
required, what is the sequence of events that leads to transmission of this
message? Maybe you don't strictly mean EAP-Success here.

Alper

---

From: [email-masked] (Bernard Aboba)
Date: Wed, 11 Jun 2003 23:04:20 -0700 (PDT)

> Do we really have to say "peer MUST avoid sending data on the link"?

If we don't do this, then the peer could be sending data to a rogue
Authenticator. This was one of the weaknesses found in the University of
Maryland state machine analysis.

> message?

The peer could authenticate the authenticator, but the authenticator might
not need to authenticate the peer. As an example, EAP-TLS could be run
without having the authenticator request the client certificate. The
authenticator could then send a Success packet.

---

From: [email-masked] (Jari Arkko)
Date: Thu, 12 Jun 2003 15:50:25 +0300

> Maryland state machine analysis.

Yes.

I agree with Alper that "link" may not be the right terminology
in the case of PANA or IKEv2. But it may be easier to deal with
that by having those protocols define what they mean as the "link".
For instance, IKEv2 could say that in these situations one should
not create any IPsec SAs.

Anyway, I like Bernard's text. I have edited the second to
last paragraph slightly, however, in order to take in account
the following:

- Yoshi's MAY NOT problem
- Joe's reformulation (further edited, hope its ok for Joe)

Here's the suggested new text:

If the peer attempts to authenticate to the authenticator and
fails to do so, the authenticator MUST send a Failure packet
and MUST NOT grant access by sending a Success packet.
However, an authenticator MAY not require that the peer
authenticate to it in situations where limited access is
offered (e.g. guest access). If this is the case, the
authenticator MUST send a Success packet.

--Jari

---

From: [email-masked] (Bernard Aboba)
Date: Thu, 12 Jun 2003 06:07:17 -0700 (PDT)

> authenticator MUST send a Success packet.

I've updated the Issue 121 text to include this.