Subject: [eap] Issue 110: Miscellaneous NITs

From: [email-masked] (Bernard Aboba)
Date: Sat, 26 Apr 2003 13:27:42 -0700 (PDT)

Submitter name: Bernard Aboba
Submitter email address: [email-masked]
Date first submitted: April 25th, 2003
Reference:
Document: EAP-02
Comment type: E
Priority: 1
Section: Various
Rationale/Explanation of issue:
Throughout the document:

EAP Methods => EAP methods
Method Type => method Type
type => Type
local users => local peers
pass through => pass-through
expanded Type => Expanded Type
method- specific => method-specific
Authenticator => authenticator

First page:
Expiration and submission dates are wrong. should be
April 2003 submission and October 2003 expiration. Please
change in the header and Status of this Memo sections.

Abstract is somewhat awkward. Change to:

"This document defines the Extensible Authentication Protocol
(EAP), an authentication framework which supports multiple
authentication methods. EAP typically runs directly over data link
layers such as PPP or IEEE 802, without requiring IP. EAP
provides its own support for duplicate elimination and retransmission,
but is reliant on lower layer ordering guarantees. Fragmentation
is not supported within EAP itself; however, individual EAP
methods may support this.

This document obsoletes RFC 2284. A summary of the changes between
this document and RFC 2284 is available in Appendix B."

Rewrite the first paragraph of Section 1 to:

"This document defines the Extensible Authentication Protocol
(EAP), an authentication framework which supports multiple
authentication methods. EAP typically runs directly over data link
layers such as PPP or IEEE 802, without requiring IP. EAP
provides its own support for duplicate elimination and retransmission,
but is reliant on lower layer ordering guarantees. Fragmentation
is not supported within EAP itself; however, individual EAP
methods may support this."

In third paragraph of section 1:
"specific authenticaiton mechanism(s) to be used" =>
"specific authentication method to be used"

"some or all methods and users" => "some or all methods and peers"

Last paragraph of Section 2.1 "Without or associated..." should be
moved to section 7.8 after the last paragraph there.

Section 3.2

"Authentication- Protocol" => "Authentication Protocol"
"back- end server" => "backend authentication server"

Section 3.2.1

"the EAP Authentication Protocol" => "EAP"

"PPP Extensible Authentication Protocol" => "Extensible Authentication
Protocol"

Section 3.4

Last paragraph "In IEEE 802.11 a..." should be moved to after the last
paragraph of 7.12.

Section 2.2, figure 2:

The "!" symbols are not aligned correctly -- they need to be moved
to the right 3 spaces.

Section 4.2.1:

"Processing of success and failure" should be "Processing of
Success and Failure"

Section 5.3.2 under Identifier

"a Expanded Nak Response" => "an Expanded Nak Response"

Section 5.7, under "Vendor-Type"

"If Vendor-Id is zero" => "If the Vendor-Id is zero"

Section 8:

Please change to the following:

"This protocol derives much of its inspiration from Dave Carrel's AHA
draft as well as the PPP CHAP protocol [RFC1994]. Valuable feedback
was provided by Yoshihiro Ohba of Toshiba America Research, Jari
Arkko of Ericsson, Sachin Seth of Microsoft, Glen Zorn of Cisco
Systems, Jesse Walker of Intel, Bill Arbaugh, Nick Petroni and Bryan Payne
of the University of Maryland, Steve Bellovin of AT&T Research,
Paul Funk of Funk Software and Pasi Eronen of Nokia."

Informative References

[RFC2869] version is now 20, date is April 2003.

Appendix A.1

"a fatal error.." => "a fatal error."

"a MIC validation failures" => "a MIC validation failure"

Appendix B, please add the following paragraphs:

"o In Section 5.5, support for OTP Extended Responses [RFC2243] has been
added to EAP OTP.

o Appendix A has been added on method-specific behavior, providing
guidance on how EAP method-specific integrity checks should be
processed."

---

From: [email-masked] (Henrik Levkowetz)
Date: Mon, 28 Apr 2003 14:28:15 +0200

I'm working on the nits, most seem pretty clear-cut, but there's this
one though:

On Sat, 26 Apr 2003 13:27:42 -0700 (PDT)
Bernard Aboba <[email-masked]> wrote:
...
> Last paragraph of Section 2.1 "Within or associated..." should be

I'm not convinced it really fits much better there. Maybe it would be
just as well to remove it completely? It seems to be somewhat at odds
with what is stated in the first paragraph of 2.1

	Henrik

-- 
  The dinosaurs became extinct because they 
  didn't have a space program. - Larry Niven 

  And if we become extinct because we don't have 
  a space program, it'll serve us right! - AC Clark

---

From: [email-masked] (Bernard Aboba)
Date: Mon, 28 Apr 2003 06:50:02 -0700 (PDT)

> with what is stated in the first paragraph of 2.1

They should not be at odds -- the first paragraph talks about multiple
authentication methods within a sequence. This paragraph talks about a
choice of methods. Maybe we need to clarify that more.

I believe that the movement to the security
considerations section was requested by John Vollbrecht, and it does seem
better suited in the section devoted to that particular type of attack.

---

From: [email-masked] (Henrik Levkowetz)
Date: Mon, 28 Apr 2003 16:15:46 +0200

On Mon, 28 Apr 2003 06:50:02 -0700 (PDT)

> better suited in the section devoted to that particular type of attack.

Ok. I've done so for now. And with the other changes you've proposed in
the security considerations it seems to fit in better.

	Henrik

-- 
#        efdtt.c  Author:  Charles M. Hannum <[email-masked]>         
#       Represented as 1045 digit prime number by Phil Carmody        
#     Prime as DNS cname chain by Roy Arends and Walter Belgers       
#                                                                     
#     Usage is:  cat title-key scrambled.vob | efdtt >clear.vob       
#   where title-key = "153 2 8 105 225" or other similar 5-byte key   

dig decss.friet.org|perl -ne'if(/^x/){s/[x.]//g;print pack(H124,$_)}'