Subject: [eap] Survey: handling of retransmissions

From: [email-masked] ([email-masked])
Date: Fri, 20 Dec 2002 13:57:53 +0200

Hello,

EAP SIM and EAP AKA are examples of methods that can silently=20
discard EAP packets based on an incorrect ICV.=20

It is also conceivable that an EAP method could delay the
processing of some unprotected packet, say a method-specific
notification. If another packet with a correct ICV is received
during the delay, then the unprotected packet may be silently
discarded. If no other packets are received, the method may
decide to process the unprotected packet. This could also
happen in EAP SIM, where ICV can only be included once=20
keys have been derived, so in the very first packets there
is no ICV.

If we further consider EAP SIM as an example, the fact
that the very first packets are not MAC'd makes it easy
to spoof packets. Of course spoofing will later be detected,
but if only the first received packet is processed, then it is
quite easy to mount a DoS attack. So it makes me wonder if
some method implementations could process several copies of the=20
"same" packet and kind of "fork" separate states for each=20
processed packet. The spoofed states should later be detected
and removed, but if the valid packets were processed separately,=20
the authentication could still succeed.

Based on these examples, I'm inclined to think that the
EAP layer should simply pass all EAP packets of a certain
type to the appropriate method, and let the method
decide how to process the packets. The EAP layer should
not act as a "flip-flop" by keeping track of requests
and corresponding responses or by flushing the packet queue.
This would make the software interface between EAP layer
and methods simple while allowing sophisticated processing
of EAP packets.

I don't know about any implementations that would work like=20
this, so I didn't answer the survey below.

Regards,
Henry

> -----Original Message-----
> From: ext Bernard Aboba [mailto:[email-masked]]
> Sent: 18 December, 2002 20:03
> To: [email-masked]
> Subject: [eap] Survey: handling of retransmissions
>=20
>=20
> A question has arisen as to how retransmissions are handled in current
> implementations, as well as integrity check failures (within=20
> a method).
>=20
> a. What does your Peer implementation doif it receives=20
> multiple packets
> with the same Identifier before it has sent a Response?
>   1. Does it check whether the packets are "the same"?
>   2. Does it process the first packet, generate a Response, and clear
>      the queue?
>   3. Does it process all the enqueued packets?
>   4. Does it drop all incoming packets other than the first one?
>=20
> b. What if there are multiple incoming packets with different=20
> Identifier
> values?
>=20
> c. What if, after sending an EAP packet up to the method, that packet
> fails a method-specific integrity check? If the method can handle it,
> can it silently discard the packet and ask for the next one in the
> queue?
>=20
> d. What about on the Authenticator side?
>   1. Does the authenticator enqueue Responses, or is only one Response
>      allowed?
>   2. Is the incoming queue cleared after another Request is sent?
>   3. Are Responses that don't match the outstanding Request ID
>      automatically discarded?
>=20
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
>=20