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