Subject: [eap] Yet another (less feable?) proposal to resolve Issue 49

From: [email-masked] (Bernard Aboba)
Date: Wed, 15 Jan 2003 08:06:35 -0800 (PST)

During the EAP Design Team discussion today, we concluded that whether the
lower layer provides protection or not was irrelevant to the processing of
EAP Success and Failure messages. Given this, we have rewritten the
potential text for Section 4.2.1 as follows:

4.2.1. Processing of success and failure

Within EAP, success and failure indications consist of the EAP Success
and Failure messages, as well as method-specific indications.
Within EAP, these indications may be protected or unprotected.

EAP Success and Failure packets are considered unprotected
indications which may be spoofed, since as described in Section 4.2,
they contain no message integrity check.

In order to provide additional protection against tampering, EAP methods
MAY support a MIC that covers some or all of the EAP packet,
including headers. It is also possible for a MIC defined within an EAP
method to in addition include coverage of previous Request and Response
messages.

EAP methods also MAY include support for method-specific
acknowledged success and failure indications. This
enables the authenticator to indicate whether the peer has successfully
authenticated, as well as for the peer to acknowledge receipt of that
indication, and respond with an indication of whether the authenticator
has successfully authenticated to the peer. If a key has previously been
derived, the result exchange MAY be protected by a Message Integrity
Check (MIC), and if so, then this success/failure indication is consid-
ered protected.

In order to protect against spoofing of success and failure indications,
EAP implementations SHOULD obey the following processing rules:

[a] Processing of protected success and failure indications. Where a
success/failure indication has been received that is protected within
EAP, the implementation MUST validate the EAP method MIC,
with a MIC failure handled via silent discard, as specified in Sec-
tion 4.1.

[b] Receipt of EAP Success and Failure packets prior to method completion.
A peer EAP implementation receiving an EAP Success packet
prior to completion of the method in progress MUST silently discard
it. 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.
A peer EAP implementation receiving an EAP Failure
packet prior to completion of the method in progress MAY silently
discard it.

[c] Authentication requirement. An EAP peer implementation that has
been configured to require authentication MUST silently discard a
"canned" EAP Success message (an EAP Success message sent immediately
upon connection).

[d] Contradictory indications. Where protected and unprotected result
indications are both available, protected indications take precedence.
For example, where an EAP method provides a protected indication that
authentication failure has occurred in either direction, the
implementation MUST silently discard subsequent EAP Success packets. Similarly,
where an EAP method provides a protected indication that authentication
has succeeded in both directions, the EAP implementation MAY silently
discard EAP Failure packets.

[e] Processing of EAP Success and Failure in the absence of protected
indications. Subsequent to the completion of the EAP authentication
method (Types 4 and greater), and in the absence of protected
result indications, EAP Success and Failure packets
MUST be accepted and processed by the EAP implementation.

---

From: [email-masked] (Nick Petroni)
Date: Wed, 15 Jan 2003 13:32:03 -0500 (EST)

> packet prior to completion of the method in progress MAY silently
The concept of protected success and failure has been discussed for some
time, but in light of recent discussions distinguishing between "Method
Failure" and "Authenticator Failure" I would like to inquire as to the
implications on protected success and failure. Because such messages would
invariably be sent as Method messages, is it possible for the method to
claim it actually speaks for the overall conversation? We have previously
established that a method could succeed, but authentication fail overall.
Ideally, one would not utilize a method with protected success in a
manner that would allow this, but I am unsure how this fits into the
current framework. Yoshihiro's comments on the previous state machine
draft were insightful in showing that a method failure should not
necessarily indicate auth failure, but protected success seems to imply
that we actually do trust some methods to make this decision. Given that
discarding failure messages is a MAY, this might not be an issue. Still, I
am having trouble viewing this in terms of the state machine.

A related question, for my own information, is what should be represented
in the state machine- only MUST and  SHOULD behavior, or MAY as well.

---

From: [email-masked] (Bernard Aboba)
Date: Wed, 15 Jan 2003 09:43:14 -0800 (PST)

> claim it actually speaks for the overall conversation?

I don't think it can -- but perhaps there are some constraints that can be
placed on the overall conversation as a result.

> We have previously

Yes.

> current framework.

I think it is possible to utilize it that way. For example, say I invent a
method that has protected Success/Failure, and the authentication succeeds
in both directions, but there is a constraint that the user can only have
one simultaneous login. Once the authentication succeeds the AAA server
does a database lookup, finds several simultaneous conversations and
decides to deny access. So it *could* send an EAP Failure after a
successful authentication.

> Yoshihiro's comments on the previous state machine
> that we actually do trust some methods to make this decision.

This one is more controversial -- because I'd claim that if the
authenticator doesn't authenticate to the peer then accepting an
unprotected success indication is dangerous -- it opens the peer up to
connecting to a rogue authenticator.

Maybe this is only at the level of a SHOULD though -- there might be
circumstances where alternative behavior might be allowed, but you'd have
to think it through carefully (physically secure media?).

> Given that
> discarding failure messages is a MAY, this might not be an issue.

It was left as a MAY for implementations that want a high level of
security, and have circumstances that permit this. But it can have side
effects (lots of timeouts) so making it the default behavior may not be
wise. Of course this enables some DoS attacks.

> in the state machine- only MUST and  SHOULD behavior, or MAY as well.

I'd suggest that we try to illustrate as much behavior as possible,
perhaps by including variables that define what behaviors will be
exhibited.

---

From: [email-masked] (Nick Petroni)
Date: Wed, 15 Jan 2003 14:35:40 -0500 (EST)

> placed on the overall conversation as a result.
I agree.

> successful authentication.
I agree here as well.

> connecting to a rogue authenticator.
The question in my mind comes down to basically what value protected
failures have. Yes, it's true that if you know you failed the conversation
you don't want to accept a success, but that is true even if you never
received a "protected" failure. The fact that you have yet to
mutually authenticate is the real reason not to accept
success. Furthermore, even with a protected
failure, you might want to continue with another method anyway.

Similarly, protected success doesn't do much more than say the the current
method has finished successfully. It doesn't mean you should necessarily
neglect an unprotected failure that follows (as stated above), right?

I am understanding the protected success/failure methods to only indicate
success or failure of the method, in which case I am unclear how the EAP
conversation is really affected by them.

> perhaps by including variables that define what behaviors will be
Ok.

---

From: [email-masked] (Bernard Aboba)
Date: Wed, 15 Jan 2003 12:36:42 -0800 (PST)

> failures have.

That's my question, too.

> Yes, it's true that if you know you failed the conversation
> received a "protected" failure.

The question is where the failure occurred. If the peer knows that the
authenticator failed to authenticate to it, then presumably that will
cause it to not accept a "Success" -- but accepting a Failure is fine.

On the other hand, if the authenticator has told the peer "you succeeded
in authenticating to me", then it is possible that a Failure could be sent
afterward. It's also possible that such a Failure might be inauthentic,
and will soon be followed by the "real" Success indication. Which one does
the peer believe?

> The fact that you have yet to
> success.

Yes. I'd also claim Success should not be accepted if the authenticator
tells you in a protected way that you've failed to authenticate to it.

> Furthermore, even with a protected

If the authenticator tells the peer that "you've failed to authenticate
successfully" it is possible that a retry will occur, yes. The peer only
gets to decide whether it will send a Respond to the Request or a Nak.

> Similarly, protected success doesn't do much more than say that the

I think this is a bit like the handling of ICMP messages in IPsec. A host
MAY act on those (unprotected) messages, but it also may choose to ignore
them and wait for a timeout. Most implementations wait for the timeout --
but this is a source of continuing aggravation when the Responder doesn't
support IKE.

> conversation is really affected by them.

That's what we're trying to figure out :)

---

From: [email-masked] (Yoshihiro Ohba)
Date: Wed, 15 Jan 2003 17:46:16 -0500

> successful authentication.

This implies that EAP Success/Failure message is used as an indication
of an authorization result as well as an authentication result.  A
valid MIC for EAP Failure indicates "you are successfully
authenticated" and the EAP code (i.e., Failure) indicates "but sorry,
you are not authorized for some reason".  The same interpretation
might be possible for method-specific success/failure indication.

On the other hand, it might be also possible to define success/failure
indication differently, i.e., it indicates an authentication result
only, not an authorization result.  If we take this definition, the
authenticator should not return an EAP Failure message when the peer
is successfully authenticated.

Yoshihiro Ohba