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
