Channel-Binding Support for Extensible Authentication Protocol (EAP) Methods
draft-ietf-emu-chbind-16

Thanks for addressing my Discuss and Comments

-- 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.

Just happy that there is an "Operations and Management Considerations" section. 
It makes sense in many documents, IMHO.
Thanks for that.

Regards, Benoit.

Minor editroial nit: the affiliation for
T. Clancy in the header should be fixed.

  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.

1) The secdir review [1] 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.)

   [1]
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.