Re: [secdir] Updated secdir review of draft-ietf-emu-chbind-15.txt

[Sam Hartman <[e-mail]>]

>>>>> "Stephen" == Stephen Hanna <[e-mail]> writes:

    Stephen> The changes in draft-ietf-emu-chbind-15.txt satisfactorily
    Stephen> address almost all of the comments in my April 13, 2012
    Stephen> secdir review. I do have one remaining substantive comment
    Stephen> on this latest draft and two non-substantive ones.

    Stephen> Substantive Comment -------------------

    Stephen> The last paragraph of section 9.1 points out a security
    Stephen> problem with implementing channel bindings using EAP tunnel
    Stephen> methods. If the EAP tunnel method terminates on the
    Stephen> authenticator, the channel bindings can easily be defeated
    Stephen> by the authenticator. While that's true, nobody terminates
    Stephen> the EAP tunnel method on the authenticator today. In the
    Stephen> EAP model, the authenticator is not trusted so terminating
    Stephen> the EAP tunnel method on the authenticator is a bad idea
    Stephen> for many reasons. For example, the authenticator would then
    Stephen> have the ability to bypass protected result indications and
    Stephen> to bypass all the cryptographic protections provided by the
    Stephen> tunnel.  Sometimes there is value in having the inner and
    Stephen> outer methods terminate on different servers but both
    Stephen> servers must be trusted.  The authenticator is not. So
    Stephen> there is no big security hole here, unless you have already
    Stephen> opened an enormous security hole. It's ironic that this
    Stephen> document which attempts to close vulnerabilities caused by
    Stephen> malicious authenticators ends up subtly suggesting that
    Stephen> people open a much larger vulnerability!

    Stephen> I would recommend deleting the end of this paragraph,
    Stephen> starting with the sentence that starts "Even when
    Stephen> cryptographic binding".>

I disagree very strongly with this proposed change.  It's possible that
the text is not clear and I'd be happy to work for a round or two to see
if we can clarify the text, but ending the paragraph as you propose
would defeate the point of text we added after a WG consensus call.

I agree with you that authenticators are not trusted.
The issue is that you cannot trust attackers to act within a
specification.
If an attacker can gain benefit from doing something, they may do so.

So, if an attacker can create a tunnel terminating at an authenticator
and gain advantage from doing so, then they will do so.

Remember that we're talking about crypto binding. If crypto binding is
relevant for confirming there are no extra servers, then we're in a
threat model space where we're trusting the inner method to authenticate
the server, not the outer method.  You can't say "you should only
establish trusted tunnels," because we're hoping that crypto binding
will give us that trust.  So, the issue here is that once you add
channel bindings and the associated changes to the threat model to EAP,
an authenticator can gain advantage through convincing a client to trust
a tunnel that terminates at an authenticator.  That is, an authenticator
can mount an attack.  Yes, the authenticator needs to convince the peer
to trust the extra tunnel. However, as I discuss in
draft-hartman-emu-mutual-crypto-binding and in my presentation at last
IETF, that's often fairly easy.

So, how can we make the text more clear?