Subject: [eap] Issue 26: Unprotected Success and Failure

From: [email-masked] (Bernard Aboba)
Date: Mon, 21 Oct 2002 19:06:40 -0700 (PDT)

Issue 26: Unprotected Success and Failure
Submitter: Jesse Walker
Submitter email address: [email-masked]
Date first submitted: May 3, 2002
Reference:
Document: RFC2284bis-04
Comment type: T
Priority: S
Section: 4.2
Rationale/Explanation of issue:
Section 4.2 page 12 begins:

"The Success packet is sent by the Authenticator to the Peer to
acknowledge successful completion of an authentication method.
The Authenticator MUST transmit an EAP packet with the Code
field set to 3 (Success)."

We know from the 802.11 experience that the Success message as formulated
today has no reliable meaning within that context. The solution de jour
802.11 has proposed is to use 802.11 link level protections for the
Success message. This feels unsatisfactory, because it does not protect the
Success message the entire length of the channel between the EAP Authenticator and
the EAP Peer. It seems we will not arrive at a satisfactory solution until
we find a way to protect the Success message end-to-end across this entire
channel.

If this observation is valid, it would imply we need a cryptographic key
to protect the Success message, and the EAP architecture cannot be considered
complete until it deals with this problem (or else make devices that can
use EAP in environments like 802.11 non-conformant, which no one wants to do).
To be useful, such a key can only come as a bi-product of the authentication,
and it can be either a static key identified by the authentication or an
ephemeral key constructed as a bi-product of the authentication protocol
carried by EAP.

I might be wrong, but I haven't convinced myself it is sufficient to
simply "tunnel" the EAP Success message through TLS or IPsec or the like; it
seems like it is necessary to insert data orgin authentication fields the
Success packet itself to guarantee that some entity other than the Authenticator
has not forged the Success message; this is an application layer function, and
lower level security will not address the concern. It also feels like an
abuse to protect the Success via an underlying tunneling protocol, because
the EAP exchange exists to establish the trust that is assumed by any such
protocol. This suggest either extending the format of the existing Success
message, or introducing a new one that has all the necessary bells and
whistles for environments like 802.11. An alternate approach might be to
require use of a key distribution message in lieu of the Success in these
environments.

To prevent all kinds of forgeries, it is also necessary to deny replayed
Success messages between the same two Peers. For this to work, it is
necessary to tie the Success message to the packets conveyed by EAP during
this particular authentication. A typical hueristic that accomplishes this
is to use the key to hash all the information elements in all the packets we
care about, as well as the important fields of the Success message itself,
and the Success carries the hash to the Peer for verification; the Peer
verification will fail if the messages it exchanged differ. This hueristic
applies if the packets contain unguessable data; otherwise, some sort of
nonces will have to be introduced into the Request/Reply exchange, or we
would need to discover a new way to guarantee a live Success, or ban EAP
methods that don't introduce any session-specific material.

So the requirements for making the Success message generally meaningful is
that there must be some way to authenticate it, that the authentication
key used to do this has to stem from the authentication itself, that the
Success must be tied to the messages exchanged in this particular authentication
session, and that the authentication has to include information by which
the Peer can determine liveness and authenticity of the Success. It appears to
me today that the Success message itself should carry the protections,
although I might have this wrong about this.

I am not suggesting that 2284bis address this problem, since this kind of
change is out of scope of the document intent. Rather the issue and the
requirements for its solution should be noted somewhere, so that we have a
starting point if we are ever chartered to extend EAP.

Resolution: Discuss

[BA] I agree that it is important for EAP to
be extended to support acknowledged (and protected)
success and failure indications, and that this
is a requirement for secure operation on networks
where physical security cannot be assumed. This
has been added to the requirements in the security
considerations section. We should discuss whether
this should be handled in RFC 2284bis, possibly
along with the cryptographic binding issue (#40),
and acknowledged success/failure issue (#10).