Subject: [Emu] New draft on mutual crypto binding problem

From: Sam Hartman <[email-masked]>
Date: Mon, 05 Mar 2012 18:32:02 -0500

Folks, I'd like to draw your attention to a draft we've put together
describing the crypto binding interaction with channel binding and other
peer-focused EAP services that I posted back in January.  Please see
draft-hartman-emu-mutual-crypto-bind-00.txt.

there are a few rough edges. A couple of figures need to be added. we'd
also like to describe where existing tunnel methods  are in terms of
vulnerability to these issues and where inner methods are in terms of
providing keys and EMSKS.
Dacheng zhang has compiled a lot of this data but I didn't get a chance
to integrate it today.

I'd like to thank all those who have helped with this so far  and
welcome any feedback.

We'd like to request time at the EMU session to discuss this attack and
the implications for our ongoing work.

---

From: Hao Zhou <[email-masked]>
Date: Wed, 07 Mar 2012 13:13:51 -0500

Sam:

This is a well thought and well written draft, it covers a lot of background
and aspect of the attacks and mitigations. However, I have few comments:

1. I don't agree that Mutual crypto-binding is the recommended mitigation
and should be added to TEAP. I actually think proper server authentication
or server policy is better mitigation. Reasons:
A. Mutual crypto-binding required the use of EMSK, not all existing EAP
method generate and export EMSK. It will also break intermediate AAA
servers. More importantly, it would only work for an EAP method that
generates keys. Part of the goal of Tunnel Method is to protect weak
authentication or EAP method, this would not benefits them.
B. The root of the problem is a legitimate NAS acting as something it
shouldn't be. If the peer can detect that from the beginning, that will
prevent further damages such as leaking of credentials, sensitive data etc.
Thus I strong recommend we emphasize on server cert validation and introduce
the concept of authorization to the server authentication. Certain server
can be only used for the services that are authorized. If the peer is
seeking certain services and encounter a server that is not on the
authorized server offering this type of service, despite it is a legit
server for other services, it should refuse to connect to it. It's like you
don't log onto Facebook to do your bank transactions:) I don't think
Standard cert naming is enough, we need some sort of authorization built
into the cert name or a peer side policy, what service the holder can offer.
C. Adding Crypto-binding to TEAP would complicate things, we will need to
try to negotiate that and fall back to the case where inner method doesn't
generate EMSK. And it doesn't protect the methods that doesn't generate
keys.
D. Enforcing server policy would be another good way to go, if server can
demand tunnel method only, eliminate the chance of inner method MSK being
sent to the attacker.

2. I am not sure "Mutual Crypto-binding" is a good term, as the existing
crypto-binding is already mutually authenticating the peer and the server.
Maybe more accurate to be called "Crypto-binding based on EMSK" or "Extended
Crypto-binding" etc.

Some small nits:
1. In introduction, EAP RFC is 3748, not 3778.
2. In abstract, "[RFC3748]" probably should be "Cryptographic binding
defined in [RFC3748]".

On 3/5/12 6:32 PM, "Sam Hartman" <[email-masked]> wrote:

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

---

From: Sam Hartman <[email-masked]>
Date: Mon, 19 Mar 2012 15:00:52 -0400

Dear Hao:

I was pleased to hear your analysis of areas where mutual crypto binding
may be tricky to deploy because I would like to accurately describe this
problem space. I believe the draft covers most of the points you raise
but I will definitely incorporate your feedback.

I was a bit frustrated though that you proposed simply focusing on
certificate validation without responding to the concerns that the draft
raises  in that area because I put a fair bit of time into analyzing
that problem space and I was hoping to try and explain that there are no
easy answers. I hear that you are concerned about the complexity of
EMSK-based cryptographic binding; I'm guessing you'd like to make rapid
progress on your draft.

However I'm concerned  when I think we may be discarding an option like
EMSK-based cryptographic binding in favor of an option that we believe
doesn't cover a number of deployments that we've decided in our
requirements analysis are important to us.
I think both of our options have merit.
Would you be willing to get together  with me and Dacheng before the EMU
meeting to work on a design for EMSK-based cryptographic binding in your
method and to work on understanding what's required to get the most out
of certificate binding? I'd like to have a well-informed discussion
about the complexity of EMSK-based cryptographic binding, the discussion
of complexity of certificate validation and  the environments where they
can both function. I'd appreciate your help in getting to that point!
I'd also be interested in working with anyone else on this problem.

Currently I'm available Monday morning, Monday during lunch, Monday
during the first afternoon session. It also looks like I have a fair bit
of availability Tuesday.

---

From: Hao Zhou <[email-masked]>
Date: Mon, 19 Mar 2012 18:19:19 -0400

Hi, Sam:

I can meet with you and Dacheng either during Monday lunch or first
afternoon session to discuss the options. Thanks.

---

From: Sam Hartman <[email-masked]>
Date: Tue, 20 Mar 2012 15:00:57 -0400

Let's meet Monday at lunch.

We should try and get a count of interested people.