As was pointed out to me, the subject message on the message had the wrong draft name (even if the version number was right).
I am re-posting so that searches on the subject will find the correct document for comments. Jim > -----Original Message----- > From: emu-boun...@ietf.org [mailto:emu-boun...@ietf.org] On Behalf Of > Jim Schaad > Sent: Tuesday, September 25, 2012 9:11 PM > To: emu@ietf.org > Subject: [Emu] Review - draft-ietf-emu-eap-tunnel-method-00 > > Version 0 of the document is not ready for a last call as security > considerations are missing. > > Other comments > > > 1. I think in figure #1, there would be improved clarity if the line for Pear > initiates connection to a service would have the following under the attacker > line "-->|<--" to indicate that the attacker is intercepting the traffic at this > point and forwarding it. > > 2. The last paragraph in section 1 need to be re-organized. > a) It says there are several strategies, but I can only see two that are outlined > here > b) It is not clear where the second strategy starts. That is "is the technical > solution part of the security solution". (yes I know that it is > not) > c) It is unclear if the cryptographic binding is unable to make the proof to the > peer, or if this is just not done because the peer has traditionally not cared > that it was so. > > 3. In section 2 I have a problem with the sentence "Channel bindings are > used to tell the peer which application service is being connected to." I don't > know that this is a good characterization of what is happening with channel > bindings esp with the updated RFC in process. The issue I have is that not all > of the information about the service is communicated to the peer, and the > peer is told information about the service, but still might not know what > service it is connected to. I think a better characterization might be "Channel > bindings are used to provide the peer with information about the application > service it is connecting to." > > 4. I would add an introductory sentence to paragraph #2 in section 2 to say > this is the start of an example. > > 5. In section 3.2.2 - Item #1 seems to be a hardship to get implemented and > get right. There is an easy argument that servers can have a policy > configured about what inner methods can be used, but imposing it on the > peer and making the configuration be server based can be problematic. I > think that this issue probably deserves more text. How is the configuration > updated and transferred to the peer. > > 6. In section 3.2.4 - "then condition 3" need to tell me where condition 3 is - > what section? > > 7. Missing paran " (see Section 3.3. insert" > > 8. In section 3.3 - can the intended intermediary be on the other side - that is > between the NAS and the authenticator rather than the peer and the NAS? > This is not clear from the text > > 9. In section 4.2 - there may be another piece of state tracking that should be > added. It is not enough to know that mutual authentication has occurred, it > might also be important to know who it has occurred with. Thus having > performed mutual auth with a user is different than performing mutual auth > with a machine and the operations that are allowed to take place may be > different. > > 10. Section 5, 6 and 7 appear to be completely absent in the current draft. > > Jim > > > _______________________________________________ > Emu mailing list > Emu@ietf.org > https://www.ietf.org/mailman/listinfo/emu _______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
