Subject: [Emu] I-D Action: draft-ietf-emu-chbind-15.txt

From: [email-masked]
Date: Mon, 14 May 2012 12:06:42 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the EAP Method Update Working Group of the IETF.

	Title           : Channel Binding Support for EAP Methods
	Author(s)       : Sam Hartman
                          T. Charles Clancy
                          Katrin Hoeper
	Filename        : draft-ietf-emu-chbind-15.txt
	Pages           : 33
	Date            : 2012-05-14

   This document defines how to implement channel bindings for
   Extensible Authentication Protocol (EAP) methods to address the lying
   Network Access Service (NAS) as well as the lying provider problem.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-emu-chbind-15.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-emu-chbind-15.txt

The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-emu-chbind/

---

From: Sam Hartman <[email-masked]>
Date: Mon, 14 May 2012 15:10:25 -0400

This version includes a large number of changes mostly to respond to the
secdir review.

I'm not entirely sure that Stephen Hanna will be happy with the changes
in section 9, but I'd like to start there and see where we are.  I think
it's a good idea for WG members to review these changes.

---

From: Joe Salowey <[email-masked]>
Date: Tue, 15 May 2012 07:59:32 -0700

Please respond on the list by May 25, 2012.

Thanks,

Joe

On May 14, 2012, at 12:10 PM, Sam Hartman wrote:

> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu

---

From: [email-masked]
Date: Wed, 16 May 2012 10:00:13 +0800

Hi，all

 In section 9.1 ， “One attractive implementation strategy for channel 
binding is to add
   channel binding support to a tunnel method which can tunnel an inner
   EAP authentication.”was expected to introducing implementing channel 
binding on tunnel,
  but was sudden to turn to cryptographic binding by "" Tunnel methods 
sometimes use
   cryptographic binding," and began on weakness of tunnel method with 
cryptographic binding,
   especially on a specific (or typical) implementation with MSK.

 In my opinion, these are two different topic, better in separate 
paragraghs;
 and the first topic needs some explanation, pros and cons, why not adopt 
that implementation 
since it is attractive.

Also, on tunnel method with channel binding, I think there is some point 
unclear.

According to

section  4.2 "The channel bindings MUST be transported with integrity 
protection
   based on a key known only to the peer and EAP server. " 
section 6  "The channel binding protocol defined in this document must be 
transported 
after keying material has been derived between the EAP peer and server, 
and before the peer would 
suffer adverse affects from joining an adversarial network."

To my understanding, channel binding exchange happens 
after a MSK is derived  between EAP peer and EAP server,
and before MSK is transported to authenticator. 

If not, for example, after MSK is transported to authenticator,
of course  authenticator can control the channel binding exchange.

I think that is why the EAP cryptograhic binding draft was put forward.
If it is made clear and MUST that " MSK transportation to authenticator" 
happens 
after channel binding exchange finishes, I don't think an extra crypto 
binding is necessary.

and to make it clear， I suggest EAP server transport MSK after it has 
obtained explicit response 
from EAP peer to authorize the action.

Regards~~~

-Sophia, Sujing Zhou

Joe Salowey <[email-masked]> 
发件人:  [email-masked]
2012-05-15 22:59

收件人
[email-masked]
抄送
Sam Hartman <[email-masked]>
主题
Re: [Emu] I-D Action: draft-ietf-emu-chbind-15.txt

Thanks,

Joe

---

From: Sam Hartman <[email-masked]>
Date: Wed, 16 May 2012 08:26:40 -0400

>>>>> "zhou" == zhou sujing <[email-masked]> writes:

    zhou> Hi all

    zhou>  In section 9.1 One attractive implementation strategy for
    zhou> channel binding is to add channel binding support to a tunnel
    zhou> method which can tunnel an inner EAP authentication.  was
    zhou> expected to introducing implementing channel binding on
    zhou> tunnel, but was sudden to turn to cryptographic binding by ""
    zhou> Tunnel methods sometimes use cryptographic binding," and began
    zhou> on weakness of tunnel method with cryptographic binding,
    zhou> especially on a specific (or typical) implementation with MSK.

    zhou>  In my opinion, these are two different topic, better in
    zhou> separate paragraghs; and the first topic needs some
    zhou> explanation, pros and cons, why not adopt that implementation
    zhou> since it is attractive.

I appreciate your desire to analyze the proes and cons of of tunnel
methods.
I'm nervous about expanding the scope of this document to do that
because I believe it would add delay. Also, I'm confused about whether a
general discussion of tunnel methods and channel bindings belongs in the
security considerations section of this document.

The explicit structure of
that paragraph was called out for WG review prior to IETF last call;
also that structure was present in IETF last call.  I do not wish to
wait to reach consensus on general comments about proes/cons of
implementing channel binding with tunnel methods prior to approval of
this document.

Thus I prefer the current text.

    zhou> Also, on tunnel method with channel binding, I think there is
    zhou> some point unclear.

    zhou> According to

    zhou> section 4.2 "The channel bindings MUST be transported with
    zhou> integrity protection based on a key known only to the peer and
    zhou> EAP server. " section 6 "The channel binding protocol defined
    zhou> in this document must be transported after keying material has
    zhou> been derived between the EAP peer and server, and before the
    zhou> peer would suffer adverse affects from joining an adversarial
    zhou> network."

    zhou> To my understanding, channel binding exchange happens after a
    zhou> MSK is derived between EAP peer and EAP server, and before MSK
    zhou> is transported to authenticator.

Channel binding can happen before or after the MSK is generated, but
effectively needs to happen after some key is generated.

    zhou> If not, for example, after MSK is transported to
    zhou> authenticator, of course authenticator can control the channel
    zhou> binding exchange.

I would expect that the key used for channel binding integrity would be
cryptographically independent of the MSK.
I've not analyzed a method where the MSK is used for channel binding but
this is done prior to transport to the authenticator.
That's probably safe, but it seems like a bad design strategy because it
seems needlessly fragile.
So, I'd be nervous about that strategy and would recommend independent
keys for channel binding.

    zhou> I think that is why the EAP cryptograhic binding draft was put
    zhou> forward.  If it is made clear and MUST that " MSK
    zhou> transportation to authenticator" happens after channel binding
    zhou> exchange finishes, I don't think an extra crypto binding is
    zhou> necessary.

I disagree.
I'd ask you to take a look at the slides I presented at IETF 83. I think
they are more clear than draft-hartman-emu-mutual-crypto-binding at the
moment, although obviously we will update that draft in the near future
to reflect your comments and those of others.

    zhou> and to make it clear I suggest EAP server transport MSK after
    zhou> it has obtained explicit response from EAP peer to authorize
    zhou> the action.

That would be a change to existing EAP methods in some cases.
That sort of change is out of scope for draft-ietf-emu-chbind.
It's true that channel binding benefits from protected success
indications and the current draft-ietf-emu-chbind does discuss that.

---

From: [email-masked]
Date: Thu, 17 May 2012 09:04:50 +0800

> implementing channel binding with tunnel methods prior to approval of

Well，no matter what's the result, I don't like the logic in the current 
text,
it is not clear and easy to confusing the two bindings. 

> keys for channel binding.

If there is another key available, it will be great, 
EMSK? It has been suggested for cryptographic binding.

> to reflect your comments and those of others.

If EMSK is used in channel binding, is cryptophic binding using EMSK still 
neccesary?
> indications and the current draft-ietf-emu-chbind does discuss that.

If EMSK is used, then no change to existing EAP methods will be made.
That will be fine.

---

From: [email-masked]
Date: Thu, 17 May 2012 09:04:50 +0800

---

From: Sam Hartman <[email-masked]>
Date: Thu, 17 May 2012 08:46:55 -0400

>>>>> "zhou" == zhou sujing <[email-masked]> writes:

    zhou> If there is another key available, it will be great, EMSK? It
    zhou> has been suggested for cryptographic binding.

I'm expecting that most EAP methods will use a key internal to their
heirarchy above both the MSK and EMSK. For example I'd expect that
TLS-based tunnels would use the TLS integrity and confidentiality keys
for channel binding.

---

From: [email-masked]
Date: Fri, 18 May 2012 08:16:32 +0800

Regards~~~

-Sujing Zhou

> TLS-based tunnels would use the TLS integrity and confidentiality keys
what if there is not such an internal key other than MSK and EMSK for a 
EAP method?

---

From: [email-masked]
Date: Fri, 18 May 2012 12:33:57 +0800

Regards~~~

-Sujing Zhou

---

From: [email-masked]
Date: Fri, 18 May 2012 12:58:36 +0800

Regards~~~

-Sujing Zhou

---

From: Sam Hartman <[email-masked]>
Date: Fri, 18 May 2012 07:49:52 -0400

>>>>> "zhou" == zhou sujing <[email-masked]> writes:

I don't really understand how that would be possible.  If a fresh MSK
and EMSK are generated per session, which we'd expect in a good EAP
method, they need to be generated from something.  So, I'd need to
better understand what was happening if we had an EAP method that only
had an MSK and EMSK internally.

However, if that were the case I'd consider
something EMSK-based while also considering whether it really made sense
to add channel binding to that EAP method.

---

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: [email-masked]
Date: Sat, 19 May 2012 09:48:13 +0800

> outer method tunnel terminates on the authenticator".

Cann't be more agree.
The logic and goal of the last paragraph is suspicious.
It gives an impression that channel binding on tunnel method is 
not applicable just because the specific (rare) example  shown is 
no good.
What about a good crypto binding in tunnel method?

---

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:
>>>