Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods
Note: This ballot was opened for revision 14 and is now closed.
(Ron Bonica) No Objection
(Stewart Bryant) No Objection
Benoit Claise No Objection
Comment (2012-04-26 for -14)
Just happy that there is an "Operations and Management Considerations" section. It makes sense in many documents, IMHO. Thanks for that. Regards, Benoit.
(Ralph Droms) No Objection
Comment (2012-04-25 for -14)
Minor editroial nit: the affiliation for T. Clancy in the header should be fixed.
(Wesley Eddy) No Objection
(Adrian Farrel) (was Discuss) No Objection
Comment (2012-05-14 for -15)
Thanks for addressing my Discuss and Comments
Stephen Farrell (was Discuss) No Objection
Comment (2012-04-26 for -15)
1) The secdir review  has resulted in some changes that are already agreed and some that are being chatted about between reviewer and wg chair. This is just a discuss to hold things while that happens. (Not all the review comments are DISCUSS level, but a few are. We can figure out which if we get stuck on some if that's ok.)  http://www.ietf.org/mail-archive/web/secdir/current/msg03271.html 2) Does this really work with ERP? Seems like it'd add more roundtrips, e.g. making ERP-AAK pointless. 3) Why can't the authenticator cheat on CB if the EAP method is based on symmetric crypto with a KDC like thing? In fig 1 the lying NAS could mess with i1 as sent from peer to server. Why not? 4) Does including attributes that were validated in the CB failure message not expose the server to someone probing the server's policy? E.g. the lying NAS could play about until it knows what cheating is possible? 5) What does "MAY be defined" mean in 7.1? By whom? Where? Does that need to be here? 6) What does "as thorough of a validation as possible" mean in section 8? That doesn't seem to be testable. 7) Is "typically contains" enough for User-Name protection if EAP method identity protection is employed? I expected to see a MUST there. 8) Is A.3 correct? If the selected method is breakable (if not why bid down to it?) then the bad NAS can probably change the i1 message so I'm not convinced by this argument. nits: - p10 - rfc5296bis is in IESG Evaluation, and obsoletes 5296 so you should update the reference - p11 - knowing that the client is using layer 2 crypto doesn't seem very compelling if concerned about a bad NAS, since its the often the case that the putative bad NAS that can see the plaintext, it could leak that back over the air in clear if it wanted. (Liable to be detected, but then so might lack of layer2 crypto in the client UI.) - p22 - the NAS identifier can expose the user's location, depending on how those are named and whether confid. is available for the peer/server i1 or i2 message. That might be worth a mention.
Brian Haberman No Objection
(Russ Housley) No Objection
Comment (2012-04-22 for -14)
The Gen-ART Review by Francis Dupont on 7-Apr-2012 raised quite a few editorial comments. The authors have indicated that many of them are very useful, and they want to update the document to address them, but this has not happened as yet.
Barry Leiba No Objection
Comment (2012-04-24 for -14)
-- IANA Considerations -- The definitions for the two new EAP Channel Binding Parameters sub-registries specify numbers in column one of the tables, but do not specify a range for those numbers. Is it 0-255 (one byte)? Something else? Please specify, so IANA (and the rest of us) knows. Similarly for the new sub-registry in 11.1. I would like to see a brief rationale for the choices of Standards Action and IETF Review for the registration policies for the two new parameters sub-registries. See draft-leiba-iana-policy-update if you want to see where I'm coming from on this. Just something brief that shows that it was considered and discussed, and that explains why these were chosen. Note: the definition for the new registry in 11.1 does give a rationale; thanks.