Subject: [eap] editorial issues on 2284bis-03.f

From: [email-masked] (Jari Arkko)
Date: Sun, 11 May 2003 14:35:59 +0300

A few minor editorial nits that should probably be handled somehow:

> 1. Introduction
> 
>    EAP may be used on dedicated links as well as switched circuits, and
>    wired as well as wireless links.  To date, EAP has been implemented
>    with hosts and routers that connect via switched circuits or dial-up
>    lines using PPP [RFC1661]. It has also been implemented with switches
>    and access points using IEEE 802 [IEEE.802.1990].  EAP encapsulation
>    on IEEE 802 wired media is described in [IEEE.802.1X].

Add wireless LANs to this list: "EAP encapsulation on IEEE
wireless LANs is described in [IEEE.802-11.1999]."

> 1.2
>    authenticator
>              The end of the EAP link initiating EAP authentication. The
>              term authenticator is used in [IEEE.802.1X], and has the
>              same meaning in this document.
> 
>    peer
>              The end of the EAP Link that responds to the authenticator.
>              In [IEEE.802.1X], this end is known as the Supplicant.

Just wondering about the capitalization. Does IEEE 802.1X really
call something "authenticator" and something else "Supplicant"?

> 1.3 Security claims terminology for EAP methods
> 
>    These terms are used in particular in Section 7.2:

s/in particular in Section 7.2/to described the security
properties of EAP methods/

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

Propose to use a slightly different formatting here, maybe
the XML2RFC style='symbol' lists?

> 2. ...
> 
>       For sessions in which the authenticator acts as a pass-through, it
>       MUST determine the outcome of the authentication solely based on
>       the Accept/Reject indication sent by the backend authentication
>       server; the outcome MUST NOT be determined by the contents of an
>       EAP packet sent along with the Accept/Reject indication, or the
>       absence of such an encapsulated EAP packet.

This normative language should be moved somewhere else, it
seems a bit out of place in the advantages list. Maybe Section
2.2?

> 2.1. ...
>    Supporting multiple authentication methods within an EAP conversation
>    would add complexity to the EAP protocol, would enable
>    man-in-the-middle attacks (see Section 7.4), and would result in
>    interoperability problems, since existing EAP implementations
>    typically do not support multiple authentication methods.

The above text seems a bit out of place, its like a statement of
the consensus in the wg and why we have done something.
Suggested rewrite: "Multiple authentication methods within an
EAP conversation are not supported due to their vulnerability to
man-in-the-middle attacks (see Section 7.4) and incompatibility
with existing implementations.", and move this text to be the
lead-in for the last paragraph.

> 6.1 Definition of Terms

Remove the 6.1 heading, I believe the reader will find it
easier to go to the right place in the document if the
structure of the IANA section is "6.1. Packet Codes" and
"6.2. Method Types". Merge the below paragraphs in the above
text, after the first paragraph in 6.

> 6.2 Recommended Registration Policies

Paragraph 2 goes to new 6.1, rest to 6.2.

--Jari

---

From: [email-masked] (Bernard Aboba)
Date: Sun, 11 May 2003 11:51:38 -0700 (PDT)

Filed (along with the Displayable Message issue) as Issue 126.