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

[Sean Turner <[e-mail]>]

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: [e-mail]; [e-mail]; [e-mail]
>> 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:[e-mail]]
>>> Sent: Monday, May 21, 2012 5:51 PM
>>> To: Stephen Hanna
>>> Cc: Sam Hartman; [e-mail]; [e-mail]; [e-mail]
>>> Subject: Re: Updated secdir review of draft-ietf-emu-chbind-15.txt
>>> Importance: High
>>>
>>>>>>>> "Stephen" == Stephen Hanna<[e-mail]>  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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/emu
>