From sethomso@cisco.com Fri Aug 27 18:30:22 2010 Return-Path: X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CE953A676A for ; Fri, 27 Aug 2010 18:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.299 X-Spam-Level: X-Spam-Status: No, score=-109.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICXuq-McEs+8 for ; Fri, 27 Aug 2010 18:30:15 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 48C7A3A65A5 for ; Fri, 27 Aug 2010 18:30:12 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALMDeEytJV2d/2dsb2JhbACgX3GgXJtNhTcEhDtPh3I X-IronPort-AV: E=Sophos;i="4.56,281,1280707200"; d="scan'208";a="152805359" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-2.cisco.com with ESMTP; 28 Aug 2010 01:30:43 +0000 Received: from xbh-rcd-101.cisco.com (xbh-rcd-101.cisco.com [72.163.62.138]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id o7S1UhvM031639 for ; Sat, 28 Aug 2010 01:30:43 GMT Received: from xmb-rcd-105.cisco.com ([72.163.62.147]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 27 Aug 2010 20:30:43 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Aug 2010 20:30:40 -0500 Message-ID: <043901FAFD488D44ACC9CCED00470BDC0279082C@XMB-RCD-105.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft IETF 78 NEA WG meeting minutes Thread-Index: ActGUKAxHU+j3qzFSrSEjsIErGKvaw== From: "Susan Thomson (sethomso)" To: X-OriginalArrivalTime: 28 Aug 2010 01:30:43.0632 (UTC) FILETIME=[A1D09300:01CB4650] Subject: [Nea] Draft IETF 78 NEA WG meeting minutes X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Aug 2010 01:30:22 -0000 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.=20 Instead, they summarize the material presented, and focus on=20 comments and discussion. Agenda =3D=3D=3D=3D=3D=3D Date: Tuesday, July 27, 2010 Time: 1300-1500=20 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 =20 1435 Consensus Questions 1450 Next Steps 1455 Milestones 1500 Adjourn WG Status =3D=3D=3D=3D=3D=3D=3D=3D=3D Susan Thomson reviewed WG status. There are several individual PT=20 submissions. One stumbling block to adopting the drafts as WG=20 documents has been confusion about the NEA Asokan attack. The=20 objective of this meeting is to make sure that the NEA Asokan=20 attack is understood by the WG and to determine if there is=20 consensus to address it. NEA Reference Model =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Steve Hanna reviewed the NEA reference model for the benefit of=20 those new to the WG. NEA Asokan Attack =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Joe Salowey started the discussion by describing 2 different trust=20 models that apply in the case of NEA. One model is at the PT layer=20 where a NEA client and server communicate over a secure transport,=20 such as TLS (PT trust model). In this model, if the NEA client is=20 configured to only communicate to an authorized NEA server, then=20 MITM attacks can be mitigated. If the NEA client is not configured=20 to talk to an authorized NEA server, then MITM attacks are=20 possible. Another trust model that applies is at the PA layer (PA trust=20 model). To deal with the lying endpoint problem, some NEA client=20 implementations have the ability to attest to the validity of the=20 posture attributes in a way that a posture validator can verify=20 it. The issue comes in when these two are put together, and one of the=20 trust models breaks down, in particular at the PT layer.=20 Steve then described the NEA Asokan atack. This was discussed at=20 the last IETF and there is a detailed description on the mailing=20 list. Briefly, a compromised NEA client, with technology that=20 allows the NEA server to detect a lying endpoint, establishes a=20 secure transport connection with a NEA server. The objective of=20 the attacker is to have the compromised endpoint appear to be=20 compliant to the NEA server. This can be accomplished by having a=20 spy machine, which is compliant, send its posture to a spy NEA=20 server, which in turn forwards the PA and PB posture attributes=20 via the compromised NEA client to the NEA server. Without any=20 counter-measures, the NEA server is unable to detect that the=20 posture is not that of the compromised machine. This attack is analogous to that described for authentication=20 using EAP tunnel methods, and is described in the literature by=20 Asokan and others. In this attack, an inner authentication method=20 from one EAP peer is forwarded into an outer method from another=20 EAP peer, and the EAP server doing the authentication is not able=20 to detect this.=20 Open Discussion=20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The NEA Asokan attack was discussed at the last IETF. However,=20 there was confusion about the nature of the attack, and no=20 consensus on whether to address it in the NEA WG. In this meeting, the goal is to make sure that the NEA Asokan=20 attack is understood, and to achieve consensus on whether to=20 address it. Tim Polk asked the question how many people feel they understand=20 the attack. A majority responded in the affirmative.=20 There were 2 subsequent clarifying questions. Alvaro Cardenas asked why the spy machine could not communicate=20 with the NEA server directly.=20 Steve responded that this is possible. However, the objective of=20 the attacker is to get a compromised (non-compliant) machine, onto=20 the network, rather than the spy machine which is compliant and=20 assumed to be clean.=20 There was another question about the feasibility of this attack.=20 The question was how would the spy machines get onto the network=20 if access controls were in place. Steve responded that it is not necessary to have the spy equipment=20 in the building. The compromised machine is assumed to have=20 multiple interfaces e.g. wireless, 3G, which can allow remote=20 access into the machine. Before the consensus check was taken, Tim Polk read the=20 appropriate portion of the NEA WG charter which says that the WG=20 must accommodate emerging technologies that detect lying=20 endpoints. Chris Inascio asked who is responsible for defining PT. Steve=20 responded that the NEA WG is, but the PT will to the extent=20 possible leverage existing transports such as TLS. Joe stated that part of this attack relies on technology to=20 perform lying endpoint protection. We need to make sure that there=20 is sufficient information to ensure that emerging technologies are=20 accommodated. Right now, it is not clear how they work.=20 Tim says there is no official process to do this, but in the case=20 of TPM developed in TCG we have members of that organization in=20 this WG who can ensure that what this WG produces will work. But=20 the output of this WG should be general and able to work with=20 multiple technologies, and should not be specific to TPM. Joe said he agrees that the approach should be general, and that=20 the next step should be to define a general abstraction of the=20 technology that deals with the lying endpoint problem. Steve said that he and Paul Sangster are co-chairs of TNC and can=20 help ensure that the NEA protocols work with TPM.=20 Tim reiterated that if there are other technologies out there, we=20 do not have a process in place to deal with them.=20 Steve agreed that the approach should be general so that whatever=20 the PA mechanism is, it will defeat the Asokan attack. Consensus Check Question: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= The question was asked whether the NEA Asokan attack needs to be=20 addressed. The result was unanimous in favor of addressing the=20 attack. This result needs to be confirmed on the list. Proposed Next Steps: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Susan reviewed next steps. The proposal is to rework the current=20 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=20 attack. The hope is that the counter-measure can be designed to be PT- independent, and can be leveraged by multiple PTs. Proposed Milestones: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Susan reviewed the milestones. The goal is to set up a design team=20 to work on the counter-measure and produce an I-D in time for=20 review at the next IETF. The hope is that at the Beijing IETF, the=20 WG can converge on the PT I-Ds, so that these I-Ds can become WG=20 documents shortly after that. Tim confirmed that the proposal is to produce an I-D before the=20 next IETF, and said that the plan looked fine. He suggested that=20 it was possible that the first version of the design team output=20 could be a WG I-D, rather than be an individual submission. Susan agreed that this was possible, although it depends on the=20 progress of the design team. Steve asked whether there were concerns about this approach. There=20 were none, and asked for names of volunteers for the design team.=20 Joe Salowey, Nancy Winget, Steve Hanna and Paul Sangster=20 volunteered. Paul asked whether any changes are required to the PT-TLS I-D,=20 since it currently does not include any protection against the NEA=20 attack. Susan said that it is probably best to wait for the output of the=20 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=20 produced with the necessary hooks, if any. Meeting adjourned. =20