Hi,
At IETF 78, the NEA WG unanimously agreed that they
*did* need to address the Asokan attack(s) against NEA.
At the end of these minutes, see their Proposed Next
Steps and Proposed Milestones.
Cheers,
- Ira
---------- Forwarded message ----------
From: Susan Thomson (sethomso) <sethomso at cisco.com>
Date: Fri, Aug 27, 2010 at 9:30 PM
Subject: [Nea] Draft IETF 78 NEA WG meeting minutes
To: nea at ietf.org
Draft meeting minutes from Maastricht IETF are below.
Please let me know of any corrections by Sept 10, 2010.
Thanks
Susan
---------------------------
These notes do not attempt to duplicate the content of the slides.
Instead, they summarize the material presented, and focus on
comments and discussion.
Agenda
======
Date: Tuesday, July 27, 2010
Time: 1300-1500
WG Charter: http://www.ietf.org/html.charters/nea-charter.html
WG Tools: http://tools.ietf.org/wg/nea
WG email: nea at ietf.org
1300 Administrivia
Blue Sheets
Jabber & Minute scribes
Agenda bashing
1305 WG Status
1310 NEA Reference Model
1315 Description of NEA Asokan Attack
1345 Open Discussion
1435 Consensus Questions
1450 Next Steps
1455 Milestones
1500 Adjourn
WG Status
=========
Susan Thomson reviewed WG status. There are several individual PT
submissions. One stumbling block to adopting the drafts as WG
documents has been confusion about the NEA Asokan attack. The
objective of this meeting is to make sure that the NEA Asokan
attack is understood by the WG and to determine if there is
consensus to address it.
NEA Reference Model
====================
Steve Hanna reviewed the NEA reference model for the benefit of
those new to the WG.
NEA Asokan Attack
=================
Joe Salowey started the discussion by describing 2 different trust
models that apply in the case of NEA. One model is at the PT layer
where a NEA client and server communicate over a secure transport,
such as TLS (PT trust model). In this model, if the NEA client is
configured to only communicate to an authorized NEA server, then
MITM attacks can be mitigated. If the NEA client is not configured
to talk to an authorized NEA server, then MITM attacks are
possible.
Another trust model that applies is at the PA layer (PA trust
model). To deal with the lying endpoint problem, some NEA client
implementations have the ability to attest to the validity of the
posture attributes in a way that a posture validator can verify
it.
The issue comes in when these two are put together, and one of the
trust models breaks down, in particular at the PT layer.
Steve then described the NEA Asokan atack. This was discussed at
the last IETF and there is a detailed description on the mailing
list. Briefly, a compromised NEA client, with technology that
allows the NEA server to detect a lying endpoint, establishes a
secure transport connection with a NEA server. The objective of
the attacker is to have the compromised endpoint appear to be
compliant to the NEA server. This can be accomplished by having a
spy machine, which is compliant, send its posture to a spy NEA
server, which in turn forwards the PA and PB posture attributes
via the compromised NEA client to the NEA server. Without any
counter-measures, the NEA server is unable to detect that the
posture is not that of the compromised machine.
This attack is analogous to that described for authentication
using EAP tunnel methods, and is described in the literature by
Asokan and others. In this attack, an inner authentication method
from one EAP peer is forwarded into an outer method from another
EAP peer, and the EAP server doing the authentication is not able
to detect this.
Open Discussion
===============
The NEA Asokan attack was discussed at the last IETF. However,
there was confusion about the nature of the attack, and no
consensus on whether to address it in the NEA WG.
In this meeting, the goal is to make sure that the NEA Asokan
attack is understood, and to achieve consensus on whether to
address it.
Tim Polk asked the question how many people feel they understand
the attack. A majority responded in the affirmative.
There were 2 subsequent clarifying questions.
Alvaro Cardenas asked why the spy machine could not communicate
with the NEA server directly.
Steve responded that this is possible. However, the objective of
the attacker is to get a compromised (non-compliant) machine, onto
the network, rather than the spy machine which is compliant and
assumed to be clean.
There was another question about the feasibility of this attack.
The question was how would the spy machines get onto the network
if access controls were in place.
Steve responded that it is not necessary to have the spy equipment
in the building. The compromised machine is assumed to have
multiple interfaces e.g. wireless, 3G, which can allow remote
access into the machine.
Before the consensus check was taken, Tim Polk read the
appropriate portion of the NEA WG charter which says that the WG
must accommodate emerging technologies that detect lying
endpoints.
Chris Inascio asked who is responsible for defining PT. Steve
responded that the NEA WG is, but the PT will to the extent
possible leverage existing transports such as TLS.
Joe stated that part of this attack relies on technology to
perform lying endpoint protection. We need to make sure that there
is sufficient information to ensure that emerging technologies are
accommodated. Right now, it is not clear how they work.
Tim says there is no official process to do this, but in the case
of TPM developed in TCG we have members of that organization in
this WG who can ensure that what this WG produces will work. But
the output of this WG should be general and able to work with
multiple technologies, and should not be specific to TPM.
Joe said he agrees that the approach should be general, and that
the next step should be to define a general abstraction of the
technology that deals with the lying endpoint problem.
Steve said that he and Paul Sangster are co-chairs of TNC and can
help ensure that the NEA protocols work with TPM.
Tim reiterated that if there are other technologies out there, we
do not have a process in place to deal with them.
Steve agreed that the approach should be general so that whatever
the PA mechanism is, it will defeat the Asokan attack.
Consensus Check Question:
=========================
The question was asked whether the NEA Asokan attack needs to be
addressed. The result was unanimous in favor of addressing the
attack.
This result needs to be confirmed on the list.
Proposed Next Steps:
====================
Susan reviewed next steps. The proposal is to rework the current
individual submission as follows:
- have one I-D for each base PT (assuming the PT trust model)
- a separate I-D describing the counter-measure to the NEA Asokan
attack.
The hope is that the counter-measure can be designed to be PT-
independent, and can be leveraged by multiple PTs.
Proposed Milestones:
====================
Susan reviewed the milestones. The goal is to set up a design team
to work on the counter-measure and produce an I-D in time for
review at the next IETF. The hope is that at the Beijing IETF, the
WG can converge on the PT I-Ds, so that these I-Ds can become WG
documents shortly after that.
Tim confirmed that the proposal is to produce an I-D before the
next IETF, and said that the plan looked fine. He suggested that
it was possible that the first version of the design team output
could be a WG I-D, rather than be an individual submission.
Susan agreed that this was possible, although it depends on the
progress of the design team.
Steve asked whether there were concerns about this approach. There
were none, and asked for names of volunteers for the design team.
Joe Salowey, Nancy Winget, Steve Hanna and Paul Sangster
volunteered.
Paul asked whether any changes are required to the PT-TLS I-D,
since it currently does not include any protection against the NEA
attack.
Susan said that it is probably best to wait for the output of the
design team since it is possible that some binding to the counter-
measure will be necessary.
Steve agreed, and said that the revised PT and EAP I-Ds could be
produced with the necessary hooks, if any.
Meeting adjourned.
_______________________________________________
Nea mailing list
Nea at ietf.orghttps://www.ietf.org/mailman/listinfo/nea
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ids/attachments/20100830/63eec492/attachment-0001.html>