Subject: [Emu] Review - draft-ietf-emu-eap-tunnel-method-00

From: "Jim Schaad" <[email-masked]>
Date: Tue, 25 Sep 2012 21:10:40 -0700

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

---

From: "Hao Zhou (hzhou)" <[email-masked]>
Date: Fri, 28 Sep 2012 16:30:16 +0000

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" <[email-masked]> wrote:

>_______________________________________________
>Emu mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/emu