| Re: proposed resolution to Issue 161 | <– Date –> <– Thread –> |
From: Bernard Aboba (aboba internaut.com)
|
|
| Date: Sat, 25 Oct 2003 09:16:07 -0500 (CDT) | |
Here is a revision that hopefully addresses Nick's issue...
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. It is possible for a host to act as both
EAP peer and authenticator, and in this case 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 is used 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.
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
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 checks on the Code,
Identifier 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, 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.
The forwarding model is illustrated in Figure 2. Compliant
pass-through authenticator implementations MUST by default
forward EAP packets of any Type. Pass-through authenticator
implementations MUST support forwarding Response (Code=2)
packets to the backend authentication server, and receiving
EAP Request (Code=1), Success (Code=3) and Failure (Code=4) packets
from the backend authentication server. Implementations MAY be
capable of forwarding Request (Code=1), Success (Code=3) and
Failure (Code=4) packets to the backend authentication server, and
receiving EAP Response (Code=2) packets from the backend authentication
server.
Where the pass-through device implements an EAP peer listener,
it will not forward to the backend authentication server
EAP Request (Code=1), Success (Code=3) or Failure (Code=4)
packets in order to act on them locally. The use of the
RADIUS protocol for encapsulation of EAP in pass-through
operation is described in [RFC3579].
Peer Pass-through Authenticator Authentication
Server
+-+-+-+-+-+-+ +-+-+-+-+-+-+
| | | |
|EAP method | |EAP method |
| V | | ^ |
+-+-+-!-+-+-+ +-+-+-!-+-+-+
| ! | | ! |
|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.
Although EAP supports peer-to-peer operation, selected EAP 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 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" operation on behalf of an
authenticator, not a peer. As noted in [RFC3579] Section
2.6.2, a RADIUS server responds to an Access-Request encapsulating an
EAP-Request with an Access-Reject.
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.
-
Re: proposed resolution to Issue 161 Bernard Aboba, October 23 2003
- Re: proposed resolution to Issue 161 Bernard Aboba, October 25 2003
Results generated by Tiger Technologies using MHonArc.