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; e...@ietf.org; sec...@ietf.org; ietf@ietf.org
Subject: Re: Updated secdir review of draft-ietf-emu-chbind-15.txt
Importance: High
Stephen == Stephen Hanna sha...@juniper.net 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?
