Subject: Updated secdir review of draft-ietf-emu-chbind-15.txt

From: Stephen Hanna <[email-masked]>
Date: Fri, 18 May 2012 18:10:19 -0400

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

Substantive Comment
-------------------

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

I would recommend deleting the end of this paragraph, starting
with the sentence that starts "Even when cryptographic binding".
If you choose to keep this strange text, I suggest that you at
least note that terminating an EAP tunnel method on the
authenticator is unusual. For example, you could add a
parenthetical comment like "(rare)" after the clause "if the
outer method tunnel terminates on the authenticator".

Non-Substantive Comments
------------------------

In the first paragraph of section 3, an extraneous numeral 3 was
somehow added to the end of the second sentence.

T. Charles Clancy's address in the Authors' Addresses section
now reads:

   T. Charles Clancy
   Virginia Tech
   Virginia Tech
   Arlington, VA  22203
   USA

The duplication of Virginia Tech should be removed from
this address.

I appreciate the hard work of the document editors to address
my many earlier comments. I hope that these new comments will
also be useful.

Thanks,

Steve

---

From: Sam Hartman <[email-masked]>
Date: Mon, 21 May 2012 17:50:57 -0400

>>>>> "Stephen" == Stephen Hanna <[email-masked]> 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?

---

From: Stephen Hanna <[email-masked]>
Date: Tue, 22 May 2012 16:00:19 -0400

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:[email-masked]]
> Sent: Monday, May 21, 2012 5:51 PM
> To: Stephen Hanna
> Cc: Sam Hartman; [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Updated secdir review of draft-ietf-emu-chbind-15.txt
> Importance: High
>

---

From: Stephen Hanna <[email-masked]>
Date: Thu, 24 May 2012 09:07:33 -0400

Sam,

Thanks for addressing my comments in draft-ietf-emu-chbind-16.txt.
I'm happy with this version. All my substantive concerns are addressed.

I do see two non-substantive issues. These can be addressed in some
future version or not at all.

1) The word "subvert" is misspelled as "subvirt" in the new text.

2) Editing Charles Clancy's address in the Authors' Addresses section
   has apparently caused the list of authors in the top right corner of
   the first page to revert to this suboptimal form:

EMU Working Group                                        S. Hartman, Ed.
Internet-Draft                                         Painless Security
Intended status: Standards Track                               T. Clancy
Expires: November 25, 2012                      Department of Electrical
                                        Engineering and Computer Science
                                                               K. Hoeper
                                                Motorola Solutions, Inc.

   As you can see, Dr. Clancy's affiliation has now changed back to
   "Department of Electrical Engineering and Computer Science". I guess
   that whatever tool you're using to create the draft must insist on
   placing the second line of each author's address on the first page.
   If that's the case, you might want to change Dr. Clancy's address to

   T. Charles Clancy
   Virginia Tech
   Department of Electrical Engineering and Computer Science
   Arlington, VA  22203
   USA

   Or perhaps you'll just have to surrender to the flawed tool and
   leave the credit for Dr. Clancy on the first page as nonsensical.

Thanks for your patience in addressing the issues that I raised.
I think the document is much better for this attention.

Take care,

Steve

> From: Stephen Hanna
> Sent: Tuesday, May 22, 2012 4:00 PM
> To: 'Sam Hartman'
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: Updated secdir review of draft-ietf-emu-chbind-15.txt
> 
> Sam,
>

---

From: Sean Turner <[email-masked]>
Date: Fri, 25 May 2012 08:57:40 -0400

Steve/Sam,

I've gone ahead and entered fixes for these two as RFC editor notes to 
ensure we won't forget them.

Thanks for working through this!

spt

On 5/24/12 9:07 AM, Stephen Hanna wrote:
>>>>>>>> "Stephen" == Stephen Hanna<[email-masked]>  writes:
>>>
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu
>