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