eap Mailing List: Issue 173:

[Bernard Aboba (aboba]

Issue 173: RFC 2284bis method issues
Submitter name: Bernard Aboba
Submitter email address: aboba [at] internaut.com
Date first submitted: 9/11/2003
Reference:
http://mail.frascone.com/pipermail/public/eap/2003-September/001656.html
Document: EAP-05
Comment type: E
Priority: S
Section: Various
Rationale/Explanation of issue:

There are no security claims for the Identity (5.1),
Notification (5.2), and NAK  (legacy, 5.3.1 or expanded, 5.3.2) methods.

For each of these methods, insert the following claims:

Security Claims (see Section 7.2):

Intended use: Physically secure lower layers;
     vulnerable to attack when used
     with wireless or over the Internet.
Fragmentation: No
Auth. Mechanism: None
Ciphersuite Negotiation: No
Mutual authentication: No
Integrity protection: No
Replay protection: No
Confidentiality: No
Key Derivation: No
Key strength: N/A
Dictionary attack prot: N/A
Key hierarchy: N/A
Fast reconnect: No
Crypt. binding: N/A
Acknowledged S/F: No

Other than a statement in Section 3.1, there is no
explicit statement about whether the methods defined
in RFC 2284bis support fragmentation. This should be
stated explicitly, and added as a required claim.

Add:

"Fragmentation: No
Auth. Mechanism: None
Ciphersuite Negotiation: No"

to Sections 5.1, 5.2, 5.3.1, 5.3.2, 5.4, 5.5, 5.6

Also, change "Mechanism:" To "Auth. Mechanism:" in these
sections.

Add the following to Section 7.2.1:

"Protected Ciphersuite negotiation
This refers to the ability of an EAP method to
negotiate the ciphersuite used to protect the
EAP conversation, as well as to integrity protect the
negotiation. It does not refer to the ability to
negotiate the ciphersuite used to protect data.

Fragmentation
This refers to whether an EAP method supports fragmentation
and reassembly. As noted in Section 3.1, EAP methods
should support fragmentation and reassembly if EAP packets
can exceed the minimum MTU of 1020 octets."