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@xxxxxxxx; secdir@xxxxxxxx; ietf@xxxxxxxx
> 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@xxxxxxx]
> > Sent: Monday, May 21, 2012 5:51 PM
> > To: Stephen Hanna
> > Cc: Sam Hartman; emu@xxxxxxxx; secdir@xxxxxxxx; ietf@xxxxxxxx
> > Subject: Re: Updated secdir review of draft-ietf-emu-chbind-15.txt
> > Importance: High
> >
> > >>>>> "Stephen" == Stephen Hanna <shanna@xxxxxxxxxxx> 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?