State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator

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

(Margaret Cullen) Yes

(Steven Bellovin) No Objection

(Ted Hardie) No Objection

Comment (2004-04-27 for -)
No email
send info
In 4.2, the draft uses the following example:

  (for instance, it has invalid MIC, this case should never occur, and the method 
  treats MIC failures as non-fatal)

and later, a related example in 5.2:

  (e.g. it has invalid MIC, and this case should never occur)

MIC is not defined in this draft.  I also found this wording a bit hard to follow,
especially in the first case.  "This would arise when:  1) .. 2)...  3)" might be
a little bit better, but it is not really easy to make work in a parenthetical
example.  If the authors don't see better language, this would be okay,
but they might think about it to see if something clearly strikes them.

(Russ Housley) No Objection

Comment (2004-04-28 for -)
No email
send info
I think that the security considerations should say that an accurate state
  machine can help reduce implementation errors.  While the EAP document
  remains the normative protocol description, this state machine ought to
  help in this regard.

(David Kessens) No Objection

(Jon Peterson) No Objection

(Alex Zinin) No Objection

(Scott Hollenbeck) Abstain

Comment (2004-04-27 for -)
No email
send info
This document contains a fairly detailed API description, including method and variable names, in addition to the WG-chartered state machine.  It thus seems to contain a lot of detail that could be considered implementation-specific, though the abstract does state that "Implementations may achieve the same results using different methods".