Diameter Extensible Authentication Protocol (EAP) Application
RFC 4072

Note: This ballot was opened for revision 10 and is now closed.

(Bert Wijnen) Yes

(Harald Alvestrand) No Objection

Comment (2004-10-28 for -)
No email
send info
Reviewed by Mark Allman, Gen-ART

His review:

This one looks ready.  (From a non-expert.)

Per usual, I think it could have done a bit better job of sketching the
problem being solved.  But, it's OK.  If the doc does get rev-ed, I'd
suggest:

  * better problem description (nothing huge, but give non-experts a
    general feel)

  * spell out AVP and NASREQ the first time you use them (and, tell me
    what they are!)

  * reference PAP/CHAP

(Steven Bellovin) No Objection

(Margaret Cullen) No Objection

(Bill Fenner) No Objection

(Ted Hardie) No Objection

Comment (2004-10-25 for -)
No email
send info
In 2.8.2, the documents says:

  This situation can be difficult to avoid when Diameter proxy agents
   make authorization decisions (that is, proxies can change the
   Result-Code AVP sent by the home server).  Since the responsibility
   for avoiding conflicts lies with the Diameter server, the NAS MUST
   NOT "manufacture" EAP result packets in order to correct
   contradictory messages that it receives.  This behavior, originally
   mandated within [IEEE-802.1X], will be deprecated in the future.


Not a bid deal, but I think this document deprecates the behavior, so
the last line reads oddly.  Proposed text:

This behavior is deprecated.  Note that [IEEE-802.1X] originally mandated
this in its authentication and key management standards, but an update  
is expected.

(Scott Hollenbeck) No Objection

(Russ Housley) No Objection

Comment (2004-10-27 for -)
No email
send info
  Comments are based on SecDir review by Don Eastlake.

  In Section 2.1, at the top of page 5: I guess "bidding down attack"
  is an okay description, but this is more commonly called a 
  "downgrade attack."

  In Section 2.3, 1st paragraph: Both "Code (2)" and "Code (1)" 
  appear.  All other cases of parenthesized single digit Arabic
  numerals in this document are lengths in octets.  Here I
  believe that two different values are being discussed.

  In Section 2.4: s/an a/a/

  In Section 2.7, last paragraph: s/more more/more/

  In Section 8.1, 3rd paragraph, the ending words
  ", even if redirects are used" seem not just superfluous but
  slightly confusing.

  In Section 8.1, in first sentence of 4th paragraph, suggest
  replacing "(denial-of-service is, of course, possible)" with
  "except for denial-of-service attacks."

  In Section 8.4, 1st paragraph:
    s/EAP-Session-Key/EAP-Master-Session-Key/

  In the References, [IEEE-802.11i], this is no longer a "work in
  progress."  It received final approval on 24 June 2004.

(David Kessens) No Objection

(Allison Mankin) No Objection

Comment (2004-10-28 for -)
No email
send info
A well-prepared document.  May its users honor it.   (May they
use redirects as much as possible :)

Just one nit:   the intro of DER and DEA is confusing:
"The following Command Codes are defined in this section:"

Command-Name             Abbrev.    Code       Reference
      --------------------------------------------------------
      Diameter-EAP-Request      DER       268          3.1
      Diameter-EAP-Answer       DEA       268          3.2

Since the table then shows a single code for both, there's some surprise, only explained
later by discussing the R bit being set or not.  I suggest you help out the reader either 
by including the R bit in the table or introducing it "The following Commands are 
defined in this section".

(Thomas Narten) No Objection

(Jon Peterson) No Objection

(Alex Zinin) No Objection