> -----Original Message----- > From: Jim Schaad [mailto:jim...@augustcellars.com] > Sent: Wednesday, February 27, 2013 5:47 PM > To: 'draft-ietf-emu-crypto-b...@tools.ietf.org' > Cc: emu@ietf.org > Subject: Comments on draft-ietf-emu-crypto-bind-02 > > Sam et al, > > You said you thought you were ready for a WGLC so I did a much more > detailed review. Lots of little things but nothing that should stop a WGLC in > my opinion. > > > 1. Keywords text should be attached to the first section of the document > and not to the abstract. > > 2. In the abstract, please keep some type of name (such as EAP) with the > RFC reference. If this text was standalone the reference would not really > work and people would not really know what the RFC was about. > > 3. I-D.ietf-emu-eap-tunnel-req has been published as RFC 6678 and the > reference should be updated. > > 4. Section #1 paragraph #3 > OLD: > An > example of the attack can happen when a peer is willing to perform > authentication inside and outside a tunnel. > NEW: > An example of the attack can happen when a peer is willing to use the same > EAP method to perform authentication inside and outside of a tunnel. > > After all, the tunnel is a method of authentication. > > 5. On the ASCII art - I could clean this up between now and the next IETF if > neither of your co-authors are willing to do so. > > 6. Section #1 last paragraph. I am not sure that it is sufficient for the server > to have this policy by itself. It is necessary that both the server and the peer > have the common policy and enforce it. In this case the server may only be > offering the inner method inside of the tunnel but if the peer will allow it to > be run outside of the tunnel it does not matter. > > 7. Section #2 para #1 - Prior to channel bindings, peers could not > distinguish one Network Access Service (NAS) from another, so attacks > where one NAS impersonated another were out-of-scope. > > I suggest s/distinguish/reliably distinguish/ > > 8. In section #3 para #1 - This sentence exists In this attack, one party adds a > layer of tunneling such > that from the perspective of the EAP peer, there are more methods > than from the perspective of the EAP server. > > I don't understand the intent of the sentence. From the example above > there was no additional EAP methods being added that I could see. I can see > the addition of the tunneling, but it is not clear why there are more methods > > 9. In section 3.2.1 - Potental additional challenge to be added to para #2 > It is not always obvious that a provided certificate is intended for EAP tunnel > authentication rather than for some other purpose (such as doing HTTP over > TLS). > > 10. In section 3.2.1 - Counter argument on section #3 should be added: > > On the other hand, not using commercial CAs can be problematic for users > who are trying to use kiosk type access points. Users may be able to > remember a user name and a password but are probably not going to be able > to correctly provide the necessary validation information for a private CA. > The use of commercial CAs in this case is also problematic as the user will > probably not be able to provide the machine name of the tunnel provider > either. > > 11. Comment " Please view in a fixed-width font such as Courier." Should be > removed > > 12. Section 3.2.2 - I think that the conversion of EAP methods is sufficiently > significant that it merits it's own section in the text. Where it is does not > make it follow nicely. Not sure why it is under server policy rather than > standing on its own. > > 13. Section 3.2.3 - The last sentence should say "when the inner method is a > key deriving EAP method". > > 14. Section 3.2.4 - Current text is "insert intermediates between the peer > and the EAP server." As the NAS sits between the peer and the EAP server > this is not a reasonable statement. I might try "split the EAP server into the > tunnel EAP server and the inner EAP server(s)." > > 15. Section 3.2.4 - In point #3 - does it need to depend on the MSK and the > EMSK or only on the EMSK? TEAP will depend on only the EMSK and not the > MSK if one is available and usable. > > 16. Section 3.2.4 - Given the text "If EMSK-based cryptographic binding is an > optional facility, the > negotiation of whether to use it MUST be protected by the inner MSK > or EMSK." > a) I don't understand the requirement > b) Do you believe that TEAP meets this requirement? > If I understand the sentence correctly I believe that TEAP does not meet this > requirement as the negotiation would be fully available to anyone who could > get into the tunnel. However the negotiation is protected by the tunnel > itself. > > 17. Section 6 - I don't really care for the security considerations at present. > > It seem to be rather perfunctorily written. Minimum things that I think I > would include here > > Traditionally, the primary focus of EAP has been to authenticate a peer to a > server in order to allow access to a network. With the advent of other types > of NAS services, such as are provide by ABFAB, it becomes more important > that the EAP peer be able to get information from the EAP server about the > network and its environments. This imposes new security requirements on > the EAP protocol such as a need for mutual authentication and a stronger > need to prevent MITM attacks on the authentication. > > This memo presents some of the attacks that are possible and provides a > number of recommendations for operators and protocol developers to > follow in order to prevent the attacks presented. The most significant of > these are to use tunnel methods and to use appropriate channel binding > methods within the tunnel methods. > > 18. Section 7 - review for additional people you might want to acknowledge. > Also - capitalize Margaret. > > Jim
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
