Subject: [Emu] FW: Comments on draft-ietf-emu-crypto-bind-02

From: "Jim Schaad" <[email-masked]>
Date: Wed, 27 Feb 2013 19:29:02 -0800

> -----Original Message-----
> From: Jim Schaad [mailto:[email-masked]]
> Sent: Wednesday, February 27, 2013 5:47 PM
> To: [email-masked]'
> Cc: [email-masked]
> Subject: Comments on draft-ietf-emu-crypto-bind-02
> 
> Sam et al,
> 
> You said you thought you were ready for a WGLC so I did a much more
> detailed review.  Lots of little things but nothing that should stop a
WGLC in
> my opinion.
> 
> 
> 1.  Keywords text should be attached to the first section of the document
> and not to the abstract.
> 
> 2.  In the abstract, please keep some type of name (such as EAP) with the
> RFC reference.  If this text was standalone the reference would not really
> work and people would not really know what the RFC was about.
> 
> 3.  I-D.ietf-emu-eap-tunnel-req has been published as RFC 6678 and the
> reference should be updated.
> 
> 4.  Section #1 paragraph #3
> OLD:
>   An
>    example of the attack can happen when a peer is willing to perform
>    authentication inside and outside a tunnel.
> NEW:
>  An example of the attack can happen when a peer is willing to use the
same
> EAP method to perform authentication inside and outside of a tunnel.
> 
> After all, the tunnel is a method of authentication.
> 
> 5.  On the ASCII art - I could clean this up between now and the next IETF
if
> neither of your co-authors are willing to do so.
> 
> 6.  Section #1 last paragraph.  I am not sure that it is sufficient for
the server
> to have this policy by itself.  It is necessary that both the server and
the peer
> have the common policy and enforce it.  In this case the server may only
be
> offering the inner method inside of the tunnel but if the peer will allow
it to
> be run outside of the tunnel it does not matter.
> 
> 7.  Section #2 para #1 - Prior to channel bindings, peers could not
>    distinguish one Network Access Service (NAS) from another, so attacks
>    where one NAS impersonated another were out-of-scope.
> 
> I suggest s/distinguish/reliably distinguish/
> 
> 8.  In section #3 para #1 - This sentence exists In this attack, one party
adds a
> layer of tunneling such
>    that from the perspective of the EAP peer, there are more methods
>    than from the perspective of the EAP server.
> 
> I don't understand the intent of the sentence.  From the example above
> there was no additional EAP methods being added that I could see.   I can
see
> the addition of the tunneling, but it is not clear why there are more
methods
> 
> 9.  In section 3.2.1 - Potental additional challenge to be added to para
#2
>   It is not always obvious that a provided certificate is intended for EAP
tunnel
> authentication  rather than for some other purpose (such as doing HTTP
over
> TLS).
> 
> 10.  In section 3.2.1 - Counter argument on section #3 should be added:
> 
> On the other hand, not using commercial CAs can be problematic for users
> who are trying to use kiosk type access points.  Users may be able to
> remember a user name and a password but are probably not going to be able
> to correctly provide the necessary validation information for a private
CA.
> The use of commercial CAs in this case is also problematic as the user
will
> probably not be able to provide the machine name of the tunnel provider
> either.
> 
> 11.  Comment " Please view in a fixed-width font such as Courier." Should
be
> removed
> 
> 12.  Section 3.2.2 - I think that the conversion of EAP methods is
sufficiently
> significant that it merits it's own section in the text.  Where it is does
not
> make it follow nicely.  Not sure why it is under server policy rather than
> standing on its own.
> 
> 13.  Section 3.2.3 - The last sentence should say "when the inner method
is a
> key deriving EAP method".
> 
> 14.  Section 3.2.4 - Current text is "insert intermediates between the
peer
> and the EAP server."  As the NAS sits between the peer and the EAP server
> this is not a reasonable statement.  I might try "split the EAP server
into the
> tunnel EAP server and the inner EAP server(s)."
> 
> 15.  Section 3.2.4 - In point #3 - does it need to depend on the MSK and
the
> EMSK or only on the EMSK?  TEAP will depend on only the EMSK and not the
> MSK if one is available and usable.
> 
> 16.  Section 3.2.4 - Given the text "If EMSK-based cryptographic binding
is an
> optional facility, the
>    negotiation of whether to use it MUST be protected by the inner MSK
>    or EMSK."
> a)  I don't understand the requirement
> b) Do you believe that TEAP meets this requirement?
> If I understand the sentence correctly I believe that TEAP does not meet
this
> requirement as the negotiation would be fully available to anyone who
could
> get into the tunnel.  However the negotiation is protected by the tunnel
> itself.
> 
> 17.  Section 6 - I don't really care for the security considerations at
present.
> 
> It seem to be rather perfunctorily written.  Minimum things that I think I
> would include here
> 
> Traditionally, the primary focus of EAP has been to authenticate a peer to
a
> server in order to allow access to a network.  With the advent of other
types
> of NAS services, such as are provide by ABFAB, it becomes more important
> that the EAP peer be able to get information from the EAP server about the
> network and its environments.  This imposes new security requirements on
> the EAP protocol such as a need for mutual authentication and a stronger
> need to prevent MITM attacks on the authentication.
> 
> This memo presents some of the attacks that are possible and provides a
> number of recommendations for operators and protocol developers to
> follow in order to prevent the attacks presented.  The most significant of
> these are to use tunnel methods and to use appropriate channel binding
> methods within the tunnel methods.
> 
> 18.  Section 7 - review for additional people you might want to
acknowledge.
> Also - capitalize Margaret.
> 
> Jim