Skip to main content

Extensible Authentication Protocol (EAP)
RFC 3748

Yes

(Margaret Cullen)
(Thomas Narten)

No Objection

(Alex Zinin)
(Bert Wijnen)
(Bill Fenner)
(Harald Alvestrand)
(Jon Peterson)
(Ned Freed)
(Steven Bellovin)
(Ted Hardie)

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

(Margaret Cullen; former steering group member) Yes

Yes ()

                            

(Thomas Narten; former steering group member) Yes

Yes ()

                            

(Alex Zinin; former steering group member) No Objection

No Objection ()

                            

(Allison Mankin; former steering group member) No Objection

No Objection (2003-12-18)
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.

(Bert Wijnen; former steering group member) No Objection

No Objection ()

                            

(Bill Fenner; former steering group member) No Objection

No Objection ()

                            

(Harald Alvestrand; former steering group member) No Objection

No Objection ()

                            

(Jon Peterson; former steering group member) No Objection

No Objection ()

                            

(Ned Freed; former steering group member) No Objection

No Objection ()

                            

(Russ Housley; former steering group member) (was Discuss) No Objection

No Objection (2003-12-16)
  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/

(Steven Bellovin; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Ted Hardie; former steering group member) No Objection

No Objection ()