From nea-bounces@ietf.org Fri Jul 07 16:38:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyx5h-00008a-E8; Fri, 07 Jul 2006 16:38:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fyx5g-00005n-2M for nea@ietf.org; Fri, 07 Jul 2006 16:38:20 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fyx5d-0003NV-QN for nea@ietf.org; Fri, 07 Jul 2006 16:38:20 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 07 Jul 2006 13:38:17 -0700 X-IronPort-AV: i="4.06,218,1149490800"; d="scan'208"; a="566050135:sNHT37787944" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Jul 2006 16:38:15 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Logistics for NEA Dinner Thread-Index: AcaiBUV8t6Q162dQSn6vHI/8m1kowA== From: "Stephen Hanna" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [Nea] Logistics for NEA Dinner X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org I made reservations for our NEA dinner at the downtown location of the Vargas restaurant on Tuesday night, July 11 at 8:15 PM. They seem to have a broad menu so everyone should be OK: chicken, fish, veggies, and steak. See http://www.vargas.ca The address is 690 Bd. Rene Levesque at University but let's plan to meet at the IETF Registration desk after the last session at 7:50 PM and walk over. We'll plan to leave at 8:00 PM. If you miss us, call me on my cell phone at +1.339.223.0158. It should be working. Here are the people I have confirmed to attend: Pat Calhoun, Cisco Brian Ford, Cisco Paul Gleichauf, Cisco Susan Thomson, Cisco Mauricio Sanchez, HP Diana Arroyo, IBM Ravi Sahita, Intel John Vollbrecht, Internet 2 Steve Hanna, Juniper Eugene Chang, Meetinghouse Sandilya Garimella, Motorola Joe Tardo, Nevis Paul Sangster, Symantec If you want to be added to this list (or removed), please let me know. See you in Montreal, Steve _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Sat Jul 08 03:15:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fz72H-0004hi-2j; Sat, 08 Jul 2006 03:15:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fz72F-0004hd-T9 for nea@ietf.org; Sat, 08 Jul 2006 03:15:27 -0400 Received: from mga01.intel.com ([192.55.52.88] helo=fmsmga101-1.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fz72D-0000qm-IZ for nea@ietf.org; Sat, 08 Jul 2006 03:15:27 -0400 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101-1.fm.intel.com with ESMTP; 08 Jul 2006 00:15:24 -0700 Received: from orsmsx335.jf.intel.com (HELO orsmsx335.amr.corp.intel.com) ([10.22.226.40]) by fmsmga001.fm.intel.com with ESMTP; 08 Jul 2006 00:15:24 -0700 X-IronPort-AV: i="4.06,219,1149490800"; d="scan'208"; a="94990849:sNHT19135872" Received: from orsmsx411.amr.corp.intel.com ([10.22.226.47]) by orsmsx335.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 8 Jul 2006 00:15:24 -0700 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 Subject: RE: [Nea] Logistics for NEA Dinner Date: Sat, 8 Jul 2006 00:15:23 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Logistics for NEA Dinner Thread-Index: AcaiBUV8t6Q162dQSn6vHI/8m1kowAAWIdBQ From: "Khosravi, Hormuzd M" To: "Stephen Hanna" , X-OriginalArrivalTime: 08 Jul 2006 07:15:24.0593 (UTC) FILETIME=[480ACA10:01C6A25E] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Hey Steve Thanks for arranging this! Hope this turns out to be a celebration dinner :) Sorry I wont be able to make it since I am leaving on Tuesday evening, but hope to meet you guys before that ...I'll be there from Sunday evening to Tuesday eveing. C u all soon, Hormuzd -----Original Message----- From: Stephen Hanna [mailto:shanna@juniper.net]=20 Sent: Friday, July 07, 2006 1:38 PM To: nea@ietf.org Subject: [Nea] Logistics for NEA Dinner I made reservations for our NEA dinner at the downtown location of the Vargas restaurant on Tuesday night, July 11 at 8:15 PM. They seem to have a broad menu so everyone should be OK: chicken, fish, veggies, and steak. See http://www.vargas.ca The address is 690 Bd. Rene Levesque at University but let's plan to meet at the IETF Registration desk after the last session at 7:50 PM and walk over. We'll plan to leave at 8:00 PM. If you miss us, call me on my cell phone at +1.339.223.0158. It should be working. Here are the people I have confirmed to attend: Pat Calhoun, Cisco Brian Ford, Cisco Paul Gleichauf, Cisco Susan Thomson, Cisco Mauricio Sanchez, HP Diana Arroyo, IBM Ravi Sahita, Intel John Vollbrecht, Internet 2 Steve Hanna, Juniper Eugene Chang, Meetinghouse Sandilya Garimella, Motorola Joe Tardo, Nevis Paul Sangster, Symantec If you want to be added to this list (or removed), please let me know. See you in Montreal, Steve _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Jul 10 05:50:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzsPJ-0002WI-0T; Mon, 10 Jul 2006 05:50:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FzsPH-0002UH-EX for nea@ietf.org; Mon, 10 Jul 2006 05:50:23 -0400 Received: from mxcd03.gs.com ([12.47.209.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FzsPD-0005c6-5D for nea@ietf.org; Mon, 10 Jul 2006 05:50:23 -0400 Received: from unknown (HELO insvsod02.inz.gs.com) ([207.17.36.79]) by mxcd03.gs.com with ESMTP; 10 Jul 2006 05:50:18 -0400 Received: from gsmblnp01es.firmwide.corp.gs.com (gsmblnp01es.firmwide.corp.gs.com [154.1.192.99]) by insvsod02.inz.gs.com with ESMTP; Mon, 10 Jul 2006 05:50:18 -0400 Content-class: urn:content-classes:message Subject: RE: [Nea] Logistics for NEA Dinner MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Jul 2006 10:50:17 +0100 Message-Id: <92DF157A152AFE499293DCDBCF81A10D01266916@gsmblnp01es.firmwide.corp.gs.com> X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Logistics for NEA Dinner Thread-Index: AcaiBUwUTJLsAU58RrOvVfDmWobEQQCAOtVA From: "Sibia, Amardeep" To: "Stephen Hanna" , X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Hi Steve, Please add me to the list. Thanks=20 ________________________________________=20 Amardeep Sibia =20 ________________________________________ -----Original Message----- From: Stephen Hanna [mailto:shanna@juniper.net]=20 Sent: Friday, July 07, 2006 9:38 PM To: nea@ietf.org Subject: [Nea] Logistics for NEA Dinner I made reservations for our NEA dinner at the downtown location of the Vargas restaurant on Tuesday night, July 11 at 8:15 PM. They seem to have a broad menu so everyone should be OK: chicken, fish, veggies, and steak. See http://www.vargas.ca The address is 690 Bd. Rene Levesque at University but let's plan to meet at the IETF Registration desk after the last session at 7:50 PM and walk over. We'll plan to leave at 8:00 PM. If you miss us, call me on my cell phone at +1.339.223.0158. It should be working. Here are the people I have confirmed to attend: Pat Calhoun, Cisco Brian Ford, Cisco Paul Gleichauf, Cisco Susan Thomson, Cisco Mauricio Sanchez, HP Diana Arroyo, IBM Ravi Sahita, Intel John Vollbrecht, Internet 2 Steve Hanna, Juniper Eugene Chang, Meetinghouse Sandilya Garimella, Motorola Joe Tardo, Nevis Paul Sangster, Symantec If you want to be added to this list (or removed), please let me know. See you in Montreal, Steve _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Jul 10 16:21:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G02GV-000586-5O; Mon, 10 Jul 2006 16:21:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G02GT-000581-W4 for nea@ietf.org; Mon, 10 Jul 2006 16:21:57 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G02GS-0005ld-Ha for nea@ietf.org; Mon, 10 Jul 2006 16:21:57 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k6AKLoFk013371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 10 Jul 2006 13:21:51 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k6AKGbFQ024824; Mon, 10 Jul 2006 13:21:50 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 13:20:47 -0700 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 Subject: RE: [Nea] Comments regardingdraft-khosravi-nea-requirements-01.txt Part 1 Date: Mon, 10 Jul 2006 13:20:43 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Comments regardingdraft-khosravi-nea-requirements-01.txt Part 1 Thread-Index: Acacmzghel4FabntSNSwqf+mbLesMQHv3a2g From: "Narayanan, Vidya" To: "Frank Yeh Jr" , "Brian Ford \(brford\)" X-OriginalArrivalTime: 10 Jul 2006 20:20:47.0610 (UTC) FILETIME=[54600DA0:01C6A45E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org >=20 >> [#1] In the abstract it says: "NEA provides owners of networks (e.g. an >> enterprise offering remote access) a mechanism to learn the operational >> state or posture of a system requesting network access and then apply >> this knowledge to the network admission decision. Why call out "an >> enterprise offering remote access"? Couldn't this capability be used by >> enterprise and service (and all) providers alike over wired and wireless >> networks? > It could and should be used by all of the above. =20 =20 Specific to the above comment, I don't see how everything is the same for "providers" - as opposed to enterprises, providers don't own and control the end devices. Providers have the desire to protect their network, but it can't be done by assessing or remediating end devices that attach to it, since they don't own those end devices. The end devices are owned by the customer of that service (either an end user or an enterprise).=20 How many of us want a service provider telling us what applications we can run on laptops that we purchased? The IETF should be a good place to take this vote :)=20 Vidya _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Jul 10 16:43:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G02b6-00042u-GX; Mon, 10 Jul 2006 16:43:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G02b5-00042p-HM for nea@ietf.org; Mon, 10 Jul 2006 16:43:15 -0400 Received: from troy.oit.umass.edu ([128.119.175.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G02b4-0006jd-8g for nea@ietf.org; Mon, 10 Jul 2006 16:43:15 -0400 Received: from [128.119.1.20] (exegesis.oit.umass.edu [128.119.1.20]) (authenticated bits=0) by troy.oit.umass.edu (8.13.6/8.13.2) with ESMTP id k6AKhD7i009502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 10 Jul 2006 16:43:13 -0400 (EDT) Message-ID: <44B2BBDF.1030502@nic.umass.edu> Date: Mon, 10 Jul 2006 16:43:11 -0400 From: Christopher Misra User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: nea@ietf.org References: <56D476CC1C49B94B841267A5FB22D5314C0AAD@OIT-EX.ad.bu.edu> In-Reply-To: <56D476CC1C49B94B841267A5FB22D5314C0AAD@OIT-EX.ad.bu.edu> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [Nea] Comments on NEA requirements document X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Given the current needs and usage of NEA-like models as characterized by the work of the SALSA-NetAuth working group, we would propose the follow changes or amendments, details inline below. These comments reflect the consensus of the NetAuth working group as of 6 July 2006. Christopher Misra Chair, Internet2 Salsa-NetAuth working group = Addition to Section 4 (Common Requirements Across Architecture): Add a requirement to section 4 that is a rephrasing of point 1 from Section 7 (operational considerations): 1. Some network devices (e.g. printers, legacy systems) will not have support for NEA agents present < ... > Added as section 4.8 8. Some network devices (e.g. printers, legacy systems) will not have support for NEA agents and others, though able to run an NEA agent, might experience periods of time when the client is unable to respond using the NEA protocols. Because of this, the NEA protocols MUST be capable of detecting that some network devices are incapable of responding to NEA protocols and thus will not be able to report its security posture. The NEA architecture SHOULD allow for this event to be detected and reported to other components. The other components MAY be able to evaluate risk via other mechanisms (e.g. using scanning techniques) and report back a suggested action. Clarification of Section 5.3 5.3.Posture Transport (PT) Protocol Requirements The PT is the transport protocol between the Network Access Requestor (NAR) in the NEA Client and the Network Access Authority (NAA) within the NEA Server present on the network owner?s infrastructure. PT is responsible for providing a protected transport (frequently using a tunnel) for the PB protocol. This section will also define the use of EAP as the Posture Transport. While EAP is explicitly defined it is not the only supported method of transport. An implementation could add additional transport options in addition to EAP and still be compliant. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Jul 10 17:11:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G032G-0005i2-G0; Mon, 10 Jul 2006 17:11:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G032F-0005hg-Gp for nea@ietf.org; Mon, 10 Jul 2006 17:11:19 -0400 Received: from mga03.intel.com ([143.182.124.21] helo=azsmga101-1.ch.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G032D-0007oY-34 for nea@ietf.org; Mon, 10 Jul 2006 17:11:19 -0400 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101-1.ch.intel.com with ESMTP; 10 Jul 2006 14:11:15 -0700 Received: from fmsmsx332.fm.intel.com (HELO fmsmsx332.amr.corp.intel.com) ([132.233.42.148]) by azsmga001.ch.intel.com with ESMTP; 10 Jul 2006 14:11:00 -0700 X-IronPort-AV: i="4.06,221,1149490800"; d="scan'208"; a="63882947:sNHT11791387335" Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 14:10:53 -0700 Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Jul 2006 14:10:53 -0700 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 Subject: RE: [Nea] Commentsregardingdraft-khosravi-nea-requirements-01.txt Part 1 Date: Mon, 10 Jul 2006 17:10:50 -0400 Message-ID: <279DDDAFA85EC74C9300A0598E704056477363@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Commentsregardingdraft-khosravi-nea-requirements-01.txt Part 1 Thread-Index: Acacmzghel4FabntSNSwqf+mbLesMQHv3a2gAAI4D2A= From: "Blumenthal, Uri" To: "Narayanan, Vidya" , "Frank Yeh Jr" , "Brian Ford \(brford\)" X-OriginalArrivalTime: 10 Jul 2006 21:10:53.0091 (UTC) FILETIME=[53C80F30:01C6A465] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org >>> [#1] In the abstract it says: "NEA provides owners of networks >>> (e.g. an enterprise offering remote access) a mechanism to learn >>> the operational state or posture of a system requesting network >>> access and then apply this knowledge to the network admission >>> decision. Why call out "an enterprise offering remote access"? >>> Couldn't this capability be used by enterprise and service >>> (and all) providers alike over wired and wireless networks? >> >> It could and should be used by all of the above. > >Specific to the above comment, I don't see how everything is the same >for "providers" - as opposed to enterprises, providers don't own and >control the end devices. Correct - providers don't "own" the end devices. And I don't think that "normal" ISP "should" look into postures or attempt to enforce any policy on "normal" customers. (What ISP does wrt. Intranet access - is rather different.) >Providers have the desire to protect their network, but it >can't be done by assessing or remediating end devices >that attach to it, since they don't own those end devices.=20 Correct. "Normal" providers would just connect the end devices, without checking posture or enforcing policy (which they don't have). In that case posture verification and remediation is likely to take place when the end device attempts to connect (via VPN?) to the Intranet (after being successfully connected to Internet via ISP who did not run NEA). Some providers could act as "hired extensions of enterprise" - providing (no pun intended) direct Intranet access, plus authentication and enforcement that come with it. Next step in enterprises outsourcing their network management. In this case provider itself will run NEA on behalf of the contracting enterprise. >The end devices are owned by the customer of that service (either >an end user or an enterprise).=20 In some cases the enterprise is also the provider, in other cases enterprise hires a provider, and in some cases provider has nothing to do with enterprises. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Jul 11 14:59:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0NRl-0002B6-S2; Tue, 11 Jul 2006 14:59:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0NRk-0002B0-LH for nea@ietf.org; Tue, 11 Jul 2006 14:59:00 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0NRh-0004qV-C3 for nea@ietf.org; Tue, 11 Jul 2006 14:59:00 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 11 Jul 2006 11:58:58 -0700 X-IronPort-AV: i="4.06,230,1149490800"; d="scan'208"; a="567011723:sNHT36250644" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 11 Jul 2006 14:58:54 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NEA Dinner at 8:15 PM tonight Thread-Index: AcaiBUV8t6Q162dQSn6vHI/8m1kowADFjvyA From: "Stephen Hanna" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Subject: [Nea] NEA Dinner at 8:15 PM tonight X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Someone told me that there's some confusion about the time for tonight's NEA dinner. It will be at 8:15 PM EDT, as described in the email below. BTW, I'd say the BOF was a success so this will be a celebration. I'll buy a round of drinks. For those who aren't in Montreal, here's a virtual toast to your help. We're not out of the woods yet but I think we've found the path. Draft BOF minutes are coming soon. Thanks, Steve -----Original Message----- From: Stephen Hanna=20 Sent: Friday, July 07, 2006 4:38 PM To: nea@ietf.org Subject: Logistics for NEA Dinner I made reservations for our NEA dinner at the downtown location of the Vargas restaurant on Tuesday night, July 11 at 8:15 PM. They seem to have a broad menu so everyone should be OK: chicken, fish, veggies, and steak. See http://www.vargas.ca The address is 690 Bd. Rene Levesque at University but let's plan to meet at the IETF Registration desk after the last session at 7:50 PM and walk over. We'll plan to leave at 8:00 PM. If you miss us, call me on my cell phone at +1.339.223.0158. It should be working. Here are the people I have confirmed to attend: Pat Calhoun, Cisco Brian Ford, Cisco Paul Gleichauf, Cisco Susan Thomson, Cisco Mauricio Sanchez, HP Diana Arroyo, IBM Ravi Sahita, Intel John Vollbrecht, Internet 2 Steve Hanna, Juniper Eugene Chang, Meetinghouse Sandilya Garimella, Motorola Joe Tardo, Nevis Paul Sangster, Symantec If you want to be added to this list (or removed), please let me know. See you in Montreal, Steve _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Jul 13 10:32:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12ES-0003TE-GS; Thu, 13 Jul 2006 10:32:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12ER-0003T9-Ho for nea@ietf.org; Thu, 13 Jul 2006 10:31:59 -0400 Received: from nf-out-0910.google.com ([64.233.182.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G12EQ-0006bf-9k for nea@ietf.org; Thu, 13 Jul 2006 10:31:59 -0400 Received: by nf-out-0910.google.com with SMTP id l23so180812nfc for ; Thu, 13 Jul 2006 07:31:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=rLpS5Ifc9zj6BXXOAWqC7Yzvp8a+oGTjUC7OkMPTGQsQ+fBnsR6b/33UD2uVn0Dw5XJkPnJ7TlGzz9UB1A4rVXzfwmge/aNPrNXruyKxazu0INqrGqnwYbFQU8Iv4nD5wvk92IpF1oLAJkfOZjyPhI3IGTPp7Y8ZelwRSco6aus= Received: by 10.48.254.1 with SMTP id b1mr965458nfi; Thu, 13 Jul 2006 07:31:57 -0700 (PDT) Received: by 10.65.219.1 with HTTP; Thu, 13 Jul 2006 07:31:57 -0700 (PDT) Message-ID: Date: Thu, 13 Jul 2006 10:31:57 -0400 From: "Mike Fratto" To: nea@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 2870a44b67ee17965ce5ad0177e150f4 Subject: [Nea] Conformance requirements X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Has there been any discussion about specifying conformance requirements and testing? I didn't see anything about conformance in the archives. Or is conformance testing not something the working group will cover? _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Jul 13 10:49:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12Vj-0002iB-Vj; Thu, 13 Jul 2006 10:49:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12Vi-0002hx-LK for nea@ietf.org; Thu, 13 Jul 2006 10:49:50 -0400 Received: from mga03.intel.com ([143.182.124.21] helo=azsmga101-1.ch.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G12Vh-0007Xi-8g for nea@ietf.org; Thu, 13 Jul 2006 10:49:50 -0400 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101-1.ch.intel.com with ESMTP; 13 Jul 2006 07:49:48 -0700 Received: from fmsmsx334.fm.intel.com (HELO fmsmsx334.amr.corp.intel.com) ([132.233.42.1]) by azsmga001.ch.intel.com with ESMTP; 13 Jul 2006 07:49:48 -0700 X-IronPort-AV: i="4.06,221,1149490800"; d="scan'208"; a="65414598:sNHT38169159" Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx334.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Jul 2006 07:48:17 -0700 Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 13 Jul 2006 07:48:17 -0700 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 Subject: RE: [Nea] Conformance requirements Date: Thu, 13 Jul 2006 10:48:18 -0400 Message-ID: <279DDDAFA85EC74C9300A0598E7040564C845B@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Conformance requirements Thread-Index: AcamiSqhcm/H/AreQHy1sDrARBkAYwAAb0jg From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 13 Jul 2006 14:48:17.0384 (UTC) FILETIME=[605A6680:01C6A68B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org At this time the very existence of WG is still under question - it's perhaps too early to discuss conformance. Indeed, it is necessary to define conformance and ways to test it. My guess is we can do it later. -----Original Message----- From: Mike Fratto [mailto:mfratto@gmail.com]=20 Sent: Thursday, July 13, 2006 10:32 AM To: nea@ietf.org Subject: [Nea] Conformance requirements Has there been any discussion about specifying conformance requirements and testing? I didn't see anything about conformance in the archives. Or is conformance testing not something the working group will cover? _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Jul 13 11:09:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12ob-0004R6-Lu; Thu, 13 Jul 2006 11:09:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12oY-0004Lb-RO for nea@ietf.org; Thu, 13 Jul 2006 11:09:18 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G12kv-0008Oo-8p for nea@ietf.org; Thu, 13 Jul 2006 11:05:34 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 13 Jul 2006 08:05:33 -0700 X-IronPort-AV: i="4.06,236,1149490800"; d="scan'208"; a="562367625:sNHT28338808" X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 13 Jul 2006 11:05:31 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF 66 NEA BOF Summary Thread-Index: AcalKRfO+PMqaWq2RTmBQ4LOO4SLUgBWMNIwAAJvx3A= From: "Stephen Hanna" To: , "Russ Housley" , "Sam Hartman" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: Subject: [Nea] IETF 66 NEA BOF Summary X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Summary of NEA BOF at IETF 66 The NEA BOF focussed on discussing and agreeing on a charter for a potential NEA WG. As part of this, there was considerable discussion of the NEA use case, architecture, and scope. The session was well attended (more than 100 people). Many good questions and issues were raised, all in a constructive manner. These concerns will be reviewed to determine whether architectural changes may be needed. At the end of the session, rough consensus was reached on a revised scope. The scope in the previously proposed charter will be modified to require that the WG identify a Mandatory To Implement transport (which may be developed by another WG). Also, vendor attributes would be required to be documented in an RFC. And the protocols developed must be designed to accomodate emerging technologies for addressing lying endpoints. With these changes, rough consensus was reached that the IETF should create a WG with this scope and the previously proposed goals. A substantial number of BOF participants indicated they would help edit and author documents. The BOF chairs will work with the ADs, the mailing list, and others to prepare a revised charter reflecting the BOF's rough consensus. This charter will be submitted to the IESG for consideration. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Jul 13 11:15:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12ud-00076r-Vo; Thu, 13 Jul 2006 11:15:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G12ud-00076h-CG for nea@ietf.org; Thu, 13 Jul 2006 11:15:35 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G12uc-0000fh-0N for nea@ietf.org; Thu, 13 Jul 2006 11:15:35 -0400 Received: from [132.219.13.244] (h1c52-net84db.lab.risq.net [132.219.28.82] (may be forged)) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k6DFFU7T039274 for ; Thu, 13 Jul 2006 08:15:32 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 13 Jul 2006 11:15:48 -0400 To: nea@ietf.org From: Paul Hoffman Subject: Re: [Nea] Conformance requirements Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org At 10:31 AM -0400 7/13/06, Mike Fratto wrote: >Has there been any discussion about specifying conformance >requirements and testing? I didn't see anything about conformance in >the archives. Or is conformance testing not something the working >group will cover? The IETF doesn't do conformance testing. The RFCs issued by the group will specify what implementations will need to conform to. It is up to implementers to do so. In the case where the market feels a need to "prove" conformance and/or interoperability, a vendor association and/or a testing service can do that for the vendors. [Insert subtly implied advertisement here...] --Paul Hoffman, Director --VPN Consortium _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Jul 19 15:05:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3HM3-0001xQ-Vj; Wed, 19 Jul 2006 15:05:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3HM3-0001xL-2Y for nea@ietf.org; Wed, 19 Jul 2006 15:05:07 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3HM2-0002My-51 for nea@ietf.org; Wed, 19 Jul 2006 15:05:07 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 19 Jul 2006 12:05:05 -0700 X-IronPort-AV: i="4.06,256,1149490800"; d="scan'208"; a="569249020:sNHT48122452" x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Jul 2006 15:05:04 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft minutes from IETF 66 NEA BOF Thread-Index: AcarZj3i+sotKuQSQFeRwkW6QxLPBg== From: "Stephen Hanna" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8aa7cbc518894eb04182283f0682f662 Subject: [Nea] Draft minutes from IETF 66 NEA BOF X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Here are the latest draft minutes for the NEA BOF held at IETF 66. Thanks to the note takers for their excellent notes! I also used the audio recording to add some more info. That was very useful. I apologize for any errors. Please review these and let me know if you have any comments. In particular, I'd like to identify the few people who are listed as "Unknown Person". I will incorporate any comments sent to me by August 1 into a new draft and submit that for the proceedings. Thanks, Steve ------------ Draft Minutes of IETF NEA BOF at IETF 66 July 11, 2006 Minutes taken by Brian Ford and Mauricio Sanchez Meeting was called to order at 9:01 AM Steve Hanna and Susan Thomson chairing *Agenda Bashing* No agenda changes needed. Chairs were asked to please give their email addresses. They were added to the title slide. *NEA Background Presentation* The chairs went through the NEA background presentation in the slides. See those slides for content. Questions asked are noted here. Dave Oran: Does NEA include a capability for the client to interrogate the network to make a decision if it wants to join? Susan Thomson: This is not in our requirements. Eric Rescorla: Any given system has many pieces of software installed and many may not have the capability to communicate via NEA. What fraction of applications are expected to be able to provide posture data? Steve Hanna: Most applications will not include a posture collector or validator. Instead, something like a patch manager application would provide posture for a large number of applications. *Discussion* Discussion of the NEA Use Case and Architecture began. Jeff Schiller: If lying endpoints are not in scope, what's the point? Uri Blumenthal: NEA is a vaccination technology not a treatment technology. It is infeasible to detect a lying endpoint just with protocols. But there are other methods being developed, like TCG's TPM. Kurtis Lindqvist: Lying endpoints are important. Bernard Aboba: Are we saying that NEA will be incompatible with TPM and other technologies that use signed assertions? Steve Hanna: We can do this with vendor-specific attributes. Uri Blumenthal: Calling those vendor-specific is misleading. They'd probably be vendor-independent, especially for TPM. Michael Galant: Does the architecture support external validators? Steve Hanna: Yes. Validators can take input from external sources like Intrusion Detection Systems and network scanners. Stefan Santesson: This is a solution that allows us to reduce risk of operating a network. The community consists of different vendors with solutions. We have customers looking for solutions with common interfaces. But standards do not work well when vendors try to impose their will through standards. We might be too early to know where that vendors-customer ecosystem should exist. Susan Thomson: Actually, lots of work has in fact been done. People have been shipping products that do this for years. Thomas Narten: When I hear that lying endpoints are out of scope, I fear that security is out of scope and that the system will not work. Adding security later is very hard. Steve Hanna: TCG has done lots of work on handling lying endpoints. But IETF does not want to get into that area. So that problem is=20 not being avoided. External mechanisms can be used. Eric Rescorla: The techniques for detecting lying endpoints are not compatible with open systems. What is the likelihood that a posture collector from one vendor will interoperate with a posture validator from another vendor? And will this working group stay around to standardize more attributes? Steve Hanna: For standardized attributes, we should be able to get good interoperability. I hope we can avoid hanging around for years, extending that set of standardized attributes. Just choose a few. Uri Blumenthal: Big vendors are already doing this. The question is whether IETF will step in to develop an interoperable solution. Vidya Narayanan: It is not clear to me what the scope of interoperability is here. What is it in terms of interoperability are we talking about? Susan Thomson: Posture attributes will likely be vendor specific. All we are talking about is trying to standardize how the communication will work. Vidya Narayanan: Are we trying to standardize SMS (Microsoft Systems Management Server)? Ryan Hurst: No, this is not SMS. Customers definitely want interoperability. But I'm not sure that this work will provide an interoperable solution. It doesn't cover all the protocols needed. Also, it will take a long time to be completed. There are a number of EAP methods that are stalled in draft stage. And how successful can we be if only limited posture variables are available? Again, I'm not sure that as chartered the WG will result in a working solution. Tim Polk: Solving the lying endpoint problem should be out of scope but the group should be required to provide protocols that are designed to support solutions for detecting lying endpoints. The charter should be updated to reflect this. Pat Calhoun: This technology is being deployed whether the IETF wants it or not. If the IETF doesn't get involved, all the issues raised today probably won't be addressed. Amardeep Sibia: I'm with Goldman Sachs. NEA is a risk mitigation technology for us and most of our peers in the industry agree with us. Without standards in this area, we fear that we may invest here and in 2-3 years not have a viable technology solution that supports this. Bob Morgan: We need solutions to the lying endpoint problem. NEA should at least be compatible with those. The set of attributes will need to be constantly extended (like MIBs and LDAP). Multiple transports is fine. That may raise a negotiation issue but it should probably be out of scope. But you should at least ID an EAP transport. Unknown Person (Leif Johansson?): I support Tim's comments. And I support the need for external sources of posture information. On detecting viruses, we needn't be perfect to be useful. Ryan Hurst: A number of players in this industry are already trying to work together. This proposal maps to what they have produced so far. I do see value in a standard being created but I worry about the narrow scope of the charter. It should be scoped to reflect the overall problem area, not current vendor capabilities. Bernard Aboba: NEA's assumptions about posture transport don't always hold true. For example, EAP-PEAP doesn't support arbitrary inner methods. Thomas Narten: We have to be careful about having most of the posture data in vendor-specific attributes. That can lead to poor interoperability. Susan Thomson: Posture collectors and validators will likely come from the same vendor, but that is not required if they use the minimal set of standard attributes. The rest of the architecture may or may not come from the same vendor. Stefan Santesson: Where are you expecting interoperability? Steve Hanna: The goal for NEA is to achieve client/server interoperability.=20 Stefan Santesson: The NEA architecture diagram is not representative of all possible or even all current architectures. Sam Hartman: What else should be added? Stefan Santesson: It's too early to tell what the best architecture is and where standardization should be done. Susan Thomson: The NEA architecture can support a wide variety of Posture Transport protocols. Sam Hartman: You should have one that's Mandatory To Implement to ensure interoperability. Richard Graveman: Lying endpoints can cause lots of problems. We should say in a positive sense what we're doing. Is this perimeter defense? Maybe this isn't security and should be done in the applications or operations area. Vidya Narayanan: I question the viability of NEA given perceived issues around limited posture attribute definition, EAP incompatibilities, and limited EAP deployment in the enterprise. Posture validation should not be part of network access authentication. Otherwise, it will be too intrusive and slow. A UDP transport would be much better. Steve Hanna: NEA will support a variety of Posture Transport protocols not just EAP. Thomas Narten: Typically in the IETF there is one mandatory to implement protocol and other optional protocols. That helps ensure interoperability. Are you saying there won't be a mandatory to implement Posture Transport protocol? Steve Hanna: The NEA WG is not the appropriate forum for standardizing Posture Transport protocols since those go beyond what's needed for NEA. However, we certainly could identify one as mandatory to implement if IETF standardizes some. =20 Susan Thomson: There is no standard mandatory to implement EAP carrier like 802.1x. Why must we define mandatory to implement for all protocols in the stack? Thomas Narten: That's necessary to get interoperability. Brian Ford: Vendors should publish specs for the attributes they invent so others can reuse them. Also, endpoints can decide which networks they want to connect to. Joe Salowey: Most current products support EAP. There are several good existing EAP methods for this. We probably need the IETF to standardize one and then we can make it mandatory to implement. Amardeep Sibia: There are many Posture Transport protocols now. I'd like to have that set narrow down. Standard attributes are good but there will always be a need for vendor-specific attributes also. John Vollbrecht: This is a good architecture. It doesn't solve all problems but it enables solution of many. For example, it doesn't detect lying endpoints but it allows other technology to do so. Collectors can do many things: user authentication, client assessment of the network, etc. We shouldn't downplay the value of this work. Pat Calhoun: Is some set of standard attributes in scope? Steve Hanna: Yes. Pat Calhoun: Some people have said we can't get interoperability across vendors. Do you agree? Susan Thomson: We can get that if it's useful. Pat Calhoun: Do you think it's useful? Steve Hanna: I think it's useful and it's in the current draft charter. Pat Calhoun: This year, I'd say that about 90% of new wireless nets are running 802.11i not VPNs. And use of 802.1x in wired nets is increasing. Dave Oran: I'm speaking as an individual and have several comments. First, it is an architectural error to cast this as a client server protocol. It's equally important for the client to evaluate the server to ensure that its credentials aren't stolen. Second, at the transport level you can't punt so much. If you don't define a mandatory to implement Posture Transport protocol, then the Proxy Broker protocol must be securely proxyable so you can have a protocol translator in the middle. Third, posture collection shouldn't be coupled with authentication. There's no need for those to be so strongly coupled. Fourth, if SIP had vendor attributes, we'd have a huge mess. Maybe you should require vendors to publish RFCs with the syntax and semantics of their attributes. Stefan Santesson: There might be multiple transport protocols. And there is also the issue of timing. Do you do posture collection when you connect to the network or do you do it beforehand and collect a token that you can use when you connect to the network? Posture attributes should be the focus for standardization. Susan Thomson: This system allows for prior posture collection and assertion. Stefan Santesson: That's my point. Transport isn't the important issue. Ryan Hurst: We will need to standardize on the higher level components as well as the lower for a truly interoperable solution. Microsoft has documented our equivalents to PA and PB on MSDN and committed to royalty free licensing of them. And we'll revise our PEAPv0 document to document the known implementation hurdles and document how PA and PB can be carried. I'd like to see everyone document how they do things today so we can achieve interoperability and then we can look at the larger problem of how best to solve this problem. There is value here but the scope should be wider. Dave Nelson: I agree with previous comments that we need true interoperability and what that entails. What we're discussing here is necessary but not sufficient. And maybe not generally useful. So maybe it's not worth creating a Working Group. And if we're going to do only this part of the work, someone else must finish it. Brian Ford: The NAC marketplace is exploding. At the RSA show, there were 24 new NAC-oriented companies. There are dozens of anti-virus vendors. The time is ripe for IETF to get involved. Everyone needs multi-vendor interoperability across OS, network hardware, etc. Bernard Aboba: We can only standardize things we know how to do. There are dozens of important transport and other documents that IETF hasn't published. We need to get those published for this work to be useful. Steve Hanna: Time for some consensus checks. * Do you favor IETF forming a WG to work on the NEA problem as described in the use case described on the slide? Hum. Outcome: Roughly 2/3 in favor, 1/3 opposed * Are you comfortable with the architecture shown on the screen and described in the problem statement? Shall we proceed with this and with the scope of the WG to be PA, PB, and requirements for PT? Sam Hartman: Let's hum on Tim's suggestion re lying endpoints first. * Should we revise the charter to say we're required to support solutions to the lying endpoint problem but that we won't solve it ourselves? Hum. Overwhelmingly in favor. * With that change, let's return to the previous question. Are you comfortable with the architecture and scope with that revision (PA, PB, and requirements for PT)? Hum. Roughly evenly divided. Unknown Person: Let's split this by levels to pinpoint the problem. * Are you comfortable with the overall architecture as a reference model: three layers with protocols at each layer? Hum: Large majority in favor. Eric Rescorla: Why aren't we talking about the charter? Steve Hanna: We don't have time to discuss the details of the charter language. All we'll have time for today is maybe to agree on scope. * Who is uncomfortable with having PA in scope? Hum: Very few. Eric Rescorla: But there was big discussion on which attributes should be standardized. Steve Hanna: * Are people comfortable with standardizing the PA protocol and a small set of messages? Hum: Majority uncomfortable. * Are people comfortable standardizing the PB protocol here? Hum: Majority comfortable. * Are people comfortable only defining requirements for the PT protocol here? Hum: Majority uncomfortable. Dave Oran: For PA, let's do what SIP did: require an RFC (Informational or Standards Track) to be written before attributes can go in the protocol. * Would you be comfortable with the PA-related scope if we adopted Dave's proposal? We'd standardize PA, standardize some minimal set of attributes, and require vendors who want to define attributes must publish an RFC on those. Hum: Large majority comfortable. Sam Hartman: On PT, I suggest that we require this group to choose a mandatory to implement Posture Transport. * Would you be comfortable with the PT-related scope if we defined requirements and then eventually our Working Group was required to identify a mandatory to implement PT? Hum: Majority comfortable. More than 2/3 but not total agreement. Steve Hanna: I think we have agreement now on the reference model and scope. Let me frame the next question. How about: * Shall we form a NEA WG with the goal of achieving NEA client-server interoperability across a variety of Posture Transports (assuming Posture Transport interoperability) and with the scope as previously described: standardize PA with a few standard attributes and require vendors to publish RFCs for any vendor-specific attributes, standardize PB, agree on requirements for PT, and identify a mandatory to implement PT? Lakshminath Dondeti: We should ask: given what we've agreed on, how many people think we'll achieve something meaningful at the end of this. Steve Hanna: Well, if you think this effort is pointless, please don't hum in favor of creating a Working Group! Hum on the question listed in the previous bullet, which was written up on a slide during the meeting: Outcome unclear Show of hands on the topic: substantial majority in favor Sam Hartman: Let's hear 30 second statements from people who don't think we should form a Working Group. Ryan Hurst: Charter as specified is too narrow to create an interoperable solution. Need more detail in PA. But IETF shouldn't standardize most attributes. And need a more forward-looking architecture. Bernard Aboba: I was happier without the most recent changes, especially identifying a mandatory to implement PT. That's a can of worms. Vidya Narayanan: There are so many operating systems and such. Whatever we do won't create a meaningful interoperability. Dave Oran: To convince me, you'd have to address my previous points about symmetry and tying this to authentication. Steve Hanna: Clients can=20 Eric Rescorla: I'm skeptical that this whole concept will work. Lakshminath Dondeti: ADs, can we slap an applicability statement on this now? It seems clear to me that this won't work on service provider networks. Unknown Person: We should have a show of hands from those who want to participate. Steve Hanna: We did that last time but we can do it again. * Who would be willing to participate actively? Significant number of hands (15-20). * Who would be willing to edit or author documents? Good number of hands (10-15). Steve Hanna: ADs, anything else we need to do? Sam Hartman: No. I just want to say that there will now be a discussion within the IESG of this issue and that will be a very interesting discussion. Steve Hanna: Yes, it's not a shoe-in. Sam Hartman: But this BOF went better than expected and about as well as it could. Steve Hanna: I'd like to thank the ADs and BOF participants for a very constructive and helpful BOF. Meeting adjourned 11:27 PM _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Sun Jul 30 16:38:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7I3Z-0004H9-TY; Sun, 30 Jul 2006 16:38:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7I3X-0004H4-UK for nea@ietf.org; Sun, 30 Jul 2006 16:38:35 -0400 Received: from mga01.intel.com ([192.55.52.88] helo=fmsmga101-1.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7I3W-00056K-KQ for nea@ietf.org; Sun, 30 Jul 2006 16:38:35 -0400 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101-1.fm.intel.com with ESMTP; 30 Jul 2006 13:38:33 -0700 Received: from orsmsx331.jf.intel.com (HELO orsmsx331.amr.corp.intel.com) ([192.168.65.56]) by fmsmga001.fm.intel.com with ESMTP; 30 Jul 2006 13:38:33 -0700 X-IronPort-AV: i="4.07,196,1151910000"; d="scan'208"; a="107464495:sNHT18951128" Received: from orsmsx411.amr.corp.intel.com ([10.22.226.47]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 30 Jul 2006 13:38:33 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [Nea] IETF 66 NEA BOF Summary Date: Sun, 30 Jul 2006 13:38:32 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] IETF 66 NEA BOF Summary thread-index: AcalKRfO+PMqaWq2RTmBQ4LOO4SLUgBWMNIwAAJvx3ADYxPloA== From: "Khosravi, Hormuzd M" To: "Stephen Hanna" , , "Russ Housley" , "Sam Hartman" , X-OriginalArrivalTime: 30 Jul 2006 20:38:33.0382 (UTC) FILETIME=[1FE2F460:01C6B418] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Hi Steve Any news on the formation of the WG? By when will we get the final word? The BoF was successful, but we haven't heard of anything after that. Thanks Hormuzd -----Original Message----- From: Stephen Hanna [mailto:shanna@juniper.net]=20 Sent: Thursday, July 13, 2006 8:06 AM To: nea@ietf.org; Russ Housley; Sam Hartman; saag@mit.edu Subject: [Nea] IETF 66 NEA BOF Summary Summary of NEA BOF at IETF 66 The NEA BOF focussed on discussing and agreeing on a charter for a potential NEA WG. As part of this, there was considerable discussion of the NEA use case, architecture, and scope. The session was well attended (more than 100 people). Many good questions and issues were raised, all in a constructive manner. These concerns will be reviewed to determine whether architectural changes may be needed. At the end of the session, rough consensus was reached on a revised scope. The scope in the previously proposed charter will be modified to require that the WG identify a Mandatory To Implement transport (which may be developed by another WG). Also, vendor attributes would be required to be documented in an RFC. And the protocols developed must be designed to accomodate emerging technologies for addressing lying endpoints. With these changes, rough consensus was reached that the IETF should create a WG with this scope and the previously proposed goals. A substantial number of BOF participants indicated they would help edit and author documents. The BOF chairs will work with the ADs, the mailing list, and others to prepare a revised charter reflecting the BOF's rough consensus. This charter will be submitted to the IESG for consideration. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Jul 31 15:50:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7dmX-00014a-Bo; Mon, 31 Jul 2006 15:50:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G7dmW-00014V-Ul for nea@ietf.org; Mon, 31 Jul 2006 15:50:28 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G7dmV-0005vl-Kb for nea@ietf.org; Mon, 31 Jul 2006 15:50:28 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 31 Jul 2006 12:50:30 -0700 X-IronPort-AV: i="4.07,199,1151910000"; d="scan'208"; a="572916140:sNHT46238500" x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] IETF 66 NEA BOF Summary Date: Mon, 31 Jul 2006 15:50:36 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] IETF 66 NEA BOF Summary Thread-Index: AcalKRfO+PMqaWq2RTmBQ4LOO4SLUgBWMNIwAAJvx3ADYxPloAAkOBwQ From: "Stephen Hanna" To: "Khosravi, Hormuzd M" , , "Russ Housley" , "Sam Hartman" , X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Sorry for the gap in communications. Travel slowed things down. Susan and I are working on the revised charter. I hope we'll have something back to the NEA list within a few weeks. The timeline for an eventual IESG decision is more uncertain but I expect it would not be more than a month or two. Thanks, Steve -----Original Message----- From: Khosravi, Hormuzd M [mailto:hormuzd.m.khosravi@intel.com]=20 Sent: Sunday, July 30, 2006 4:39 PM To: Stephen Hanna; nea@ietf.org; Russ Housley; Sam Hartman; saag@mit.edu Subject: RE: [Nea] IETF 66 NEA BOF Summary Hi Steve Any news on the formation of the WG? By when will we get the final word? The BoF was successful, but we haven't heard of anything after that. Thanks Hormuzd -----Original Message----- From: Stephen Hanna [mailto:shanna@juniper.net]=20 Sent: Thursday, July 13, 2006 8:06 AM To: nea@ietf.org; Russ Housley; Sam Hartman; saag@mit.edu Subject: [Nea] IETF 66 NEA BOF Summary Summary of NEA BOF at IETF 66 The NEA BOF focussed on discussing and agreeing on a charter for a potential NEA WG. As part of this, there was considerable discussion of the NEA use case, architecture, and scope. The session was well attended (more than 100 people). Many good questions and issues were raised, all in a constructive manner. These concerns will be reviewed to determine whether architectural changes may be needed. At the end of the session, rough consensus was reached on a revised scope. The scope in the previously proposed charter will be modified to require that the WG identify a Mandatory To Implement transport (which may be developed by another WG). Also, vendor attributes would be required to be documented in an RFC. And the protocols developed must be designed to accomodate emerging technologies for addressing lying endpoints. With these changes, rough consensus was reached that the IETF should create a WG with this scope and the previously proposed goals. A substantial number of BOF participants indicated they would help edit and author documents. The BOF chairs will work with the ADs, the mailing list, and others to prepare a revised charter reflecting the BOF's rough consensus. This charter will be submitted to the IESG for consideration. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea