Subject: [Nea] Asokan attack

From: Stephen Hanna <[email-masked]>
Date: Fri, 2 Jul 2010 16:01:54 -0400

At the last NEA WG meeting (IETF 77), we agreed that the
next step was an email discussion of the Asokan attack.
Let's start that discussion. Sorry for the delay.

The basic questions seem to be:

1) What is the Asokan attack?

2) Do we need to address the Asokan attack in NEA WG?

To answer question 1, I suggest that people read the
paper that first described the Asokan attack. I recommend
this version, which is clearer than the earliest version:

N. Asokan, Valtteri Niemi, Kaisa Nyberg, "Man in the Middle
in Tunneled Authentication Protocols", published in
Security Protocols: 11th International Workshop, Cambridge,
UK, LNCS 3364 pages 28-41, Springer, available from
http://asokan.org/asokan/research/tunnel_extab_final.pdf

Once you have read that paper, you should understand how
an Asokan attack works and why it's so important to
employ countermeasures against such an attack. If you
want to see a more elementary discussion of the topic,
read the first two pages of the attached document. If
you still have questions, please raise them on this thread.

Then we move on to question 2: Do we need to address the
Asokan attack in NEA WG? The answer is clearly yes. Any
time you are running an inner protocol inside a tunnel
protocol and you want to make sure those two protocols
terminate on the same machine, you must protect against
Asokan attacks.

For NEA, we run PA in PB in PT and PT often involves an
inner protocol running over a tunnel protocol. We need
to make sure all those protocols are terminating on the
same endpoint. Otherwise, an attacker can terminate the
inner protocols on a compliant endpoint and the outer
ones on a non-compliant endpoint. The NEA server will be
none the wiser and will end up believing that the non-
compliant endpoint is OK. So we do need to protect
against the Asokan attack.

I hope that this email clarifies what the Asokan attack
is and why we need to protect against it in NEA WG. If
you have questions or comments, please respond to this
email and we'll discuss this on the NEA list.

Thanks,

Steve

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 6 Jul 2010 14:20:51 -0700

>you still have questions, please raise them on this thread.

The attached document uses different terminology than is used in the Asokan paper and the EMU documents. In specific, it talks about logging into servers, which is not what EAP is about. NEA has the concept of connecting to the PB, but even that isn't really logging in to the server. The point of NEA is to be able to access (not log into) a network. In the attached document, SpyServer and CorpServer are RADIUS servers giving login information, not servers that are being logged into.

>Asokan attack in NEA WG? The answer is clearly yes.

Fully agree.

--Paul Hoffman, Director
--VPN Consortium

---

From: Stephen Hanna <[email-masked]>
Date: Wed, 14 Jul 2010 09:24:28 -0400

Paul,

Sorry about the terminology issue in my NEA Asokan paper.
As noted in the first paragraph of the Introduction section,
CorpServer and SpyServer are RADIUS servers. For simplicity,
the EAP authenticator and NEA Server are collocated there
for the purposes of this example. The term "login" in this
document was intended to cover all phases of EAP authentication,
including the NEA assessment. Still, I can see how the phrase
"login to CorpServer" might be interpreted to mean an application
layer login. I have removed that phrase from the attached
update to my NEA Asokan explanation.

I'm glad that you were able to overcome this wording issue
and arrive at an answer to question 2, affirming that we
should address the Asokan attack in NEA WG.

I encourage others to contribute to this discussion by email
and at the NEA WG meeting in Maastricht. We should settle this
matter promptly so that we can continue our work.

Thanks,

Steve

> -----Original Message-----
> From: Paul Hoffman [mailto:[email-masked]]
> Sent: Tuesday, July 06, 2010 5:21 PM
> To: Stephen Hanna; [email-masked]
> Subject: Re: [Nea] Asokan attack
> 
> The attached document uses different terminology than is used in the
> Asokan paper and the EMU documents. In specific, it talks about logging
> into servers, which is not what EAP is about. NEA has the concept of
> connecting to the PB, but even that isn't really logging in to the
> server. The point of NEA is to be able to access (not log into) a
> network. In the attached document, SpyServer and CorpServer are RADIUS
> servers giving login information, not servers that are being logged
> into.
>

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 16 Jul 2010 16:34:49 -0700

Hi Steve,

Thanks for the document, it helps somewhat, but I still have a few
questions.

1. The original Asokan attack is a network based attack where the
attacker has control over the communication media, but not over the end
hosts.  The NEA Asokan attack is modification to this attack that
introduces compromised hosts.  From what I understand it involves the
following:

1. Attacker control of the communication media
2. A host laptop that is compromised and under the control of an
attacker
3. An NEA server that is compromised and under the control of an
attacker

Is this correct?  It seems that the compromise of these two elements in
the system is a serious thing, what other attacks are possible?  

More information on the assumptions of the hosts compromise would help
to determine if and how it should be protected against.

2.  The proposed solution does not appear to solve this problem.  The
Diffie-Hellman exchange is an anonymous exchange, the spy server can
control the Diffie-Hellman key.  A man in the middle can easily insert
themselves into this conversation just as they had inserted themselves
in the outer tunnel.  The Diffie-Hellman is just adding more computation
between the same parties at the PT layer, this does not add any
additional protection.  What am I missing?

Cheers,

Joe

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Stephen Hanna
> Sent: Friday, July 02, 2010 1:02 PM
> To: [email-masked]
> Subject: [Nea] Asokan attack
> 
> At the last NEA WG meeting (IETF 77), we agreed that the next step was
an
> email discussion of the Asokan attack.
> To answer question 1, I suggest that people read the paper that first
> described the Asokan attack. I recommend this version, which is
clearer
> than the earliest version:
> 
> N. Asokan, Valtteri Niemi, Kaisa Nyberg, "Man in the Middle in
Tunneled
> Authentication Protocols", published in Security Protocols: 11th
> International Workshop, Cambridge, UK, LNCS 3364 pages 28-41,
Springer,
> available from
> 
> Once you have read that paper, you should understand how an Asokan
attack
> works and why it's so important to employ countermeasures against such
an
> attack. If you want to see a more elementary discussion of the topic,
read
> the first two pages of the attached document. If you still have
questions,
> please raise them on this thread.
> 
> Then we move on to question 2: Do we need to address the Asokan attack
in
> NEA WG? The answer is clearly yes. Any time you are running an inner
> protocol inside a tunnel protocol and you want to make sure those two
> protocols terminate on the same machine, you must protect against
Asokan
> attacks.
> 
> For NEA, we run PA in PB in PT and PT often involves an inner protocol
> running over a tunnel protocol. We need to make sure all those
protocols
> are terminating on the same endpoint. Otherwise, an attacker can
terminate
> the inner protocols on a compliant endpoint and the outer ones on a
non-
> compliant endpoint. The NEA server will be none the wiser and will end
up
> believing that the non- compliant endpoint is OK. So we do need to
protect
> I hope that this email clarifies what the Asokan attack is and why we
need
> to protect against it in NEA WG. If you have questions or comments,
please
> respond to this email and we'll discuss this on the NEA list.
> 
> Thanks,
> 
> Steve

---

From: Stephen Hanna <[email-masked]>
Date: Sat, 17 Jul 2010 19:30:55 -0400

Joe,

Good questions. Let me address them.

On your question 1, you're right in some respects but not in others.

Yes, the Asokan attack for NEA does introduce a compromised host
into the equation. Since the purpose of the NEA protocols is to
assess endpoint compliance with policy, a natural attack against
these protocols is one that allows a non-compliant endpoint
(especially a compromised one) to masquerade as a compliant endpoint.

So certainly it's true that a precondition for the Asokan attack
on NEA is for the attacker to have compromised a trusted endpoint.
Looking at Figure 3 in the document that I sent in my last email,
the attacker has compromised CorpLaptop and wishes to fool CorpServer
(the corporate NEA Server) into believing that CorpLaptop is not
compromised (compliant). 

However, I don't agree with the other preconditions that you gave
for the Asokan attack on NEA. Looking at Figure 3 again, we'll see
that the only corporate item compromised by the attacker is CorpLaptop.
Yes, the attacker needs to set up his own equipment (SpyLaptop,
SpyAP, and SpyServer) somewhere on the Internet. But that's not
terribly difficult and doesn't require the compromise of any other
corporate asset, just CorpLaptop.

Your question 2 gets into the question of how PT should address Asokan
attacks and whether PT-EAP does a good job of doing so. I had purposely
avoided this question in my document because I thought we first wanted

> 2) Do we need to address the Asokan attack in NEA WG?

If we have answered those questions well enough, I'm glad to move on to
the question of HOW we should address the Asokan attack on NEA. This is
a rather complex question and further diagrams may be necessary to
explain and explore all aspects of the proposed solution. However,
I'll try to give a simple answer using the diagrams we have. If that
doesn't suffice, I'll create another explanatory document for this.

To discuss question 2, let's refer to Figure 4 in the document that
I previously sent. I think you're saying that if the inner EAP method
only uses an anonymous Diffie-Hellman exchange to establish the Method
Key, that won't protect against the Asokan attack on NEA. I agree. The
attacker can defeat such a protocol by having SpyServer terminate the
inner EAP method and forward the PB messages inside to CorpLaptop,
which will forward them into its inner EAP method with CorpServer.
Since CorpLaptop will be terminating the inner and outer EAP methods,
it will know the TK and MK used by CorpServer and can therefore derive
the CTK and the MSK and EMSK, etc. Let's call this a PB forwarding attack.

In TCG, we address the PB forwarding attack by having a Posture Collector
on SpyLaptop that sends the DH value to the TPM which hashes the DH with
the platform measurements (which are a hash of the security-critical
software on the machine), signs those, and sends them in a PA message
(which gets wrapped in a PB message). Let's call that PA message the DH
confirmation message.

CorpLaptop can't use a PB forwarding attack because the DH confirmation
message from SpyLaptop would reference a different DH value. CorpLaptop
can't create its own DH confirmation message with its own DH value
because the platform measurements from the TPM on CorpLaptop would show
the infection on the machine. It can't fabricate a DH confirmation message
with software because the message must be signed by a valid TPM and the
TPM will insist on including accurate platform measurements. And CorpLaptop
can't make the DH values on the two inner EAP methods match because the
software on SpyLaptop and CorpServer is uncompromised.

I won't argue that this is the only way to solve this problem. There may
well be others. I'll just argue that this is one reasonable way to solve
this problem. In fact, it's in use today in several shipping products.
So unless you can point out a flaw in the solution, this shows that there
are reasonable ways to address the Asokan attack on NEA.

Does that answer your question 2?

Thanks,

Steve

> From: Joseph Salowey (jsalowey) [mailto:[email-masked]]
> Sent: Friday, July 16, 2010 7:35 PM
> Subject: RE: [Nea] Asokan attack
> 
> Hi Steve,
>

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Sun, 18 Jul 2010 22:11:39 -0700

I think you make a good suggestion to focus on the first issue first.  

Your clarification helps.  From your description I understand the
CorpLaptop is compromised and under control of an attacker.  The
compromise is such that it is sending its NEA information to an
unauthorized server, yet it still has valid NEA assessment.  

Given this it's not clear to me why the SpyLaptop cannot be compromised
in a similar fashion and present a valid NEA assessment to the
CorpServer.  In other words, it seems that the NEA assessment should
check to make sure that the Laptop is configured to correctly authorize
the server it is presenting its NEA information to.  If the Laptop can
lie about this, then why can it not lie about other information as well?

Thanks,

Joe

> From: Stephen Hanna [mailto:[email-masked]]
> Sent: Saturday, July 17, 2010 4:31 PM
> To: Joseph Salowey (jsalowey); [email-masked]

---

From: Stephen Hanna <[email-masked]>
Date: Tue, 20 Jul 2010 00:53:04 -0400

Before I answer your question, I'd like to make sure that we're

> unauthorized server, yet it still has valid NEA assessment.

I'm not sure what you mean by "valid" here. If you mean that the
infected/compromised CorpLaptop is able to send a NEA assessment of
itself that can convince CorpServer that CorpLaptop complies with
policy, that's not correct. If CorpLaptop could do that, there would
be no need for the Asokan attack or anything. The infection on
CorpLaptop would just wait until it gets on the network and then
spread or do whatever nasty thing it wants to do. So let's assume
that CorpServer is using some form of endpoint assessment that can
detect infected machines. In that case, CorpLaptop can't send a
NEA assessment that will convince CorpServer that CorpLaptop is
compliant.

If you mean something else by the word "valid" here, my apologies.
Maybe you meant "well-formed" or something.

Maybe you just mixed up CorpLaptop and SpyLaptop in your question.
I think we're referring to Figure 3 in the document that I sent out.

Once we've straightened out this confusion, I'll be glad to address
your question if you still have one.

Thanks,

Steve

> Sent: Monday, July 19, 2010 1:12 AM
> > > Is this correct?  It seems that the compromise of these two
> elements
> in
> > > > From: [email-masked] [mailto:[email-masked]] On
> Behalf
> Of
> > > > Stephen Hanna
> > > > At the last NEA WG meeting (IETF 77), we agreed that the next
> step
> > > was
> > > an
> > > > compliant endpoint. The NEA server will be none the wiser and
> will
> > > end
> > > up
> > > > I hope that this email clarifies what the Asokan attack is and
> why
> we
> > > need

---

From: Stephen Hanna <[email-masked]>
Date: Tue, 20 Jul 2010 00:53:04 -0400

Thanks,

Steve

---

From: Stephen Hanna <[email-masked]>
Date: Tue, 20 Jul 2010 00:53:04 -0400

Thanks,

Steve