Subject: [eap] Issue 86: Separation of EAP server and authenticator

From: [email-masked] (Bernard Aboba)
Date: Fri, 14 Feb 2003 07:15:54 -0800 (PST)

Issue 86: Separation of EAP server and authenticator
Submitter name: Henrik Levkowetz
Submitter email address: henrik.levkowetz.com
Date first submitted: February 14, 2003
Document: EAP-00
Comment type: Technical
Priority: S
Section: 7.X
Rationale/Explanation of issue:

There's one section of the original Issue 73 which I feel we may have
lost track of. We were talking about the injection of failure or
success packets between the authenticator and the eap server, and
you mentioned possibly stealing some text from 2869bis; I replied
something like the following on Feb 7:

There is some text there, but as it is talking about the RADIUS case,
not all is applicable, and it does not specifically talk about the
case of the unprotected generic EAP Success and Failure messages.
I propose a new section:

"7.xx Separation of EAP server and authenticator

It is possible for the EAP peer and authenticator to mutually
authenticate, and derive a Master Session Key (MSK) for a ciphersuite
used to protect subsequent data traffic. This does not present an
issue on the peer, since the peer and EAP client reside on the same
machine; all that is required is for the EAP client module to derive
and pass a Transient Session Key (TSK) to the ciphersuite module.

However, in the case where the EAP server and authenticator reside on
different machines, there are several implications for security.

[a] Authentication will occur between the peer and the EAP server,
not between the peer and the authenticator. This means that it is
not possible for the peer to validate the identity of the NAS or
tunnel server that it is speaking to, using EAP alone.

[b] As discussed in [RFC2869bis], the authenticator is dependent
on the AAA protocol in order to know the outcome of an
authentication conversation, and does not look at the encapsulated
EAP packet (if one is present) to determine the outcome. In
practice this means that the AAA protocol spoken between the
authenticator and authentication server MUST support per-packet
authentication, integrity and replay protection.

[c] A EAP Master Session Key (MSK) negotiated between the peer and
EAP server will need to be transmitted to the authenticator.
Therefore a mechanism needs to be provided to transmit the MSK
from the EAP server to the authenticator or tunnel server that
needs it. The specification of the key transport and wrapping
mechanism is outside the scope of this document.
"

Henrik

---

From: [email-masked] (Bernard Aboba)
Date: Fri, 14 Feb 2003 07:16:39 -0800 (PST)

I would like to propose that we accept the change suggested by Henrik in
Issue 86.