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

Sean Turner <turners@ieca.com> Fri, 25 May 2012 12:57 UTC

Return-Path: <turners@ieca.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6538521F8687 for <secdir@ietfa.amsl.com>; Fri, 25 May 2012 05:57:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.213
X-Spam-Level:
X-Spam-Status: No, score=-102.213 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7S+DpFsfy5CW for <secdir@ietfa.amsl.com>; Fri, 25 May 2012 05:57:42 -0700 (PDT)
Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [69.93.179.25]) by ietfa.amsl.com (Postfix) with ESMTP id 5624221F8686 for <secdir@ietf.org>; Fri, 25 May 2012 05:57:42 -0700 (PDT)
Received: by gateway14.websitewelcome.com (Postfix, from userid 5007) id CA92F6AD52CCB; Fri, 25 May 2012 07:57:41 -0500 (CDT)
Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway14.websitewelcome.com (Postfix) with ESMTP id BCA7E6AD52CAA for <secdir@ietf.org>; Fri, 25 May 2012 07:57:41 -0500 (CDT)
Received: from [96.231.123.235] (port=35380 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from <turners@ieca.com>) id 1SXu5M-0005cW-TS; Fri, 25 May 2012 07:57:41 -0500
Message-ID: <4FBF81C4.7050503@ieca.com>
Date: Fri, 25 May 2012 08:57:40 -0400
From: Sean Turner <turners@ieca.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Stephen Hanna <shanna@juniper.net>
References: <20120514190642.11168.14882.idtracker@ietfa.amsl.com> <tslvcjy37fi.fsf@mit.edu> <AC6674AB7BC78549BB231821ABF7A9AEB82F8758EF@EMBX01-WF.jnpr.net> <tslr4udmce6.fsf@mit.edu> <AC6674AB7BC78549BB231821ABF7A9AEB82FC94472@EMBX01-WF.jnpr.net>
In-Reply-To: <AC6674AB7BC78549BB231821ABF7A9AEB82FC94472@EMBX01-WF.jnpr.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator1743.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ieca.com
X-BWhitelist: no
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: (thunderfish.local) [96.231.123.235]:35380
X-Source-Auth: sean.turner@ieca.com
X-Email-Count: 4
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20=
Cc: "secdir@ietf.org" <secdir@ietf.org>, Sam Hartman <hartmans-ietf@mit.edu>, "ietf@ietf.org" <ietf@ietf.org>, "emu@ietf.org" <emu@ietf.org>
Subject: Re: [secdir] [Emu] Updated secdir review of draft-ietf-emu-chbind-16.txt
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 May 2012 12:57:43 -0000

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:
> 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
>
>> -----Original Message-----
>> From: Stephen Hanna
>> Sent: Tuesday, May 22, 2012 4:00 PM
>> To: 'Sam Hartman'
>> Cc: emu@ietf.org; secdir@ietf.org; ietf@ietf.org
>> Subject: RE: Updated secdir review of draft-ietf-emu-chbind-15.txt
>>
>> 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-ietf@mit.edu]
>>> Sent: Monday, May 21, 2012 5:51 PM
>>> To: Stephen Hanna
>>> Cc: Sam Hartman; emu@ietf.org; secdir@ietf.org; ietf@ietf.org
>>> Subject: Re: Updated secdir review of draft-ietf-emu-chbind-15.txt
>>> Importance: High
>>>
>>>>>>>> "Stephen" == Stephen Hanna<shanna@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?
> _______________________________________________
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu
>