Subject: [eap] Re: [issue 18] Identifier behavior details

From: [email-masked] (Bernard Aboba)
Date: Thu, 4 Apr 2002 23:33:29 -0800 (PST)

RFC 2284 only appears to require that the Identifier change on a new
Request, and stay the same on a retransmitted Request as well as in the
Response to that Request. 

It doesn't say anything about the Identifier being unique for every new
Request within an EAP conversation. And it doesn't say anything about what
an Authenticator does on receiving a Response not corresponding to a
Request or what a Peer does on receiving multiple Requests with different
Identifiers. 

Here are my thoughts:

a. The Identifier field is only a single octet. This makes it really easy
to guess, even if the implementation doesn't increment the Identifier with
each new Request, which most implementations seem to do. 

Since the Identifier is so easy to guess, it is easy for an attacker to
insert packets that can disrupt the EAP Peer state machine. Say I don't
want the Peer to see packet with Identifier #4. The attacker can just send
a packet with this Identifier before the real one arrives. If duplicate
Requests are automatically discarded by the Peer, then the real packet
will never be processed. 

So I think the right answer is for the Peer to Respond to the Request,
provided that it makes sense, but not to do its own duplicate elimination
before validating the packet. 

Similarly, on the Authenticator side, if duplicates are eliminated prior
to checking packet validity, then an attacker only needs to guess the
Identifier (easy to do since it is the same as the Request), insert a
Response and the real Response will never be processed, so that the
conversation aborts. 

Some questions:

a. Does it help if the Identifier is randomly chosen and then can wrap? I
think not, since the space is so small that it really doesn't make much
difference. 

b. Should we formally require that the Identifier be incremented with each
new request? This removes some flexibility, but still probably enables
everything that could be done otherwise.

---

From: [email-masked] (Bryan D. Payne)
Date: Fri, 5 Apr 2002 07:55:50 -0500 (EST)

> Response and the real Response will never be processed, so that the

How can the peer or authenticator ever truely validate a packet?  Since we
have no cryptographic protection of packets, one can easily spoof packets
without detection, right?

-bryan

---

From: [email-masked] (Bernard Aboba)
Date: Fri, 5 Apr 2002 06:49:57 -0800 (PST)

> without detection, right?

Some methods *do* have cryptographic protection (PEAP, TTLS). So the
question is whether they get to validate the packet, or whether duplicate
elimination throws it away before they get the chance. The latter approach
seems dangerous because then an invalid packet could cause a valid one to
be thrown away.