Subject: [eap] Issue 68: MIC coverage

From: [email-masked] (Bernard Aboba)
Date: Sat, 11 Jan 2003 15:57:07 -0800 (PST)

Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: January 11, 2003
Document: RFC 2284bis-08
Comment type: T
Priority: S
Section: 2.1, 3.1
Rationale/Explanation of issue:

In order to provide integrity protection and authentication for the EAP
conversation, it may be desirable for an EAP method to be able to
calculate a MIC on the EAP headers as well as the Type-Data field, and
perhaps even previous EAP messages.

For example, in a conversation including an Identity Request/Response,
a Request for EAP Type X, a Nak Response offering alternative Y, and
then EAP Request/Response messages of Type Y, it may be desirable for
method Y to be able to calculate a MIC of all previous EAP messages,
including headers.

Is this prohibited by the multiplexing model? For example, can EAP
methods be assumed to have access to the EAP headers? Does the
multiplexing model imply that EAP messages of types Nak, Notification
Success and Failure are never accessible to the EAP method? What
about EAP Identity-Request?

---

From: [email-masked] (Jari Arkko)
Date: Sun, 12 Jan 2003 10:00:41 +0200

> about EAP Identity-Request?

There clearly has to be _some_ amount of information available to
the methods from past messages. The identity of the user, for instance.
Or if we at some point start to cryptographically bind sequences of
methods together, then the keys must be available.

One answer to your question is that this is to a large extent
an issue for the EAP method spec, and also an implementation
issue: if your product needs to implement method M which requires
past messages, then your EAP mux implementation better be capable
of providing this information.

I think it should be sufficient for 2284bis to define what
information MUST be available (identity response values?) to
the method, and state that methods MAY require more.

Then I have a question about your integrity protection scheme
above. Exactly how did you plan on using it? The state machine
still progresses one step at a time, and at the end we will
check if someone modified the sequence? If yes, do you have
a more exact definition of what the additional security provided
by this would be? It seems to me that the identity responses,
for instance, are in a way already included in the MACs... you
could substitute some other identity which happens to have the
same password, however. Apparently you could protect notifications
this way, but they never affect the end-result anyways. Success
and failure? But don't they always come _after_ methods?

If you are not expecting the state machine to just verify
things at the end, are you thinking of building some tree
of alternative message sequences and accepting the one that
leads to a successful MAC at the end?

Jari

---

From: [email-masked] (Bernard Aboba)
Date: Sat, 11 Jan 2003 23:19:54 -0800 (PST)

> the method, and state that methods MAY require more.

Yes, I think this makes sense. That would require rewording the EAP
multiplexing section in terms of MUSTs and MAYs.

The question in my mind is whether an EAP method can require a capability
that is only a MAY. That would mean that it wouldn't be feasible to run it
on every Peer and Authenticator implementation. That seems wrong somehow.

> above. Exactly how did you plan on using it?

Protocols such as TLS [RFC2246] include a Finished message that serves to
MIC the entire conversation. The reason for this is that early messages
typically can't be MIC'd, because there's no key yet. That means that the
Identity exchange, Nak, Notification, and perhaps the first one or two
method exchanges are not tamperproof.

So the purpose of this would be to be able to detect tampering in earlier
messages, once the method has been able to derive a MIC key. The question
is what earlier messages could be included. The way the section reads now,
only the Identity Response is guaranteed to be available -- not the
Identity Request, Nak Response (if sent), Notification Request or
Notification Response. And it is not entirely clear that the EAP method
can have access to the EAP headers over which to calculate a MIC -- though
we might clarify this.

The Identity Request is only a hint, and Notification Request/Response
doesn't change state, so perhaps it can be argued that we don't need
these to be part of a complete MIC. As you said, Success/Failure comes
after the method, and in any case we can have method-specific protected
result indications.

So the main thing I'm worried about is a "bidding down" attack --
discovering that the attacker inserted a Nak that the client didn't send,
in order to get a less strong method to run. Also perhaps a change of the
Identity, so as to cause the authentication to be routed to the wrong
server -- I typed [email-masked] and instead [email-masked] was
sent.

> If yes, do you have
> by this would be?

MICs which only cover the Type-data field leave the EAP headers exposed.
There are not many vulnerabilities to exploit in modifying the EAP
headers, but there are some. Changes in Code and Identifier will generally
result in silent discard, but you can change the Length field in
case an implementation isn't checking for buffer overuns, and modify
the Type field. Since some EAP methods are similar, changes in the Type
field may not be detectable, for example. So you could, for example,
convert a PEAP or EAP TTLS packet to an EAP TLS packet without anyone
noticing (at least at first).

Also there is the bidding down attack I mentioned earlier, and perhaps
Identifier space insertion attacks (I'm assuming that most of these will
also result in silent discard), and Type insertion attacks (which will
also result in silent discard except if they are timed exactly right).

> leads to a successful MAC at the end?

No, just aborting if the "finished" MICs don't match.

---

From: [email-masked] (Jari Arkko)
Date: Sun, 12 Jan 2003 10:41:04 +0200

> on every Peer and Authenticator implementation. That seems wrong somehow.

Ok. I don't think adding a requirement to have past message history
available is too much of a burden. We could make it a MUST too.

> server -- I typed [email-masked] and instead [email-masked] was

Interesting. Yes, bidding down is an issue. I didn't realize we could
solve it this way. I'm convinced now that we should provide the information
to methods.

[Hmm... this way of protecting against bidding down attacks can only
succeed if neither party allows any of the current methods as the sole
authentication method. As far as I know, all the currently defined EAP
methods lack this capabality. Somewhere down the road we are going to
need new methods.]

> No, just aborting if the "finished" MICs don't match.

Ok.

Jari

---

From: [email-masked] (Bernard Aboba)
Date: Sun, 12 Jan 2003 06:59:30 -0800 (PST)

> available is too much of a burden. We could make it a MUST too.

I don't think it is -- but I hope that capability doesn't wreak
havoc with the multiplexing model. Even though one might have the past
message history available doesn't mean that methods can assume that
messages such as Notification carry data for them.

> solve it this way. I'm convinced now that we should provide the information

Do we assume that a method could have available *all* past traffic
(inbound, outbound), including EAP headers? Or do we just add Headers,
and the Nak Response (if sent) to Identity Response in the list of things that MUST be
available to methods on both peer and authenticator? Doing that would
wreak less havoc with the multiplexing model, while still allowing
computation of a "finished" MIC.

Maybe we should ask for an opinion from our security advisor?

> methods lack this capabality. Somewhere down the road we are going to

Outside of RFC 2284, there is only one EAP method defined in an RFC (RFC
2716).