>>>>> "Stephen" == Stephen Hanna <shanna@xxxxxxxxxxx> 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?