Subject: [eap] More on Issue 74

From: [email-masked] (Bernard Aboba)
Date: Sun, 9 Feb 2003 15:30:48 -0800 (PST)

The proposed text on Issue 74 (see previous message) also implies a change
to RFC 2869bis to handle the case of a MIC failure detected by the
authentication server.

With the proposed text, a Response spoofed by an attacker would be sent to
the AAA server, and would fail the MIC check. While the authentication
server would silently discard the Response, unless it responded to the NAS
in some way, the NAS would retransmit the invalid Response until it timed
out. This is undesirable -- so the AAA server needs to send an
Access-Challenge saying "this one was bad, send another if you have it." I
would propose this be done by sending an EAP-Message attribute with
nothing in it (EAP-Start) within the Access-Challenge.

The NAS then sends additional Responses with an Identifier value matching
the outstanding Request, if any exist. This would presumably include the
authentic EAP Response sent by the peer, which would pass the MIC check.
The conversation would then continue.

Given all of this, I think that James' original suggested text with
respect to MIC processing stands as written.

Assuming that the WG agrees, I will make the change to RFC 2869bis as part
of dealing with IETF last call comments. IETF last call on RFC 2869bis
will last longer than usual (4 weeks) in order to provide the community
with adequate opportunity to read it and comment.