Extensible Authentication Protocol (EAP)
draft-ietf-eap-rfc2284bis-09

[Ballot comment]
I think there are many virtues to this spec, but it needs more attention to the applicability description - this is one reason that SMB has his Discuss, and the problem is epitomized by comments such as:

  Where transport efficiency is a consideration, and IP transport is
  available, it may be preferable to expose an artificially high EAP
  MTU to EAP and allow fragmentation to take place in IP.
  Alternatively, it is possible to choose other security mechanisms
  such as TLS [RFC2246] or IKE [RFC2409] or an alternative
  authentication framework such as SASL [RFC2222] or GSS-API [RFC2743].

How could the same application use GSS-API or SASL if it intended to use EAP? 
They seem to have very different domains of applicability.  It would be good to
discuss the ways that EAP is very applicable and ways in which it can be
kind of wedged into use, with results that may be only just satisfactory.

[Ballot discuss]
This document leaves me feeling very unhappy.  I'm not sure if it's the document's problems or if I'm very confused; if the latter, I'm not sure how much of that is due to a confusing document.  The terminology of "authenticator" and "peer" certainly leads to confusion.

Some specific points...

I'm not at all happy with the stress on "physical security" of links.  The concept isn't defined in terms of properties, nor is the threat model clear.  Many wired Ethernets, even switched ones, are not secure enough to meet what I believe to be the requirements here.

The option of cryptographic "security" as an alternative is very hard -- you can't do crypto without at least one end authenticating itself first.  When I'm sitting in my favorite 802.11 hotspot, how do I know if I'm authenticating (at the pre-EAP level) to the hotspot or to the laptop on the table next to me?  The implications here are that the requirements need to be spelled out much more carefully.

5.1 says that identity messages are "not protected".  Again, what are the precise security requirements for the lower layers?

5.2: there are no numeric codes, which creates internationalization problems.

[Ballot discuss]
1.  In section 4.3, paragraph [a], the document says: "These MUST
  be pseudo-random, generated by a PRNG seeded as per [RFC1750]."
  While I like RFC 1750 very much, I do not think that a MUST
  statement ought to reference it.  An informative reference is
  better in this case than a normative reference.

  2.  In section 7.2.1, the definition of 'key strength' is not
  correct.  In a perfect symmetric cipher, the brute force attack is
  the best possible attack.  That is, the attacker must attempt to
  decrypt with each possible key value until the correct one is found.
  On average, half of the key values need to be tried to locate the
  correct one to decrypt a particular ciphertext.  So, on average,
  2^(N-1) operations are needed to attack a key with N bits of
  effective strength.

[Ballot comment]
1.  Please pick one spelling and use it throughout the document:
    - either 'passthrough' or 'pass-through'
    - either 'ad-hoc' or 'ad-hoc' or 'ad hoc'

  2.  In section 1.2, please add the definition of supplicant and
  slightly revise the definition of EMSK as follows:
 
    supplicant
          The end of the link that responds to the authenticator in
          [IEEE-802.1X].  In this document, this end of the link is
          called the peer.

    Extended Master Session Key (EMSK)
          Additional keying material derived between the EAP client
          and server that is exported by the EAP method.  The EMSK is
          at least 64 octets in length.  The EMSK is not shared with
          the authenticator or any other third party.  The EMSK is
          reserved for future uses that are not defined yet.

  3.  In section 1.3, I find the last sentence of the 4th paragraph
  awkward.  I propose the following rewording:

    As a result, it may be necessary for an authentication algorithm
    to add one or two additional messages (at most one roundtrip)
    between the client and authenticator in order to run over EAP.

  4.  In section 2.4, 1st paragraph, last sentence, the term
  'authenticatees' is introduced.  I think that 'peers' should be used
  instead.  This leads to a problem because 'peers' is used elsewhere
  in the sentence.  Proposal:

    Both ends of the link may act as authenticators and peers at
    the same time.

  5.  In section 3.2, 1st paragraph, 1st sentence: s/must/MUST/
 
  6.  In section 4.2, 7th paragraph at the top of page 25, 1st sentence,
  I cannot figure out what the sentence means:
 
    A mutually authenticating method (such as EAP-TLS [RFC2716]) that
    provides authorization error messages provides protected result
    indications for the purpose of this specification.

  7.  In section 7.11, 2nd paragraph, last sentence:
  s/recommended/RECOMMENDED/

[Note]: 'Last Call comments received, revised ID needed.  Expect -07 update to address minor issues, possible -08 update to address peer-to-peer issues.' added by Margaret Wasserman

An issue has arisen in IEEE 802.1aa about whether EAP fully
supports peer-to-peer operation.  I've filed this as Issue 204 on the EAP
WG Issues list:

http://www.drizzle.com/~aboba/EAP/eapissues.html

The issue arose as part of IEEE 802.1aa D7.1 ballot resolution.  The full
text of the issue (arising from the resolution to Comment 15) is available
here:

http://www.ieee802.org/1/files/private/x-REV-drafts/d7/802-1X-rev-d7-1-dis.pdf

Discussion is now underway in EAP WG about the nature of the problem and
what if anything needs to be done to resolve it.

[Note]: 'Last Call comments received, revised ID needed.  Expect -07 update to address minor issues, possible -08 update to address peer-to-peer issues.' added by Margaret Wasserman

Questionnaire from chairs, does not (yet) include ballot write-up information:

> Questions:
>
> 1) Have the chairs personally reviewed this version of the ID and do
>    they believe this ID is sufficiently baked to forward to the IESG
>    for publication?

Jari and I have both reviewed it.

> 2) Has the document had adequate review from both key WG members and
>    key non-WG members? Do you have any concerns about the depth or
>    breadth of the reviews that have been performed?

The WG last call notices have been forwarded to 3GPP, 3GPP2, and IEEE 802
mailing list as well as to other IETF WGs (PANA).  More review will occur
once IETF last call gets underway.

> 3) Do you have concerns that the document needs more review from a
>    particular (broader) perspective (e.g., security, operational
>    complexity, someone familiar with AAA, etc.)?

Other than encouraging further review from the above communities, no.

> 4) Do you have any specific concerns/issues with this document that
>    you believe the ADs and/or IESG should be aware of? For example,
>    perhaps you are uncomfortable with certain parts of the document,
>    or whether there really is a need for it, etc., but at the same
>    time these issues have been discussed in the WG and the WG has
>    indicated it wishes to advance the document anyway.

I have no major concerns with it.

> 5) How solid is the WG consensus behind this document?  Does it
>    represent the strong concurrence of a few individuals, with others
>    being silent, or does the WG as a whole understand and agree with
>    it?

The WG has extensively discussed this document, as documented in the
Issues list (http://www.drizzle.com/~aboba/EAP/eapissues.html).  Many
individuals have participated in that discussion and the number of issues
raised has steadily declined with time.

> 6) Has anyone threatened an appeal or otherwise indicated extreme
>    discontent?  If so, please summarize what are they upset about.

No threats of an appeal that I know of.

> 7) Have the chairs verified that the document adheres to _all_ of the
>    ID nits?  (see http://www.ietf.org/ID-nits.html).

I believe it conforms.

> 8) For Standards Track and BCP documents, the IESG approval
>    announcement includes a writeup section with the following
>    sections:
>
>    - Technical Summary
>    - Working Group Summary
>    - Protocol Quality

Will work on this once IETF last call and IESG comments are resolved.

>    - For the protocol quality, useful information could include:
>
>      - is the protocol already being implemented?

Yes.

>      - have a significant number of vendors indicated they plan to
>        implement the spec?

Yes.

>      - are there any reviewers (during the end stages) that merit
>        explicit mention as having done a thorough review that resulted
>        in important changes or a conclusion that the document was fine
>        (except for maybe some nits?)

They're already either authors or in the acknowledgements (or will be).