eap Mailing List: Issue 202: Peer-to-peer cleanup

[Bernard Aboba (aboba]

Issue 202: Peer-to-peer cleanup
Submitter name: Bernard Aboba
Submitter email address: aboba [at] internaut.com
Date first submitted: Nov 19, 2003
Reference:
Document: RFC2284bis-06
Comment type: E
Priority: 1
Section: 2.2, 2.3, 2.4, 7.2.1
Rationale/Explanation of issue:

This is an issue to cleanup wording on peer-to-peer topics.  This responds
to issues raised by Jari Arkko relating to the term "peer listener" and
"authenticator listener".  On rethinking the terminology it appears to me
that the terms "peer layer" and "authenticator layer" serve just as well.

In Section 2.2, change:

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

To:

"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 layer, if implemented. EAP packets with Code=2 (Response) are
delivered to the EAP authenticator layer, if implemented. 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 layer, or both,
depending on which role(s) it supports."

In Section 2.3, change:

"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[DIAM-EAP]. "

To:

"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 layer to the
backend authentication server; packets received from the backend
authentication server destined to the peer are forwarded to it.  A host
receiving an EAP packet may only do one of three things with it:  act on
it, drop it, or forward it.  The forwarding decision is typically based
only on examination of the Code, Identifier and Length fields.  A
pass-through authenticator implementation MUST be capable of forwarding to
the backend authentication server EAP packets received from the peer with
Code=2 (Response). It 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.  Unless the
authenticator implements one or more authentication methods locally which
support the authenticator role, the EAP method layer header fields (Type,
Type-Data) are not examined as part of the forwarding decision.  Where the
authenticator supports local authentication methods, it MAY examine the
Type field to determine whether to act on the packet itself or forward it.
Compliant pass-through authenticator implementations MUST by default
forward EAP packets of any Type.  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 layer.  Therefore unless a host
implements an EAP peer layer, these packets will be silently discarded.
Similarly, EAP packets received with Code=2 (Response) are demultiplexed
by the EAP layer and delivered to the authenticator layer. Therefore
unless a host implements an EAP authenticator layer, 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[DIAM-EAP].  The forwarding model is
illustrated in Figure 2."

In Section 2.4, change:

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

To:

"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 which case it is necessary for both peers to implement
EAP authenticator and peer layers. 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 with a
different certificate profile for the client and server. This implies that
a host supporting peer-to-peer authentication with EAP-TLS would need to
implement both the EAP peer and authenticator layers; support both peer
and authenticator roles in the EAP-TLS implementation;  and provision two
distinct certificates, one appropriate for each role."