Subject: [eap] Re: Proposed Resolution of Issue 74

From: [email-masked] (Bernard Aboba)
Date: Fri, 7 Feb 2003 06:59:42 -0800 (PST)

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

I guess I don't understand how this is supposed to work. If the
authenticator doesn't turn off duplicate Response detection, then what
good is it for the AAA server to indicate that the Request was invalid?
The NAS will have already thrown away the other Requests in the queue, so
it won't be able to do anything about it.

> > 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').
> >
> > 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."
> >
>
> Yoshihiro Ohba
>
>
> --__--__--
>
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
>
>
> End of eap Digest
>

---

From: [email-masked] (Yoshihiro Ohba)
Date: Fri, 7 Feb 2003 11:43:37 -0500

> it won't be able to do anything about it.

Regarding the words "outstanding Request", I assume that the
authenticator keeps a copy of the Request.  The Request is
"outstanding" and retransmission and duplicate detection could be
performed in parallel to validity check until a Response turns out to
be valid.

The same thing would apply to the case the delegated entitity is
physically co-located on the same device as the authenticator (e.g.,
an "EAP server" process or thread separated from "EAP authenticator"
process or thread, both are running on the same OS of the device.)
So I think this issue is not specific to the pass-through authenticator.

Yoshihiro Ohba