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
