| Proposed Resolution to Issue 161: SM Demultiplexing | <– Date –> <– Thread –> |
From: Bernard Aboba (aboba internaut.com)
|
|
| Date: Mon, 27 Oct 2003 22:02:35 -0600 (CST) | |
The text of Issue 161 is enclosed below. A fix to the state machine
document has been discussed in a previous thread. The proposed fix within
RFC 2284bis is as follows:
Replace the text of Sections 2.2, 2.3 and 2.4 in RFC 2284bis with the
following:
2.2 EAP multiplexing model
Conceptually, EAP implementations consist of the following
components:
[a] Lower layer. The lower layer is responsible for transmitting and
receiving EAP frames between the peer and authenticator. EAP has
been run over a variety of lower layers including PPP; wired IEEE
802 LANs [IEEE-802.1X]; IEEE 802.11 wireless LANs [IEEE-802.11];
UDP (L2TP [RFC2661] and IKEv2 [IKEv2]); and TCP [PIC]. Lower
layer behavior is discussed in Section 3.
[b] EAP layer. The EAP layer receives and transmits EAP packets via
the lower layer, implements duplicate detection and
retransmission, and delivers and receives EAP messages to and
from the EAP peer and authenticator layers.
[c] EAP peer and authenticator layers. Based on the Code field, the
EAP layer demultiplexes incoming EAP packets to the EAP peer and
authenticator layers. Typically an EAP implementation on a given
host will support either peer or authenticator functionality, but
it is possible for a host to act as both an EAP peer and
authenticator. In such an implementation both EAP peer and
authenticator layers will be present.
[d] EAP method layers. EAP methods implement the authentication
algorithms and receive and transmit EAP messages via the EAP peer
and authenticator layers. Since fragmentation support is not
provided by EAP itself, this is the responsibility of EAP methods,
which are discussed in Section 5.
The EAP multiplexing model is illustrated in Figure 1 below. Note
that there is no requirement that an implementation conform to this
model, as long as the on-the-wire behavior is consistent with it.
+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+
| | | | | |
| EAP method| EAP method| | EAP method| EAP method|
| Type = X | Type = Y | | Type = X | Type = Y |
| V | | | ^ | |
+-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+
| ! | | ! |
| EAP ! Peer layer | | EAP ! Auth. layer |
| ! | | ! |
+-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+
| ! | | ! |
| EAP ! layer | | EAP ! layer |
| ! | | ! |
+-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+
| ! | | ! |
| Lower ! layer | | Lower ! layer |
| ! | | ! |
+-+-+-+-!-+-+-+-+-+-+-+-+ +-+-+-+-!-+-+-+-+-+-+-+-+
! !
! Peer ! Authenticator
+------------>-------------+
Figure 1: EAP Multiplexing Model
Within EAP, the Code field functions much like a protocol number in
IP. It is assumed that the EAP layer demultiplexes incoming EAP
packets according to the Code field. Received EAP packets
with Code=1 (Request), 3 (Success) and 4 (Failure) are
delivered by the EAP layer to the EAP peer listener, if
present. EAP packets with Code=2 (Response) are delivered
to the EAP authenticator listener, if present.
Within EAP, the Type field functions much like a port number in UDP
or TCP. It is assumed that the EAP peer and authenticator layers
demultiplex incoming EAP packets according to their Type, and deliver
them only to the EAP method corresponding to that Type. An
EAP method implementation on a host may register to receive
packets from the peer or authenticator listener, or both.
Since EAP authentication methods may wish to access the Identity,
implementations SHOULD make the Identity Request and Response
accessible to authentication methods (Types 4 or greater) in addition
to the Identity method. The Identity Type is discussed in Section
5.1.
A Notification Response is only used as confirmation that the peer
received the Notification Request, not that it has processed it, or
displayed the message to the user. It cannot be assumed that the
contents of the Notification Request or Response is available to
another method. The Notification Type is discussed in Section 5.2.
Nak (Type 3) or Expanded Nak (Type 254) are utilized for the purposes
of method negotiation. Peers respond to an initial EAP Request for
an unacceptable Type with a Nak Response (Type 3) or Expanded Nak
Response (Type 254). It cannot be assumed that the contents of the
Nak Response(s) are available to another method. The Nak Type(s) are
discussed in Section 5.3.
EAP packets with codes of Success or Failure do not include a Type
field, and are not delivered to an EAP method. Success and Failure are
discussed in Section 4.2.
Given these considerations, the Success, Failure, Nak Response(s) and
Notification Request/Response messages MUST NOT be used to carry data
destined for delivery to other EAP methods.
2.3 Pass-through behavior
When operating as a "pass-through authenticator", an
authenticator performs checks on the Code, Identifier and
Length fields as described in Section 4.1. It
forwards EAP packets received from the peer and
destined to its authenticator listener to the backend
authentication server; packets received from the
backend authentication server destined to the peer
are forwarded to it.
The forwarding decision is based on examination of the
Code, Identifier and Length fields. Since a "pass-through
authenticator" only forwards to the backend authentication
server EAP packets received from the peer and destined for its
authenticator listener, pass-through authenticator
implementations MUST be capable of forwarding to the
backend authentication server EAP packet received from
the peer with Code=2 (Response). They also MUST be capable
of receiving EAP packets from the backend authentication
server and forwarding EAP packets of Code=1 (Request),
Code=3 (Success), and Code=4 (Failure) to the peer.
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, except where the authenticator implements one or more
authentication methods locally. In this case, the authenticator
may examine the Type field to determine whether to act on the
packet itself or forward it. Compliant pass-through
authenticator implementations MUST be default forward EAP
packets of any Type. The forwarding model is illustrated
in Figure 2.
Since EAP packets received with Code=1 (Request), Code=3 (Success),
and Code=4 (Failure) are demultiplexed by the EAP layer and
delivered to the peer listener, unless a host implements
an EAP peer listener, these packets will be silently
discarded. The behavior of a "pass-through peer" is
undefined within this specification, and is unsupported by
AAA protocols such as RADIUS [RFC3579] and Diameter [DiamEAP].
Peer Pass-through Authenticator Authentication
Server
+-+-+-+-+-+-+ +-+-+-+-+-+-+
| | | |
|EAP method | |EAP method |
| V | | ^ |
+-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+
| ! | |EAP | EAP | | | ! |
| ! | |Peer | Auth.| EAP Auth. | | ! |
|EAP ! peer| | | +-----------+ | |EAP !Auth.|
| ! | | | ! | ! | | ! |
+-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+
| ! | | ! | ! | | ! |
|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.
2.4 Peer-to-Peer Operation
Since EAP is a peer-to-peer protocol, an independent and simultaneous
authentication may take place in the reverse direction (depending on
the capabilities of the lower layer). Both peers may act as
authenticators and authenticatees at the same time; in this case it
is necessary to both peers to implement both EAP authenticator and
peer listeners. In addition, the EAP method implementations on
both peers must support both authenticator and peer functionality.
Although EAP supports peer-to-peer operation, some EAP
implementations, methods, AAA protocols and link layers may not
support this. For example, EAP-TLS [RFC2716] is a client-server
protocol requiring a different certificate profile for the client and
server. This implies that a host supporting both the EAP-TLS peer and
authenticator roles would need to implement both peer and
authenticator listeners; would need to support both the peer and
authenticator roles in the EAP-TLS implementation; would need to be
provisioned with two distinct certificates, one appropriate for each
role.
Some EAP methods may support asymmetric authentication, with one type
of credential being required for the peer and another type for the
authenticator. Hosts supporting peer-to-peer operation with such a
method would need to be provisioned with both types of credentials.
AAA protocols such as RADIUS/EAP [RFC3579] and Diameter EAP
[DIAM-EAP] only support "passthrough authenticator" operation.
As noted in [RFC3579] Section 2.6.2, a RADIUS server responds to an
Access-Request encapsulating an EAP-Request, Success or Failure
packet with an Access-Reject. There is therefore no support for
"passthrough peer" operation.
Link layers such as IEEE 802.11 may only support uni-directional
derivation and transport of transient session keys. For example, the
group-key handshake defined in [IEEE-802.11i] is uni-directional,
since in IEEE 802.11 only the Access Point (AP) sends multicast
traffic. This means that in ad-hoc operation where either peer may
send multicast traffic, two uni-directional group-key exchanges are
required. Due to constraints imposed by the 4-way unicast key
handshake state machine, this also implies two 4-way handshake and
EAP method exchanges.
Link layers such as IEEE 802.11 adhoc also do not support "tie
breaking" wherein two hosts initiating authentication with each other
will only go forward with a single authentication. This implies that
even if 802.11 were to support a bi-directional group-key handshake,
then two authentications, one in each direction, might still occur."
----------------------------------------------------------------
Issue 161: State Machine demultiplexing
Submitter name: Florent Bersani
Submitter email address: florent.bersani [at] francetelecom.com
Date first submitted: July 21, 2003
Reference:
http://mail.frascone.com/pipermail/public/eap/2003-July/001504.html
Document: SM-04
Comment type: T
Priority: S
Section:
Rationale/Explanation of issue:
When two peers simultaneously perform EAP authentications (that is to say
A acts as a peer in dialog #1 with B which acts as an authenticator and,
at the same time, A acts as an authenticator in dialog #2 with B which
acts as a peer) the EAP dialogs have to get demultiplexed: this can easily
be done according to the EAP code field (responses go to the authenticator
and other codes - requests, success and failure - go to the peer).
The question is : who does this demultiplexing ? Should it be the lower
layer (which then would have to read and understand the EAP layer) or the
EAP state machine (which then should be modified, I think) ?
- (no other messages in thread)
Results generated by Tiger Technologies using MHonArc.