Sam,
I see now that you are concerned not with circumstances where
the NAS terminates the tunnel by design but rather with times
when the NAS is maliciously terminating the tunnel. I'm glad
that we both agree that having the NAS terminate the tunnel
is highly undesirable. That did not come through in the draft.
I'm much relieved to learn that nobody is suggesting this
as a desirable outcome. I agree that it's an attack scenario
that must be considered and carefully addressed.
Maybe we can resolve this issue by clarifying the text to
say more clearly that we're dealing with an attack scenario
here. For example, we could add a sentence before the words
"Tunnel methods sometimes use" saying something like "However,
this is not secure if the NAS can terminate the tunnel (a
highly undesirable situation)." Then you can mention several
countermeasures against such an attack: mutual cryptographic
bindings (still just a -00 individual draft), carefully
checking the EAP server's identity, etc. We might also take
this opportunity to split this long paragraph into two:
one that includes the first three sentences (describing how
EAP tunnel methods can support channel binding) and another
describing the attack scenario and countermeasures.
Thanks,
Steve
> -Original Message-
> From: Sam Hartman [mailto:hartmans-i...@mit.edu]
> Sent: Monday, May 21, 2012 5:51 PM
> To: Stephen Hanna
> Cc: Sam Hartman; emu@ietf.org; sec...@ietf.org; i...@ietf.org
> Subject: Re: Updated secdir review of draft-ietf-emu-chbind-15.txt
> Importance: High
>
> > "Stephen" == Stephen Hanna 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
>
