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

Sean Turner <> Fri, 25 May 2012 12:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6538521F8687 for <>; Fri, 25 May 2012 05:57:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.213
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7S+DpFsfy5CW for <>; Fri, 25 May 2012 05:57:42 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5624221F8686 for <>; Fri, 25 May 2012 05:57:42 -0700 (PDT)
Received: by (Postfix, from userid 5007) id CA92F6AD52CCB; Fri, 25 May 2012 07:57:41 -0500 (CDT)
Received: from ( []) by (Postfix) with ESMTP id BCA7E6AD52CAA for <>; Fri, 25 May 2012 07:57:41 -0500 (CDT)
Received: from [] (port=35380 helo=thunderfish.local) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from <>) id 1SXu5M-0005cW-TS; Fri, 25 May 2012 07:57:41 -0500
Message-ID: <>
Date: Fri, 25 May 2012 08:57:40 -0400
From: Sean Turner <>
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 <>
References: <> <> <> <> <>
In-Reply-To: <>
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 -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-BWhitelist: no
X-Source-Sender: (thunderfish.local) []:35380
X-Email-Count: 4
X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20=
Cc: "" <>, Sam Hartman <>, "" <>, "" <>
Subject: Re: [secdir] [Emu] Updated secdir review of draft-ietf-emu-chbind-16.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 25 May 2012 12:57:43 -0000


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!


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:;;
>> 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 []
>>> Sent: Monday, May 21, 2012 5:51 PM
>>> To: Stephen Hanna
>>> Cc: Sam Hartman;;;
>>> 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
>>> IETF, that's often fairly easy.
>>> So, how can we make the text more clear?
> _______________________________________________
> Emu mailing list