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

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

I believe that discussion on Issue 74 has exposed a mistake in the
handling of Responses in Section 4.1 Request and Response. With this
mistake corrected, I believe that the resolution of this issue becomes
more apparent. As a result, I would like to propose a rewrite of the
Description text as follows:

-----------------------------------
4.1 Request and Response

Description

The Request packet (Code field set to 1) is sent by the
authenticator to the peer. Each Request has a Type field which
serves to indicate what is being requested. Additional Request
packets MUST be sent until a valid Response packet is received,
or an optional retry counter expires. In [IEEE8021X], the retry
counter is effectively set to zero, so that retransmission never
occurs, and instead the peer times out and authentication is
restarted.

Retransmitted Requests MUST be sent with the same Identifier value in
order to distinguish them from new Requests. The contents of the data
field is dependent on the Request type.  The peer MUST send a
Response packet in reply to a valid Request packet. Responses MUST
only be sent in reply to a valid Request and never retransmitted on a
timer.

The Identifier field of the Response MUST match that of the
Request. An authenticator receiving a Response whose Identifier
value does not match that of the currently outstanding Request
MUST silently discard the Response. The Type field of a Response
MUST either match that of the Request, or correspond to a legacy
or expanded Nak (see Section 5.3). An EAP server receiving a Response
packet with an invalid Type field MUST silently discard
the Response.

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.

If a Message Integrity Check (MIC) is employed within an EAP method,
then peer and EAP server 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').

  Implementation Note: The authenticator is responsible for
  retransmitting Request messages.  If the Request message is
  obtained from elsewhere (such as from a backend authentication
  server), then the authenticator will need to save a copy of the
  Request in order to accomplish this. The authenticator is also
  responsible for discarding Response messages with a non-matching
  Identifier value before acting on them in any way, including
  passing them on to the backend authentication server for
  verification. However, if an authenticator receives multiple
  Responses, each with a matching Identifier, then it will pass
  each of them on to the backend authentication server.
  Similarly, the peer is responsible for detecting and
  handling duplicate Request messages before processing them in any
  way, including passing them on to an outside party.

  Because the authentication process will often involve user input,
  some care must be taken when deciding upon retransmission
  strategies and authentication timeouts.  By default, where EAP is
  run over an unreliable lower layer, the EAP retransmission timer
  SHOULD be computed as described in [RFC2988]. This
  includes use of Karn's algorithm to filter RTT estimates resulting
  from retransmissions.  A maximum of 3-5 retransmissions is
  suggested.

  When run over a reliable lower layer (e.g. EAP over ISAKMP/TCP, as
  within [PIC]), the authenticator retransmission timer SHOULD be set
  to an infinite value, so that retransmissions do not occur at the EAP
  layer. Note that in this case the peer may still maintain a
  timeout value so as to avoid waiting indefinitely for a Request.

  Where the authentication process requires user input, the measured
  round trip times are largely be determined by user responsiveness
  rather than network characteristics, so that RTO estimation is not
  helpful.  Instead, the retransmission timers SHOULD be set so as
  to provide sufficient time for the user to respond, with longer
  timeouts required in certain cases, such as where Token Cards are
  involved.

  In order to provide the EAP authenticator with guidance as to the
  appropriate timeout value, a hint can be communicated to the
  authenticator by the backend authentication server (such as via
  the RADIUS Session-Timeout attribute).

---

From: [email-masked] (John Vollbrecht)
Date: Tue, 11 Feb 2003 13:56:05 -0500

I think this looks very good.  I have a couple questions inline.

> Description text as follows:
presumably the peer only has to send one response if it gets a 
retransmitted  request before it responds to the original.

>   each of them on to the backend authentication server.

Does it HAVE to pass them all, or only till it gets a "new" request? 
Sending all might be pretty hard to do with RADIUS,

>   way, including passing them on to an outside party.
the peer checks for duplicates - but only those that arrive before it sends 
a response.

>   the RADIUS Session-Timeout attribute).
is this a standard use of Session-Timeout?  Is resending an EAP Request the 
same as restarting RADIUS?
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap

---

From: [email-masked] (Bernard Aboba)
Date: Tue, 11 Feb 2003 09:50:14 -0800 (PST)

> retransmitted  request before it responds to the original.

Yes, I think that's handled in language relating to the peer.

> Sending all might be pretty hard to do with RADIUS,

I think only until it gets a "new" Request. Is this stated clearly enough?

> the peer checks for duplicates - but only those that arrive before it sends

Yes. Does this section make that clear enough? If not, any ideas on how to
improve it?

> same as restarting RADIUS?

It's a use that was defined in RFC 2869. It's just an EAP retransmission
timeout, so it doesn't cause any RADIUS traffic until the Response
arrives.