Subject: [eap] Proposed resolution of Issue 118: Mutual Authentication

From: [email-masked] (Dror Caspi)
Date: Wed, 30 Apr 2003 09:34:31 +0300

I believe that Jesse Walker's last responce should be taken into =
account; i.e., if EAP can't really be used properly for peer-to-peer =
situation, this should be stated clearly in EAP as well as in 802.1X.

Dror

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]]
> Sent: Tuesday, April 29, 2003 9:45 PM
> To: [email-masked]
> Subject: [eap] Proposed resolution of Issue 118: Mutual Authentication
>=20
>=20
> The text of Issue 118 is enclosed below. Based on the=20
> discussion so far,
> it does not appear that any additional text is required in=20
> RFC 2284bis to
> address this (though additional text might be added in IEEE=20
> 802.1X). As a
> result, my recommendation is that this issue be rejected. Any=20
> objections?
>=20
>=20
> --------------------------------------------------------------
> ---------
> Issue 118: Mutual Authentication
> Submitter name: Dror Caspi
> Submitter email address: [email-masked]
> Date first submitted: April 21, 2003
> Reference:
> Document: EAP-02
> Comment type: T
> Priority: 2
> Section: Various
> Rationale/Explanation of issue:
>=20
> Having looked at the drafts of RFC2284bis, EAP-Archie and=20
> IEEE-802.1aa,
> it seems that most of the attention is given to systems where=20
> there is a
> distinction between an authenticator and a peer/supplicant. This
> distinction still exists even where mutual authentication is proposed
> (e.g., EAP-Archie).
>=20
> But what happens when both parties are peers (e.g., two=20
> bridge devices)?
> The possibility of role reversal is mentioned (i.e., run a session
> where one system is Authenticator and the other Peer, and then reverse
> the role). However it seems quite cumbersome; a single session of a
> protocol such as EAP-Archie would seem to provide the required
> authentication - yet there needs to be a mechanism to=20
> (randomly?) decide
> which party plays which role.
>=20
> Probably some of the above is misunderstanding on my part. However
> there seems to be a need for some explanatory text in the=20
> standards, if
> not for actual changes to accommodate peer-to-peer mutual=20
> authentication.
>=20
> Requested change:
>=20
> Add explanatory text about peer-to-peer mutual authentication. Modify
> the standards if required.
>=20
>=20
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap
>=20

---

From: [email-masked] (Bernard Aboba)
Date: Wed, 30 Apr 2003 06:57:42 -0700 (PDT)

Indeed it would appear that a clarification is needed -- and I've filed
this issue as #119. However, I don't agree that the clarification is the
type suggested by Jesse.

EAP was created for use with a peer-to-peer protocol, PPP. Although it is
initiated by the "authenticator", either PPP peer can play that role, and
in fact both can do so in two simulataneous conversations.

In 802.1X-2001 it was the intent to support this feature of EAP, but that
was not made clear. The IEEE 802.1aa effort is in the process of adding
text to make it clear that peer-to-peer operation is supported, and that
use of a backend authentication server is entirely optional (as it is
in both EAP and PPP).

Of course, without a backend authentication server, there is a credential
provisioning problem -- but that problem exists even without EAP and is
not made significantly more difficult by use of EAP as a transport instead
of say, UDP. True "peer to peer" authentication between network devices
is a problem that exists in context such as routing protocol security --
and the same methods are easily translatable to use with EAP. However,
provisioning a large number of routers with the appropriate credentials is
no small task -- and if an appropriate solution is not put in place, then
the solution is undeployable -- regardless of the transport used to carry
authentication.