Jim: Your comments were on draft-ietf-emu-crypto-bind-00.txt, not draft-ietf-emu-eap-tunnel-method?
On 9/26/12 12:10 AM, "Jim Schaad" <i...@augustcellars.com> wrote: >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
