Subject: [eap] Issue 74: Concern on invalid MIC

From: [email-masked] (Bernard Aboba)
Date: Tue, 4 Feb 2003 16:34:08 -0800 (PST)

I agree with James that it is best if the MIC applies to individual
datagrams, but there are situations in which this is not possible. For
example, unlike GSS-API, in EAP a key is not assumed available until it is
derived later in the conversation. This means that the Identity and Nak
messages cannot be authenticated when they are sent -- because the
method hasn't run yet, there is no key with which to authenticate
them.

However, as we've discussed, it is possible to authenticate the
uncovered part of the conversation by including those packets in a MIC
sent later on, after keys have been derived.

How about this suggested text?

"  If a per-packet Message Integrity Check (MIC) is employed within an EAP
   method, then implementations MUST silently discard any message that
   fails this check.  In this document, the descriptions of EAP message
   handling assume that per-packet MIC validation is effectively performed
   as though it occurs before examining any of the EAP message fields
   (such as 'Code').

   Some EAP methods may define MICs that cover more than one EAP packet.
   Since the Identity Request/Response, Nak Response or Notification
   Request/Response messages are not authenticated, once an EAP method
   derives keys it may be desirable to exchange MICs that cover these
   unauthenticated packets, so as to be able to detect forgeries after
   the fact. Alternatively, an EAP method may define a MIC covering an
   extended PDU that could be split into multiple fragments.

   In these situations, failure of MIC validation is typically a fatal
   error, since it may not be possible to recover the original state and
   continue the exchange. It should be understood that this increases
   vulnerability to denial of service attacks."

-----------------------------------------------------------------------
Issue 74: Concern on invalid MIC
Submitter name: Yoshihiro Ohba
Submitter email address: [email-masked]
Date first submitted: Feburary 3, 2003
Document: RFC2284bis-10
Comment type: T
Priority: S
Section: 4.1
Rationale/Explanation of issue:
Section 4.1 says:
"   If a Message Integrity Check (MIC) is employed within an EAP method,
   then implementations MUST silently discard any message that fails
   this check.  In this document, the descriptions of EAP message
   handling assume that MIC validation is effectively performed as
   though it occurs before examining any of the EAP message fields (such
   as 'Code')."

I'm sorry for discussing this issue again, but I am still not sure
whether mandating silent discard of packets with invalid MIC is always
good.

For example, EAP-TLS and PEAP haves its own fragmentation mechanism
outside the TLS, in which each fragment is carried in a single EAP
Request/Response packet. In this case, since TLS MIC validation
cannot be performed before reassembling the fragmented packets, so an
attacker Authenticator can send a fragment with broken MIC. The
packet will be accepted by the Peer as long as it is valid except for
MIC, and EAP Requests sent by legitimate Authenticator after the
attacker's attempt may be treated just as a deplicate Request.
Finally, when all fragments are received by the Peer, the Peer
reassembles a TLS record and will find invalid in terms of MIC.

If this is a possible situation, how silently discarding the packet
with invalid MIC can improve robustness againt the DoS attack of
blindly injecting fragments?

Yoshihiro Ohba
Comment from James Carlson:
It sounds like breakage in the EAP-TLS and PEAP fragmentation
mechanisms, rather than a problem with EAP itself.

> If this is a possible situation, how silently discarding the packet
> with invalid MIC can improve robustness againt the DoS attack of
> blindly injecting fragments?

If you're not doing a MIC per message, then it's hard for me to see
what the value of the thing called a "MIC" might be.

---

From: [email-masked] (Yoshihiro Ohba)
Date: Wed, 5 Feb 2003 20:27:03 -0500

The suggested text works fine for me.

Thanks,
Yoshihiro Ohba

On Tue, Feb 04, 2003 at 04:34:08PM -0800, Bernard Aboba wrote:
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
>

---

From: [email-masked] (Bernard Aboba)
Date: Wed, 5 Feb 2003 21:41:52 -0800 (PST)

Actually, I think we need to say something about the issues you raised in
passthrough mode. How about this?

"If a per-packet Message Integrity Check (MIC) is employed within an EAP
method, then peers and authenticators not operating in pass-through
mode MUST silently discard any message that fails this check. Since
authenticators operating in pass-through mode do not check
method-specific MICs, this requirement does not apply to them.

In this document, the descriptions of EAP message handling assume that
per-packet MIC validation, where it occurs, is effectively performed
as though it occurs before examining any of the EAP message fields
(such as 'Code').

---

From: [email-masked] (Yoshihiro Ohba)
Date: Thu, 6 Feb 2003 11:28:11 -0500

> method-specific MICs, this requirement does not apply to them.

I think we can describe without necessarily using the term
"passthrough".  And I also come to think that it is not necessary to
turn-off or delay duplicate Response detection.  How about the following 
text?

   "The authenticator MUST NOT send a new Request until a valid Response
   is received to an outstanding Request.  Since the authenticator can
   retransmit before receiving a valid Response from the peer, the
   authenticator can receive duplicate Responses. The authenticator
   MUST silently discard these duplicate Responses.  Note that
   authenticators which delegate the task of method-specific
   validity check to other entities (e.g., EAP servers) are assumed to
   be able to obtain the validity check result from the delegated
   entities.

   If a per-packet Message Integrity Check (MIC) is employed within an EAP
   method, then peers and authenticators MUST silently discard any
   message that fails this check."

   (continued to the following text)

Yoshihiro Ohba