Subject: [eap] Issue #21: Editorial issues in RFC 2284bis-04

From: [email-masked] (Bernard Aboba)
Date: Fri, 3 May 2002 11:37:27 -0700 (PDT)

Issue 21: Editorial issues with RFC 2284bis-04
Submitter: Jesse Walker
Submitter email address: [email-masked]
Date first submitted: May 3, 2002
Reference: 
Document: RFC2869bis-04
Comment type: E
Priority: S
Section: 2, 2.1, 4.2, 9.1, 9.8
Rationale/Explanation of issue:

Section 2, page 5 says under "Advantages":

The EAP protocol can support multiple authentication mechanisms
without having to pre-negotiate a particular one.

Certain devices (e.g. a NAS, switch or access point) do not
necessarily have to understand each request type and may be able to
simply act as a pass-through agent for a "back-end" server on a host.
The device only need look for the success/failure code to terminate
the authentication phase.

A third advantage of EAP might be noted. The separation of authentication
from the point of access simplifies credentials management and policy
decision making.

Section 2, page 5 also says under "Disadvantage":

For use in PPP, EAP does require the addition of a new authentication
type to PPP LCP and thus PPP implementations will need to be modified
to use it. It also strays from the previous PPP authentication model
of negotiating a specific authentication mechanism during LCP.
Similarly, switch or access point implementations need to support
[IEEE8021X] in order to use EAP.

A second disadvantage might be noted. The separation of authentication
from the point of access complicates the security analysis and, if it is
needed, key distribution.

This dichotomy between better management and more fragile security is a
property of all schemes that separate the policy decision point from the
policy enforcement point, and it would be worthwhile for the text to
document it, so that the tradeoffs facing us are clear.

Section 2.1 page 6, point (a) has a minor grammar error,
"receives a EAP response" instead of "an EAP response." I'd love to
produce a document someday that has only a single grammatical error.

Section 4.2 page 12 has an implementation note saying

Implementation Note: Because the Success and Failure packets are
not acknowledged, the Authenticator cannot know whether they have
been received. As a result, these packets are not retransmitted by
the Authenticator, and if they are lost, the Peer will timeout and
retry the authentication.

Sorry for being so obtuse, but I can't fathom what this is trying to tell
me. I find this text confusing, since the pages preceeding it carefully
explain that EAP does not permit the Peer to retry anything, but only to
respond to the EAP Authenticator.

The only conclusion I can draw is it constitutes a reference to some
unidentified entity outside of EAP, thus coupling the correct behavior of
EAP to the containing environment behaving correctly. This sort of
coupling always deserves examination, especially within a scheme allegedly
related to authentication.

If that is the correct conclusion, this points to a design problem within
EAP that we will want to think about more in the long term, as it could
imply that misbehaving environments (e.g., those partially controlled by
attackers) might be able to subvert the protocol, regardless of the
quality of the concrete authentication method. If my surmise is instead
incorrect, then please help me understand the intended meaning of the
language.

Section 9.1 page 22 spells "omitted" as "ommitted."

The fifth paragraph of Section 9.8 says:

the session key negotiated between the Peer and EAP server will
need to be transmitted to the Authenticator.

The EAP method might very well have to transmit the key the Peer as well,
so this should be noted.