Subject: [eap] Issue 44: Peer-to-Peer Operation of EAP

From: [email-masked] (Bernard Aboba)
Date: Wed, 27 Nov 2002 11:42:17 -0800 (PST)

Issue 44: Peer-to-Peer Operation of EAP
Submitter: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: November 25, 2002
Reference:
Document: RFC2284bis-07
Comment type: T
Priority: S
Section:  2
Rationale/Explanation of issue:

Since EAP is a peer-to-peer protocol, this should be added to the
description of how the protocol operates.

Add the following text to section 2:

"[7] Since EAP is a peer-to-peer protocol, after authentication in one
direction is complete, the direction of authentication
MAY reverse, with the endpoint previously serving as the Authenticator
assuming the Peer role, and the former Peer now taking on the
Authenticator role. As with the original conversation, the reversal is
signaled by the (new) Authenticator sending a Request."

---

From: [email-masked] (Jari Arkko)
Date: Wed, 27 Nov 2002 20:53:11 +0200

> signaled by the (new) Authenticator sending a Request."

Hmm... this has interesting implications for the state machine
design! Is there any possibility of having two "instances" of
EAP running in different directions instead of doing both for the
same EAP run? Can EAP "host" protocols such as PPP or 802.1X
allow more than one EAP "run"?

What about backwards compatibility? I suppose on PPP most implementations
would allow this, right? What about 802.1X?

Jari

---

From: [email-masked] (Bernard Aboba)
Date: Wed, 27 Nov 2002 13:38:08 -0800 (PST)

> would allow this, right? What about 802.1X?

Since PPP is a peer-to-peer protocol, and EAP was developed as part of
PPP, peer-to-peer operation is one of the implicit assumptions of EAP.

While IEEE 802.1X appears at first glance to be a client-server protocol,
it is possible for a peer to implement both Supplicant and Authenticator
roles, and in fact, this is required for adhoc operation within IEEE
802.11.

So this Issue does not really represent new functionality, but rather
clarifying functionality that has been in EAP from the beginning (but
which many implementations have missed).

Another implication of this occurs within RFC 2869bis, where it has been
suggested that RADIUS/EAP should be capable of handling role reversal,
thereby carrying an EAP-Request within a RADIUS Access-Request. There
is no intrinsic reason why RADIUS cannot do this -- after all, it's just
an encapsulation.

However, a given RADIUS server may not handle it -- in which case I think
that the proper behavior is probably sending an Access-Reject without an
embedded EAP-Message attribute. No EAP-Message attribute can be sent
because an EAP peer cannot send an EAP-Failure to an Authenticator, and
therefore there is no EAP message that means "I don't support role
reversal".