Subject: [eap] Proposed resolution to Issue 126: Miscellaneous NITs

From: [email-masked] (Bernard Aboba)
Date: Mon, 12 May 2003 10:36:10 -0700 (PDT)

I'd like to propose that these proposed changes be accepted. Note that
I've moved some of the changes that require more discussion into another
issue.

-------------------------------------------------------------------
Issue 126: Miscellaneous NITs
Submitter name: Jari Arkko
Submitter email address: [email-masked]
Date first submitted: May 10, 2003
Reference:
http://mail.frascone.com/pipermail/public/eap/2003-May/001191.html
Document: EAP-03f
Comment type: E
Priority: S
Section: Various
Rationale/Explanation of issue:
A few minor editorial nits that should probably be handled somehow:

> 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"?

[BA] -
It uses Authenticator and Supplicant. The definition of authenticator
should be:

authenticator
The end of the EAP link initiating EAP authentication. The
term Authenticator is used in [IEEE.802.1X], and
authenticator has the same meaning in this document.

> 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.

> Length
>
> The Length field is two octets and indicates the length of the EAP
> packet including the Code, Identifier, Length and Data fields.

I'd prefer "The Length field is two octets. It indicates the number of
octets in the EAP packet including the Code, Identifier, Length, and Data
fields."

Also, Section 4 and 4.1 have duplicate text for the description of
the Length field. Suggest cutting the first text shorter, maybe
"The Length field is two octets and indicates the length of the
complete EAP packet."

[BA] This could be conceived of including MAC headers too, so I'd prefer
we leave it as it is.

> 4.1 ...
>
> Retransmitted Requests MUST be sent with the same Identifier value
> in order to distinguish them from new Requests. The contents of
> the data field is dependent on the Request Type. The peer MUST

"are dependent" ?

> 5. Initial EAP Request/Response Types
>
> All EAP implementations MUST support Types 1-4, which are defined in
> this document, and SHOULD support Type 254. Follow-on RFCs MAY define
> additional EAP Types.

MAY in the last sentence does not appear to be an implementation
requirement. Replace with "Implementations MAY support other
Types defined here or in future RFCs."

> 5.7 Expanded Types
>
> Description
>
> Due to EAP's popularity, the original method Type space, which
> only provides for 255 values, is being allocated at a pace which
> if continued would result in exhaustion within a few years.

This is an interesting status report, but may not be very useful in
a protocol specification. In any case, the text that comes after this
explains the purpose of the scheme. Suggestion: delete the first
sentence.

> 7.11. ...
>
> This can be done by enabling users to configure which are the
> acceptable ciphersuites as a matter of security policy; or, the
> ciphersuite negotiation MAY be authenticated using keying material
> derived from the EAP authentication and a MAC algorithm agreed upon
> in advance by lower-layer peers.

s/MAC/MIC/

---

From: [email-masked] (Jari Arkko)
Date: Mon, 12 May 2003 21:18:59 +0300

> [BA] This could be conceived of including MAC headers too, so I'd prefer

Yes, I see your point. Better have duplicated correct text than
one correct and one incorrect text ;-)

--Jari