[Nea] Draft IETF 78 NEA WG meeting minutes

["Susan Thomson (sethomso)" <[e-mail]>]

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: [e-mail]

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.