Subject: [Emu] Comments on draft-hartman-emu-mutual-crypto-bind

From: "Jim Schaad" <[email-masked]>
Date: Tue, 20 Mar 2012 03:21:46 -0700

Sam et al,

1. In section 1 after the Classic Tunnel Attack figure, I believe there are
three methods listed as possible mitigation strategies, however I don't
understand how the second one - a sufficiently strong inner method - could
possibly be a mitigation by itself.  The three I see are 1) Policy 2) strong
inner method 3) Cryptographic binding.

2.  In section 3.2.2 - For the more traditional MITM attack.  There is a
requirement for this defense that the internal authentication methods are
going to be able to support the cryptographic binding that you are
postulating.  If this is not true then this would not be a detectible
attack.  I think this should go into the paragraph before the diagram rather
than being (kind of) implicit in the paragraph after the figure.

3.  3.2.3 or 3.2.2 - If you had a non EAP method, and it derived a key (just
like a good EAP method).  Is there any reason why you could not do the
cryptographic binding?  Other than it is not currently defined in one of the
current tunneling methods.  One could see that it could be defined as saying
after you do this, then perform the same binding as any key deriving EAP
method would do,.

4.  Section 3.2.4 - Item #4 - did you mean that it MUST prevent an attacker
from downgrading the binding from mutual to just MSK-based?  Also if the
down grade occurs, do you still want to claim that it is still mutual if
step 4 is downgraded?  The current text implies this to me and that seems
wrong.

5.  Section 3.2.4 - last paragraph - the last sentence confuses the heck out
of me.

6. Section 4.2 - I don't understand why things like doing channel binding
require that a mutual authentication be present.  I can understand a
statement that the peer MUST have doing an adequate job of authenticating
the server, but I am less clear why the server needs to have authenticated
the client.  Thus for example I think that cryptographic binding should be
sufficient to deal with these cases.  (i.e. Tunnel is authenticated to
certificate and mutual auth is tied to the tunnel).

Jim

---

From: Sam Hartman <[email-masked]>
Date: Sun, 25 Mar 2012 08:20:12 -0400

>>>>> "Jim" == Jim Schaad <[email-masked]> writes:

    Jim> 3.  3.2.3 or 3.2.2 - If you had a non EAP method, and it
    Jim> derived a key (just like a good EAP method).  Is there any
    Jim> reason why you could not do the cryptographic binding?  Other
    Jim> than it is not currently defined in one of the current
    Jim> tunneling methods.  One could see that it could be defined as
    Jim> saying after you do this, then perform the same binding as any
    Jim> key deriving EAP method would do,.

I guess.  I don't know that key expert is really defined for the non-EAP
inners in a well-defined manner.  But yes, I think something like this
would be a good idea, although I'm not sure it is practical when
compared to just forcing EAP inner methods.

    Jim> 4.  Section 3.2.4 - Item #4 - did you mean that it MUST prevent
    Jim> an attacker from downgrading the binding from mutual to just
    Jim> MSK-based?  Also if the down grade occurs, do you still want to
    Jim> claim that it is still mutual if step 4 is downgraded?  The
    Jim> current text implies this to me and that seems wrong.

I'd love to discuss this with you in person if you're available.

    Jim> 5.  Section 3.2.4 - last paragraph - the last sentence confuses
    Jim> the heck out of me.

And everyone else; it's wrong:-)
Will propose fixes to this and other comments.

    Jim> 6. Section 4.2 - I don't understand why things like doing
    Jim> channel binding require that a mutual authentication be
    Jim> present.  I can understand a statement that the peer MUST have
    Jim> doing an adequate job of authenticating the server, but I am
    Jim> less clear why the server needs to have authenticated the
    Jim> client.  Thus for example I think that cryptographic binding
    Jim> should be sufficient to deal with these cases.  (i.e. Tunnel is
    Jim> authenticated to certificate and mutual auth is tied to the
    Jim> tunnel).

I think there's an assumption that EAP always provides peer
authentication (although sometimes to an anonymous identity, isn't
semantics fun?) so mutual auth and server auth are synonyms.

And draft-ietf-emu-chbind has required mutual auth since well before I
started working on it. I didn't re-evaluate that requirement.

    Jim> Jim

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