Diameter Extensible Authentication Protocol (EAP) Application
draft-ietf-aaa-eap-10

Well except that there was one line mangled in the doc
i.e. I need (in sect 4.1.5) a s/232/2^32/
Which I have added as an RFC-Ed note.

Chwecking with Pasi if that is indeed all.

[Ballot comment]
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".

[Ballot comment]
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

[Ballot comment]
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.

[Ballot comment]
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.

IANA LAST CALL COMMENTS:
We understand this document does not create any new registries.
Upon approval of this document, the IANA will register the
following:

1 Diameter command from the Command Code namespace
4 AVPs from the AVP Code namespace
1 Diameter application from the Application Identifier namespace

All the above registrations are to go in
.

1 AVP (attribute) whose AVP Code (Attribute Type) is to
be allocated from the Attribute Type namespace
.

-----Original Message-----
From: Bernard Aboba [mailto:aboba@internaut.com]
Sent: woensdag 16 juni 2004 02:55
To: iesg@ietf.org
Subject: Comment on Diameter NASREQ, EAP, MIPv4 (fwd)


Yoshi Ohba has found an error that exists within all several Diameter
Application drafts -- Diameter NASREQ, EAP and MIPv4.  This concerns the
use of Application-IDs in those documents.

Based on the Application-ID guidelines of RFC 3588, the Diameter NASREQ,
EAP and MIPv4 documents are not permitted to allocate new Application-IDs
because no new mandatory AVPs are defined in those documents.  Re-using
Diameter Base commands will enable Diameter agents (such as
Diameter/RADIUS gateways) to operate across a range of applications with
no code changes.

Diameter EAP & NASREQ use ACR/ACA, RAR/RAA, STR/STA and ASR/ASA commands.
Diameter MIPv4 uses ACR/ACA, STR/STA and ASR/ASA commands.

Date: Sat, 15 Feb 2003 12:08:07 -0800 (PST)
From: Bernard Aboba
To: Randy Bush
cc: Bert Wijnen ,
Subject: Re: draft-ietf-aaa-eap-00.txt

Glen Zorn and Tom Hiller ripped this from the rib of NASREQ-09, but it
hasn't been revised since June 2002. I've sent several inquiries to Tom
Hiller (first author) asking when it will be revised, but haven't heard
back. So at the moment I'm not optimistic about movement on it.

Frankly, I'm not sure what's holding it up. Most of the text is a Diameter
version of RFC 2869bis, so in the hands of an good editor (know any
volunteers?) it shouldn't take more than a few months to get ready for AAA
WG last call, assuming that the keying attributes were put in a separate
document.

Not all uses of EAP require keying, so this might be possible. The keying
attributes have a dependency on the EAP Keying framework which won't be
ready until June 2003, and is likely to slip. We've also found a number of
vulnerabilities relating to keying and some careful review would be needed
to make sure they are fixed. On top of that, the keying attributes are
also the most likely to be wrapped via CMS, so you have to design them so
they will work well in that service (like making sure that the CMS package
has enough "liveness" to detect cut and past attack, provides info on the
key usage parameters and lifetimes, etc. Designing the CMS package is the
hardest part of finishing Diameter CMS; after all, CMS itself is done. So
in practice, I think that keying attributes depend on CMS, even though
there may not be a formal dependency there.