Subject: [eap] Issue 159: Organization Issues

From: [email-masked] (Bernard Aboba)
Date: Thu, 10 Jul 2003 09:04:25 -0700 (PDT)

Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: July 9, 2003
Reference:
Document: EAP-04
Comment type: E
Priority: 1
Section: 2.2, 4.1
Rationale/Explanation of issue:

The organization of section 2.2 and 4.1 could be improved.

Proposed changes:

Delete the following text from Section 2.2:

Paragraphs from "Where an authenticator operates as a pass-through..."
to the end of the section (all material relating to pass-through
operation).

Add the following text to Section 2.3:

2.3 Pass-through behavior

Where an authenticator operates as a pass-through, it forwards
packets back and forth between the peer and a backend authentication
server, based on the EAP layer header fields (Code, Identifier,
Length). This includes performing validity checks on the Code,
Identifer and Length fields, as described in Section 4.1.

Since pass-through authenticators rely on a backend authenticator
server to implement methods, the EAP method layer header fields
(Type, Type-Data) are not examined as part of the forwarding
decision. The forwarding model is illustrated in Figure 2. Compliant
pass-through authenticator implementations MUST by default be capable
of forwarding packets from any EAP method. The use of the RADIUS
protocol for encapsulation of EAP in pass-through operation is
described in [RFC2869bis].
    Peer           Pass-through Authenticator    Authentication
                                                    Server

+-+-+-+-+-+-+                             +-+-+-+-+-+-+
|           |                             |           |
|EAP method |                             |EAP method |
|     V     |                             |     ^     |
+-+-+-!-+-+-+  +-+-+-+-+-+-+-+-+-+-+-+-+  +-+-+-!-+-+-+
|     !     |  |           |           |  |     !     |
|EAP  !layer|  | EAP layer | EAP layer |  |EAP  !layer|
|     !     |  |     +-----+-----+     |  |     !     |
|     !     |  |     !     |     !     |  |     !     |
+-+-+-!-+-+-+  +-+-+-!-+-+-+-+-+-!-+-+-+  +-+-+-!-+-+-+
|     !     |  |     !     |     !     |  |     !     |
|Lower!layer|  |Lower!layer| AAA ! /IP |  | AAA ! /IP|
|     !     |  |     !     |     !     |  |     !     |
+-+-+-!-+-+-+  +-+-+-!-+-+-+-+-+-!-+-+-+  +-+-+-!-+-+-+
      !              !           !              !
      !              !           !              !
      +-------->-----+           +------->------+

Figure 2: Pass-through Authenticator

For sessions in which the authenticator acts as a pass-through, it
MUST determine the outcome of the authentication solely based on the
Accept/Reject indication sent by the backend authentication server;
the outcome MUST NOT be determined by the contents of an EAP packet
sent along with the Accept/Reject indication, or the absence of such
an encapsulated EAP packet."

Replace Section 4.1 with the following:

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

Retransmitted Requests MUST be sent with the same Identifier value
in order to distinguish them from new Requests. The contents of
the data field are 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.

If a peer receives a valid duplicate Request for which it has
already sent a Response, it MUST resend its original Response
without reprocessing the Request. Requests MUST be processed in
the order that they are received, and MUST be processed to their
completion before inspecting the next Request.

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.

The Identifier field of the Response MUST match that of the
currently outstanding Request. An authenticator receiving a
Response whose Identifier value does not match that of the
currently outstanding Request MUST silently discard the Response.

In order to avoid confusion between new Requests and retransmissions,
the Identifier value chosen for each new Request need only be
different from the previous Request, but need not be unique within
the conversation. One way to achieve this is to start the Identifier
at an initial value and increment it for each new Request. Initializing
the first Identifier with a random number rather than starting from
zero is recommended, since it makes sequence attacks somewhat
harder.

Since the Identifier space is unique to each session,
authenticators are not restricted to only 256 simultaneous
authentication conversations. Similarly, with re-authentication,
an EAP conversation might continue over a long period of time, and
is not limited to only 256 roundtrips.

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 peer is responsible
for detecting and handling duplicate Request messages before
processing them in any way, including passing them on to an
outside party. 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.
Since the authenticator can retransmit before receiving a
Response from the peer, the authenticator can receive multiple
Responses, each with a matching Identifier. Until a new Request
is received by the authenticator, the Identifier value is not
updated, so that the authenticator forwards Responses to the
backend authentication server, one at a time.

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 MUST be ignored on
reception. A message with the Length field set to a value larger
than the number of received octets MUST be silently discarded.

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. An initial specification of Types follows
in Section 5 of this document.

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) indicating that a Request Type is unacceptable
to the peer. A peer MUST NOT send a Nak (legacy or expanded)
in response to a Request, after an initial non-Nak Response has
been sent. An EAP server receiving a Response not meeting these
requirements MUST silently discard it.

Type-Data

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