Subject: [Emu] Review - draft-ietf-emu-crypto-bind-00.txt

From: "Jim Schaad" <[email-masked]>
Date: Fri, 28 Sep 2012 13:27:52 -0700

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: [email-masked] [mailto:[email-masked]] On Behalf Of
> Jim Schaad
> Sent: Tuesday, September 25, 2012 9:11 PM
> To: [email-masked]
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu