Subject: Re: [Nea] Asokan attack

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 20 Jul 2010 09:53:24 -0700

(for some reason I did not receive this message from the list, response
below)

> Before I answer your question, I'd like to make sure that we're
> not confused on anything basic. You said:
> 
> > 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.
> 
> 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.
> 
[Joe] Yes, I think I did mix up the terms.  Let me restate using the
terms from the figure 3:

The CorpLaptop has been compromised and is under control of an attacker.
It has an invalid NEA assessment (meaning it would not pass assessment
by a CorpServer).  

The SpyLaptop has been compromised at least to the point that its
transport security is compromised in that it is  sending assessment
information to the SpyServer.   However, it does provide an NEA
assessment that will be validated by the corporate server.  

Given this it's not clear to me why the CorpLaptop cannot be compromised
in a similar fashion to the SpyLaptop 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?

> Once we've straightened out this confusion, I'll be glad to address
> your question if you still have one.
> 
> Thanks,
> 
> Steve
> 
> > -----Original Message-----
> > From: Joseph Salowey (jsalowey) [mailto:[email-masked]]
> > Sent: Monday, July 19, 2010 1:12 AM
> > To: Stephen Hanna; [email-masked]
> > Subject: RE: [Nea] Asokan attack
> >
> > 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
> >
> > > -----Original Message-----
> > > From: Stephen Hanna [mailto:[email-masked]]
> > > Sent: Saturday, July 17, 2010 4:31 PM
> > > To: Joseph Salowey (jsalowey); [email-masked]
> > > Subject: RE: [Nea] Asokan attack
> > >
> > > 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
> > > to address these more elementary questions:
> > >
> > > > 1) What is the Asokan attack?
> > > >
> > > > 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
> > >
> > > > -----Original Message-----
> > > > From: Joseph Salowey (jsalowey) [mailto:[email-masked]]
> > > > Sent: Friday, July 16, 2010 7:35 PM
> > > > To: Stephen Hanna; [email-masked]
> > > > Subject: RE: [Nea] Asokan attack
> > > >
> > > > 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
> > > >
> > > > > -----Original Message-----
> > > > > 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.
> > > > > 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
> 
> _______________________________________________
> Nea mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nea

---

From: Stephen Hanna <[email-masked]>
Date: Sat, 24 Jul 2010 19:08:09 -0400

Joe,

I apologize for the delay in my response. I've been swamped.

I understand your question. Why does SpyLaptop pass the assessment?
It should fail because it has been configured to trust SpyServer.

My answer is that many endpoints (even when configured securely)
allow the user to decide which server to trust. For example, web
browsers and wireless clients generally do this. Maybe we could
argue that this shouldn't be the case but it generally is. Therefore,
SpyLaptop will still pass the assessment. Does that help explain it?

Thanks,

Steve

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Joseph Salowey (jsalowey)
> Sent: Tuesday, July 20, 2010 12:53 PM
> To: [email-masked]
> Subject: Re: [Nea] Asokan attack
>

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Mon, 26 Jul 2010 06:48:29 -0700

> Sent: Saturday, July 24, 2010 4:08 PM
[Joe] It helps, but I consider this a failure in the transport security.
The user is a victim of a successful attack.  It is important to
maintain the security at the transport layer to prevent the disclosure
of posture data which can lead to problems beyond the Asokan attack.   I
wouldn't consider an endpoint that cannot identify the server it should
trust to be configured securely and I think this behavior should not be
recommended.  

I think you are talking about a different trust model where there is
trust at the PA layer instead of the transport layer.  This needs to be
more clearly defined.  

> > > > > a rather complex question and further diagrams may be
necessary
> > > > > well be others. I'll just argue that this is one reasonable
way
> > > > > > 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
> > > > > > > N. Asokan, Valtteri Niemi, Kaisa Nyberg, "Man in the
Middle
> > > > > > > NEA WG? The answer is clearly yes. Any time you are
running

---

From: Stephen Hanna <[email-masked]>
Date: Mon, 26 Jul 2010 10:00:29 -0400

The user of SpyLaptop is the SpyUser. They're perfectly happy
to have their laptop connect to SpyServer. So I don't think
it's accurate to say that the user is the victim of a failure
in transport layer security.

If a user chooses to connect to a particular server, that's
not a transport layer security failure. That's a user choice.
One can argue that users should not be permitted to connect
to untrustworthy machines but the fact of the matter is that
many security systems allow a user override: web browsers,
802.1X supplicants, etc. That's generally considered a
feature even though it may not be ideal from a security
perspective. I'm sure that we've all clicked through a few
certificate warnings in our time! To believe that NEA clients
won't include a user override feature would be foolish.
Users will demand it and vendors will go along.

Thanks,

Steve

> Sent: Monday, July 26, 2010 9:48 AM
> > > > > > for the Asokan attack on NEA. Looking at Figure 3 again,
> we'll
> > > see
> > > > > > > Thanks for the document, it helps somewhat, but I still
> have
> > a
> > > few
> > > > > > > questions.
> > > > > > >
> > > > > > > > International Workshop, Cambridge, UK, LNCS 3364 pages
> 28-
> > 41,
> > > > > > > Springer,
> > > > > > > > available from
> > > > > > > > attack. If you want to see a more elementary discussion
> of
> > > the
> > > > > topic,
> > > > > > > read
> > > > > > > > I hope that this email clarifies what the Asokan attack
> is
> > > and
> > > > > why
> > > > > we
> > > > > > > need

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Tue, 27 Jul 2010 06:24:08 -0700

I think the configuration desires of customers will vary from market to
market.  In some markets customers demand the capability to lock
configuration down.  Anyway, I'm sure in some cases it will be the
opposite as you mention.  In these cases I agree, that when using a
trust relationship at the PA layer, the Asokan attack needs to be taken
into account. 

Joe

> Sent: Monday, July 26, 2010 7:00 AM
> > > > > > Your clarification helps.  From your description I
understand
> > > > > infected/compromised CorpLaptop is able to send a NEA
> assessment
> > of
> > > > > I think we're referring to Figure 3 in the document that I
sent
> > > out.
> > > > authorize the server it is presenting its NEA information to.
If
> > > > > > Your clarification helps.  From your description I
understand
> > > > > > CorpServer.  In other words, it seems that the NEA
assessment
> > > > should
> > > > > > lie about this, then why can it not lie about other
> information
> > > as
> > > > > > well?
> > > > > >
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Joe
> > > > > >
> > > > > > > Yes, the Asokan attack for NEA does introduce a
compromised
> > > host
> > > > > > > into the equation. Since the purpose of the NEA protocols
> is
> > to
> > > > > > > (the corporate NEA Server) into believing that CorpLaptop
> is
> > > not
> > > > > > > compromised (compliant).
> > > > > > >
> > > > > > > However, I don't agree with the other preconditions that
> you
> > > gave
> > > > > > > SpyAP, and SpyServer) somewhere on the Internet. But
that's
> > not
> > > > > > > terribly difficult and doesn't require the compromise of
> any
> > > > other
> > > > > > > If we have answered those questions well enough, I'm glad
> to
> > > move
> > > > on
> > > > > > to
> > > > > > > I'll try to give a simple answer using the diagrams we
> have.
> > If
> > > > that
> > > > > > > only uses an anonymous Diffie-Hellman exchange to
establish
> > the
> > > > > > Method
> > > > > > > Key, that won't protect against the Asokan attack on NEA.
I
> > > > agree.
> > > > > > > on SpyLaptop that sends the DH value to the TPM which
> hashes
> > > the
> > > > DH
> > > > > > with
> > > > > > > can't create its own DH confirmation message with its own
> DH
> > > > value
> > > > > > > because the platform measurements from the TPM on
> CorpLaptop
> > > > would
> > > > > > show
> > > > > > > with software because the message must be signed by a
valid
> > TPM
> > > > and
> > > > > > the
> > > > > > > TPM will insist on including accurate platform
> measurements.
> > > And
> > > > > > > CorpLaptop
> > > > > > > > attacker has control over the communication media, but
> not
> > > over
> > > > the
> > > > > > end
> > > > > > > > Diffie-Hellman exchange is an anonymous exchange, the
spy
> > > > server
> > > > > > > > between the same parties at the PT layer, this does not
> add
> > > any
> > > > > > > > > From: [email-masked] [mailto:nea-
> [email-masked]]
> > On
> > > > > > Behalf
> > > > > > Of
> > > > > > > > > Stephen Hanna
> > > > > > > > > At the last NEA WG meeting (IETF 77), we agreed that
> the
> > > next
> > > > > > step
> > > > > > > > was
> > > > > > > > an
> > > > > > > > > Once you have read that paper, you should understand
> how
> > an
> > > > > > Asokan
> > > > > > > > attack
> > > > > > > > > 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
> > > > > > > > > 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
> > > > > > > > > respond to this email and we'll discuss this on the
NEA
> > > list.