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@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.