Subject: [eap] Strawman rewrite of Section 4.1

From: [email-masked] (Bernard Aboba)
Date: Fri, 3 Jan 2003 10:50:35 -0800 (PST)

Based on the recent discussion on EAP transport behavior, I'd like to
propose the following text to replace the existing Section 4.1 Request and
Response. Comments welcome (please indicate substitute text if you don't
like something).

4.1.  Request and Response

Description

   The Request packet is sent by the authenticator to the peer.  Each
   Request has a type field which serves to indicate what is being
   requested.  The authenticator MUST transmit an EAP packet with the
   Code field set to 1 (Request). 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 Request packet. Responses MUST only be sent in reply to a received
   Request and never retransmitted on a timer.  The Identifier field of
   the Response MUST match that of the Request; if it does not match,
   then the Response MUST be silently discarded.  Authenticators
   receiving an EAP Response with a Type for which the authenticator has
   no outstanding Request 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. The authenticator MUST
   silently discard these duplicate Responses.

      Implementation Note: 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 (EAP_RTO) 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 EAP retransmission timer SHOULD be set to an
      infinite value, so that retransmissions do not occur at the EAP
      layer.

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

   A summary of the Request and Response packet format is shown below.
   The fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |  Identifier   |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |  Type-Data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Code

   1 for Request
   2 for Response

Identifier

   The Identifier field is one octet. The Identifier field MUST be the
   same if a Request packet is retransmitted due to a timeout while
   waiting for a Response. Any new (non-retransmission) Requests MUST
   modify the Identifier field. In order to avoid confusion between new
   Requests and retransmissions, the Identifier value chosen for each
   new Request MUST be unique within the EAP conversation. One way to
   achieve this is to start the Identifier at an initial value and
   increment it for each new Request. The Identifier field need only be
   unique on a per-port basis, so that authenticators are not restricted
   to only 255 simultaneous authentication conversations.

   If a peer receives a valid duplicate Request for which it has already
   sent a Response, it MUST resend its original Response. If a peer
   receives a duplicate Request before it has sent a Response to a valid
   initial Request (i.e. it's waiting for user input), it MUST silently
   discard the duplicate Request. An EAP message may be found invalid
   for a variety of reasons: failed link layer CRC or checksum,
   malformed EAP packet, EAP method-specific MIC, etc.

Length

   The Length field is two octets and indicates the length of the EAP
   packet including the Code, Identifier, Length, Type, and Type-Data
   fields.  Octets outside the range of the Length field should be
   treated as Data Link Layer padding and should be ignored on
   reception.

Type

   The Type field is one octet.  This field indicates the Type of
   Request or Response. A single Type MUST be specified for each EAP
   Request or Response.  Normally, the Type field of the Response will
   be the same as the Type of the Request.  However, there is also a Nak
   Response Type for indicating that a Request type is unacceptable to
   the peer. An initial specification of Types follows in a later
   section of this document.

Type-Data

   The Type-Data field varies with the Type of Request and the
   associated Response.

---

From: [email-masked] (James Carlson)
Date: Fri, 3 Jan 2003 15:18:35 -0500

Bernard Aboba writes:
>    Code field set to 1 (Request).

I'm not sure what the effect of the MUST is above.  There are no other
Request messages except those with Code field set to 1.  Should this
instead say that the authenticator MUST use Requests?  Even so, I
don't see that this is an actual requirement -- a hypothetical 'null
authentication' implementation could start the conversation by sending
a single Success message.  (Noting that Identity is optional, and that
no other messages are required.)

>    a Request packet.

This isn't quite true.  The peer may discard the Request.  What it
MUST NOT do is send a Response message on its own.  So, either reword
as:

	The peer MUST send a Response packet only as a reply to a
	received Request packet.

or just delete in favor of the next sentence:

> Responses MUST only be sent in reply to a received
>    Request and never retransmitted on a timer.

[...]
>    no outstanding Request MUST silently discard the Response.

Type can be Nak.

>    is received to an outstanding Request.

That's an interesting new requirement; it's not in RFC 2284.  Is this
requirement necessary?  What does an authenticatee do if it gets a
Request with a new Identifier number despite this restriction?

>       helpful.

How does the authenticator know when the authenticatee's processing
requires user input (and thus no RTO is done) and when it does not
(and RTO is done)?  Does this come from the authentication server as
well?

>    increment it for each new Request.

That doesn't make the Identifier unique unless you assume that 256 or
fewer EAP messages are ever sent on the link.  That's almost certainly
not the case if rechallenges are involved.

The requirement on Identifiers is really much less than that: the
Identifier number must not repeat within a full RTT on the link.
Since the protocol is simplex, this is trivial to accomplish in
practice.

For what it's worth, initializing the first Identifier to be sent with
a random number (rather than always using 0 and counting up) is a Good
Practice and might be noted.

> The Identifier field need only be

I do not quite understand that statement.  If they weren't specific to
the authentication session (I would use "session" rather than "port"),
then the limit would be far lower than 255 -- 128 would be the maximum
(ping-ponging between two Identifiers on each link).

-- 
James Carlson, Solaris Networking         <[email-masked]>
Sun Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677

---

From: [email-masked] (Bernard Aboba)
Date: Fri, 3 Jan 2003 15:10:32 -0800 (PST)

> Request with a new Identifier number despite this restriction?

Within EAP the Window size is only 1, so an authenticator can't send two
Requests with different IDs, can it? It might seem obvious, but the
question has come up.

The authenticatee can't know if the authenticator has received a Response,
but if it receives a packet with a new ID before sending a Response
to the initial one, doesn't it silently discard the one with the new ID?

> (and RTO is done)?  Does this come from the authentication server as

Yes. The authentication server sends a Session-Timeout attribute to
provide a hint. If no attribute is sent, the default behavior is used.

> not the case if rechallenges are involved.

Yes, requiring uniqueness probably makes DoS attacks easier. I think this
should say "need only be different from the previous request".

> Practice and might be noted.

Yes. Will add this.

> (ping-ponging between two Identifiers on each link).

This was added because some folks assumed that there could only be 256 EAP
conversations in progress, because the Identifier space is 8 bits. The
intent was to make clear that there is an independent Identifier space for
each session.

---

From: [email-masked] (James Carlson)
Date: Sun, 5 Jan 2003 11:10:12 -0500

> Requests with different IDs, can it? It might seem obvious, but the

Of course it can.  It just can't expect a Response to any of the prior
Requests it may have sent.  RFC 2284 does not have the restriction
this draft now imposes.  All it says is that *if* you send something
other than a retransmission, then you must change the Identifier
field:

      The Identifier field is one octet.  The Identifier field MUST be
      the same if a Request packet is retransmitted due to a timeout
      while waiting for a Response.  Any new (non-retransmission)
      Requests MUST modify the Identifier field.  If a peer recieves a

It doesn't say that you actually have to receive the Response.
Fortunately, there's no way that the RFC could require this.  There's
no way to tell precisely if the Response was actually received by the
authenticator -- it could still have been lost somewhere in the
receiver's internal software before being seen by EAP, and no part of
the subsequent Request has information from the prior Response from
EAP's point of view -- though perhaps not so from the details of a
particular method.

> to the initial one, doesn't it silently discard the one with the new ID?

I'd have to say "no."  Where is that restriction in RFC 2284?  Why is
that restriction needed at all?  I don't see the point.

> provide a hint. If no attribute is sent, the default behavior is used.

This is all implementation advice.  I think it should probably be made
a little less prominent.

I'm not even sure that it's the right advice.  I understand the RFC
2865 RADIUS Session-Timeout attribute differently -- it's the maximum
time-to-live for the entire user session, not for a specific message
or prompt.

   Value

      The field is 4 octets, containing a 32-bit unsigned integer with
      the maximum number of seconds this user should be allowed to
      remain connected by the NAS.

> should say "need only be different from the previous request".

I was pointing out that uniqueness (good or bad) isn't actually
possible.  "Minimal reuse" is possible, though.

> intent was to make clear that there is an independent Identifier space for

In that case, removing the reference to "ports" (which aren't defined
or used elsewhere in the document) might be good.

---

From: [email-masked] (Nick Petroni)
Date: Sun, 5 Jan 2003 15:46:02 -0500 (EST)

> other than a retransmission, then you must change the Identifier
Maybe I am misunderstanding the second sentence, but
why can't the authenticator expect a response to prior requests if
mutliple different ones can be sent (which I am not sure they can)? The
Peer MUST respond to all requests, how should it know a new one is coming
and that is shouldn't respond to the old one?
Perhaps you mean the authenticator can choose to disregard responses to
old requests? In that case, how will the peer know which track the
conversation is following since the original requests could have arrived
out of order?

---

From: [email-masked] (James Carlson)
Date: Sun, 5 Jan 2003 16:21:45 -0500

Nick Petroni writes:
> mutliple different ones can be sent (which I am not sure they can)?

Because the only Response that the authenticator can accept is one
that has an Identifier that matches the current value.  If I send
Request ID=1 and then send Request with ID=2, I can receive only
Response with ID=2.  As RFC 2284 puts it:

      [...] The
      Identifier field of the Response MUST match that of the Request.

I suppose as a design point, one could imagine having multiple
outstanding Requests.  Since the negotiation was patterned after PPP
negotiation, I doubt that was the intent.

> The

It can't know in advance.  But if an implementation receives a new
Request with a new ID value, then it does not have to respond to any
prior Requests to which it hasn't already responded.  By definition, a
properly implemented EAP authenticator would discard them anyway.

> old requests?

I would argue that it *must* disregard responses to old requests.

> In that case, how will the peer know which track the

EAP was originally defined to run on PPP and RFC 1661 has the
necessary ordering requirement:

1.  Introduction

   The Point-to-Point Protocol is designed for simple links which
   transport packets between two peers.  These links provide full-duplex
   simultaneous bi-directional operation, and are assumed to deliver
   packets in order.  It is intended that PPP provide a common solution

Any other transport of EAP *must* respect the ordering requirements of
PPP.

All that any EAP authenticatee has to do is to respond to the Request
messages that come in.  It doesn't have to "track" any conversations.

---

From: [email-masked] (Nick Petroni)
Date: Sun, 5 Jan 2003 16:46:39 -0500 (EST)

> necessary ordering requirement:
Originally, yes. But, 2284bis extends the applicability of EAP. From
section 3 of 2284bis:
[4]  Possible reordering. EAP provides its own mechanisms to detect
     reordering and so does not assume that the lower layer provides
     ordering guarantees. EAP is a "lockstep" protocol, so that the
     Authenticator MUST NOT send a new Request until a Response is
     received to an outstanding Request. Since the Peer should not
     expect a new Request until it has sent a Response, if it receives a
     new Request with a different Identifier before sending a Response
     to the outstanding Request, the new Request MUST be silently
     discarded. Similarly, if the Authenticator receives a Response with
     an Identifier that does not match the Identifier in the outstanding
     Request, the Response MUST be silently discarded.

> messages that come in.  It doesn't have to "track" any conversations.
Methods may rely on messages being presented to them in a certain order,
if EAP does not guarantee this order much more work needs to be put into
method design. I don't think the case can be made that EAP just shouldn't
be run over out-of-order protocols. Perhaps method designers can weigh-in
on this a little, but I would think problems do arise without in-order
presentation.

nick

---

From: [email-masked] (James Carlson)
Date: Mon, 6 Jan 2003 11:03:31 -0500

Nick Petroni writes:
>      ordering guarantees.

This part is false.  EAP as defined in the draft simply cannot detect
all possible cases of reordering.  Consider the following case:

	Authenticator		Authenticatee
	Request ID=1 >--------> (got req 1)
                          ----< Response ID=1
	(timeout)        /
	Request ID=1 >--/
	               /\
	(got resp 1) <-  |
	Request ID=2 >--------> (got req 2)
	                 |  --< Response ID=2
	                 | /
	(got resp 2) <-----
	                  \
	                   ---> (got req 1)
	(disc bad id) <-------< Response ID=1

At this point, the session is completely scrazzled.  Authenticatee is
unable to tell that the second "Request ID=1" message it got was
actually just a retransmission, so it must treat it as a new Request,
and must reinvoke whatever process was used to generate the Response.
Besides being just wasteful, this also means that (1) any saved state
on the Authenticatee side (e.g., values used to compute shared keys)
is now trashed and (2) the actual Response data may differ from the
original Response data, leading to chaos.

EAP as currently defined can't do what you want here.  If the RFC had
defined a sequence space with a "less than" comparison operation, then
you could probably do it, but that's no longer the same as RFC 2284
EAP.

> EAP is a "lockstep" protocol, so that the
>      discarded.

That's not compatible with 2284, which has no such restriction.

> be run over out-of-order protocols.

Really?  Why not?  That was the original intent of RFC 2284.  It was
modeled on PPP negotiation, and PPP negotiation most explicitly does
*not* survive out-of-order delivery.  If there's some transport being
planned for EAP that does present the possibility of out-of-order
delivery, then I think that probably needs a little more careful
examination.

> Perhaps method designers can weigh-in

Those problems certainly do arise.