From nea-bounces@ietf.org Tue May 02 19:05:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb3wN-0004FL-F6; Tue, 02 May 2006 19:05:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb3wM-0004FE-5E for nea@ietf.org; Tue, 02 May 2006 19:05:58 -0400 Received: from mga02.intel.com ([134.134.136.20] helo=orsmga101-1.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb3wK-0005jS-SD for nea@ietf.org; Tue, 02 May 2006 19:05:58 -0400 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101-1.jf.intel.com with ESMTP; 02 May 2006 16:05:55 -0700 Received: from orsmsx332.jf.intel.com (HELO orsmsx332.amr.corp.intel.com) ([192.168.65.60]) by orsmga001.jf.intel.com with ESMTP; 02 May 2006 16:05:17 -0700 X-IronPort-AV: i="4.05,81,1146466800"; d="scan'208"; a="30607765:sNHT4455187037" Received: from orsmsx411.amr.corp.intel.com ([10.22.226.47]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 2 May 2006 16:05:16 -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 Date: Tue, 2 May 2006 16:05:15 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Requirements team meeting summary Thread-Index: AcZnfgEedAZHPj0/SMWaazdF5s/3FwAQDKXAAAFnjXAAAdwCkAAIr3pAACZyafAAEamBoABTXWLQABCkxrAA94fiAA== From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 02 May 2006 23:05:16.0655 (UTC) FILETIME=[E0480FF0:01C66E3C] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [Nea] Requirements team meeting 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 Hi All Here is the summary from Requirements team first meeting last week -------------------- Attendees: Thomas, Susan, Mauricio, Ravi, Kevin, Paul, Joe, Amardeep, Hormuzd *Agenda bashing - 5 mins - looks ok *Finalize conference call day/time - 5 mins=20 Thursday 9-10 AM will be the call time for foreseeable future Next week not many folks can attend the call due to Interop & TCG meeting Folks who can attend (Amardeep, Ravi?, Kevin, Susan, Uri) *Reqs Outline comments - 10 mins=20 Looks ok Paul - only as much architecture detail as needed to define the Reqs *Architecture Use cases - 10 mins=20 Ask Ewelyn for a clarification on this Paul/Hormuzd Action Item - Do Reqs RFCs have system flows? Paul - Arch Use Cases are good to have - post this to the list Kevin - This is a brainstorming doc from the BoF Paul - send out overall use case for NEA (Hormuzd to review) *Reqs general discussion - 20 mins=20 Paul/Amardeep/Hormuzd - architecture reqs Paul/Hormuzd/Ravi - PA, PB May 19th post an initial rev - Amardeep/Susan suggestion Thomas to help out on the Security section Uri/Jeff/Thomas on security analysis Entire Team to be copied on all email discussions by subteams *Next Steps/Action Items - 10 mins All sub-teams provide initial reqs by Tuesday 9th=20 Paul to point group to TNC specs Team meeting for next week is canceled, we meet May 11th Thanks Hormuzd _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu May 04 01:51:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbWkg-0007Zb-6f; Thu, 04 May 2006 01:51:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbWkd-0007Yc-Qi for nea@ietf.org; Thu, 04 May 2006 01:51:47 -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 1FbWZM-0007Z2-BH for nea@ietf.org; Thu, 04 May 2006 01:40:09 -0400 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101-1.fm.intel.com with ESMTP; 03 May 2006 22:40:07 -0700 Received: from orsmsx334.jf.intel.com (HELO orsmsx334.amr.corp.intel.com) ([10.22.226.45]) by fmsmga001.fm.intel.com with ESMTP; 03 May 2006 22:40:07 -0700 X-IronPort-AV: i="4.05,86,1146466800"; d="scan'208"; a="32157250:sNHT31021816" Received: from orsmsx411.amr.corp.intel.com ([10.22.226.47]) by orsmsx334.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 May 2006 22:40:07 -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 Date: Wed, 3 May 2006 22:39:35 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Requirements team meeting summary Thread-Index: AcZnfgEedAZHPj0/SMWaazdF5s/3FwAQDKXAAAFnjXAAAdwCkAAIr3pAACZyafAAEamBoABTXWLQABCkxrAA94fiAABABXgQ From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 04 May 2006 05:40:07.0390 (UTC) FILETIME=[337917E0:01C66F3D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Subject: [Nea] RE: Requirements team meeting 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 I was told to provide full names for the Reqs team members that attended the call...made the correction below. Hormuzd -----Original Message----- From: Khosravi, Hormuzd M=20 Sent: Tuesday, May 02, 2006 4:05 PM To: nea@ietf.org Subject: Requirements team meeting summary Hi All Here is the summary from Requirements team first meeting last week -------------------- Attendees: Thomas Hardjono, Susan Thompson, Mauricio Sanchez, Ravi Sahita, Kevin Amorin, Paul Sangster, Joe Tardo, Amardeep Sibia, Hormuzd Khosravi *Agenda bashing - 5 mins - looks ok *Finalize conference call day/time - 5 mins=20 Thursday 9-10 AM will be the call time for foreseeable future Next week not many folks can attend the call due to Interop & TCG meeting Folks who can attend (Amardeep, Ravi?, Kevin, Susan, Uri) *Reqs Outline comments - 10 mins=20 Looks ok Paul - only as much architecture detail as needed to define the Reqs *Architecture Use cases - 10 mins=20 Ask Ewelyn for a clarification on this Paul/Hormuzd Action Item - Do Reqs RFCs have system flows? Paul - Arch Use Cases are good to have - post this to the list Kevin - This is a brainstorming doc from the BoF Paul - send out overall use case for NEA (Hormuzd to review) *Reqs general discussion - 20 mins=20 Paul/Amardeep/Hormuzd - architecture reqs Paul/Hormuzd/Ravi - PA, PB May 19th post an initial rev - Amardeep/Susan suggestion Thomas to help out on the Security section Uri/Jeff/Thomas on security analysis Entire Team to be copied on all email discussions by subteams *Next Steps/Action Items - 10 mins All sub-teams provide initial reqs by Tuesday 9th=20 Paul to point group to TNC specs Team meeting for next week is canceled, we meet May 11th Thanks Hormuzd _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu May 04 01:53:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbWm9-0007yx-Nd; Thu, 04 May 2006 01:53:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbWkQ-0007Wj-3V for nea@ietf.org; Thu, 04 May 2006 01:51:34 -0400 Received: from mga02.intel.com ([134.134.136.20] helo=orsmga101-1.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbWfy-0007kN-3l for nea@ietf.org; Thu, 04 May 2006 01:47:00 -0400 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101-1.jf.intel.com with ESMTP; 03 May 2006 22:46:57 -0700 Received: from orsmsx334.jf.intel.com (HELO orsmsx334.amr.corp.intel.com) ([10.22.226.45]) by orsmga001.jf.intel.com with ESMTP; 03 May 2006 22:46:57 -0700 X-IronPort-AV: i="4.05,86,1146466800"; d="txt'?scan'208,217"; a="31270774:sNHT35498561" Received: from orsmsx411.amr.corp.intel.com ([10.22.226.47]) by orsmsx334.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 May 2006 22:46:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C66F3E.279A332A" Date: Wed, 3 May 2006 22:46:56 -0700 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: architectural use cases/system flow diagrams Thread-Index: AcZvPicaN3aUqCp1S4uRHpxRFZVU1w== From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 04 May 2006 05:46:57.0166 (UTC) FILETIME=[27B7F2E0:01C66F3E] X-Spam-Score: 0.0 (/) X-Scan-Signature: dd887a8966a4c4c217a52303814d0b5f Subject: [Nea] architectural use cases/system flow diagrams 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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C66F3E.279A332A Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C66F3E.279A332A" ------_=_NextPart_002_01C66F3E.279A332A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All =20 One of the action items that John Vollbrecht and myself took at the NEA meeting at IETF was to brainstorm on some of the generic architectural use cases or system flows (without any specific existing framework/implementation in mind) and send it out to the list for discussion. Here it is. =20 We would appreciate comments and a lively discussion on this. Its not clear at the moment which draft these diagrams should belong to, for now we want to get some feedback and this will help with some of the Requirements definition as well. =20 =20 Thanks Hormuzd =20 ------_=_NextPart_002_01C66F3E.279A332A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All

 

One of the action items that John Vollbrecht and = myself took at the NEA meeting at IETF was to brainstorm on some of the generic = architectural use cases or system flows (without any specific existing framework/implementation in mind) and send it out to the list for = discussion. Here it is.

 

We would appreciate comments and a lively discussion = on this. Its not clear at the moment which draft these diagrams should = belong to, for now we want to get some feedback and this will help with some of the Requirements definition as well.

 

 

Thanks

Hormuzd

 

------_=_NextPart_002_01C66F3E.279A332A-- ------_=_NextPart_001_01C66F3E.279A332A Content-Type: text/plain; name="nea-architecture-usecases-1.txt" Content-Transfer-Encoding: base64 Content-Description: nea-architecture-usecases-1.txt Content-Disposition: attachment; filename="nea-architecture-usecases-1.txt" QXJjaGl0ZWN0dXJhbCBVc2UgQ2FzZXMvU3lzdGVtIEZsb3dzDQoNClRoZXNlIGFyZSBnZW5lcmlj IHVzZSBjYXNlcyBvciBzeXN0ZW0gZmxvd3MgZm9yIE5FQSwgbm90IHNwZWNpZmljIHRvIGFueSBl eGlzdGluZyBmcmFtZXdvcmsgb3IgaW1wbGVtZW50YXRpb24uDQoNCjEpIEJvb3RzdHJhcC9TdGFy dHVwIHVzZSBjYXNlDQoNClRoaXMgaXMgdGhlIHVzZSBjYXNlL3N5c3RlbSBmbG93IGRpYWdyYW0g Zm9yIGluaXRpYWwgc3lzdGVtIHN0YXJ0LXVwLiBXZSBzaG93IHNvbWUgb2YgdGhlIHNlY3VyaXR5 IGFzc29jaWF0aW9ucyB0aGF0IG5lZWQgdG8gYmUgaW4gcGxhY2UgYmVmb3JlIGFueSBvZiB0aGUg YXV0aGVudGljYXRpb24vcG9zdHVyZSBleGNoYW5nZSBjYW4gdGFrZSBwbGFjZS4NCg0KDQpQb3N0 dXJlICBDbGktQnJva2VyICBDbGllbnQgICAgICAgICAgICAgICAgICAgICAgU0Jrci1OQUEgICAg ICBwb3N0dXJlDQpjb2xsZWN0b3JzIE5BUmVxICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgUERQICAgICAgIHZhbGlkYXRvcnMNCiAgfCAgICAgICAgIHwgICAgICAgICB8ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgfA0KICB8ICAgICAgICAgfCAgICAg ICAgIHwgICAgICAgICBQRVAoTmV0RW5mb3JjZXIpICAgICB8ICAgICAgICAgICB8DQogIHxzZWMg YXNzbyB8ICAgICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgc2VjIGFzc28g IHwNCiAgfDwtLS0tLS0tPnwgICAgICAgICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAg fDwtLS0tLS0tLS0+fA0KICB8ICAgICAgICAgfCAgICAgICAgIHwgICAgICAgICAgICAgIHwgIHNl YyBhc3NvICAgICB8ICAgICAgICAgICB8DQogIHwgICAgICAgICB8ICAgICAgICAgfCAgICAgICAg ICAgICAgfDwtLS0tLS0tLS0tLS0tPnxwb3N0dXJlIHJlcXMNCiAgfCAgICAgICAgIHwgICAgICAg ICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfDwtLS0tLS0tLS0tfA0KICB8ICAgICAg ICAgfCAgICAgICAgIHwgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8PC0tLS0tLS0tLS18 DQogIHwgICAgICAgICB8ICAgICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHw8 LS0tLS0tLS0tLXwNCiAgfCAgICAgICAgIHwgICAgICAgICB8ICAgICAgICAgICAgICB8ICAgICAg ICAgICAgIHN0b3JlZCAgICAgICAgfA0KICB8ICAgICAgICAgfCAgICAgICAgIHwgICAgICAgICAg ICAgIHwgICAgICAgICAgICAgICAwICAgICAgICAgICB8DQogIHwgICAgICAgICB8ICAgICAgICAg fHJlcSBuZXQgYWNjZXNzfCAgICAgICAgICAgICAgIHwgICAgICAgICAgIHwNCiAgfCAgICAgICAg IHwgICAgICAgICB8LS0tLS0tLS0tLS0tLT58ICAgICAgICAgICAgICAgfCAgICAgICAgICAgfA0K ICB8ICAgICAgICAgfCAgICAgICAgIHwgICAgICAgICBhdXRoZW50aWNhdGlvbiAgICAgICB8ICAg ICAgICAgICB8DQogIHwgICAgICAgICB8ICAgICAgICAgfDwtLS0tLS0tLS0tLS0tfC0tLS0tLS0t LS0tLS0tPnwgICAgICAgICAgIHwNCiAgfCAgICAgICAgIHwgICAgICAgICB8ICAgICAgICBQb3N0 dXJlIFJlcSAgICAgICAgICAgfCAgICAgICAgICAgfA0KICB8ICAgICAgICAgfCBQb3MgUmVxIHw8 LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0wICAgICAgICAgICB8DQogIHwgUG9zIFJlcSB8 PC0tLS0tLS0tfCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAgICAgIHwNCiAg fDwtLS0tLS0tLXwgICAgICAgICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfCAgICAg ICAgICAgfA0KICB8PC0tLS0tLS0tfCAgICAgICAgIHwgICAgICAgICAgICAgIHwgICAgICAgICAg ICAgICB8ICAgICAgICAgICB8DQogIHw8LS0tLS0tLS18ICAgICAgICAgfCAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgIHwgICAgICAgICAgIHwNCiAgfFBvcyBSZXNwIHwgICAgICAgICB8ICAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgfCAgICAgICAgICAgfA0KICB8LS0tLS0tLS0+fCAg ICAgICAgIHwgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAgICB8DQogIHwt LS0tLS0tLT58ICAgICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAg ICAgIHwNCiAgfC0tLS0tLS0tPnxQb3MgUmVzcCB8ICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgfCAgICAgICAgICAgfA0KICB8ICAgICAgICAgfC0tLS0tLS0tPnwgICAgICAgIFBvc3R1cmUg UmVzcCAgICAgICAgICB8ICAgICAgICAgICB8DQogIHwgICAgICAgICB8ICAgICAgICAgfC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwgUG9zIFJlc3AgIHwNCiAgfCAgICAgICAgIHwgICAg ICAgICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0+fA0KICB8ICAg ICAgICAgfCAgICAgICAgIHwgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8LS0tLS0tLS0t LT58DQogIHwgICAgICAgICB8ICAgICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAg IHwtLS0tLS0tLS0tPnxQb3N0dXJlDQogIHwgICAgICAgICB8ICAgICAgICAgfCAgICAgICAgICAg ICAgfCAgICAgICAgICAgICAgIHw8LS0tLS0tLS0tLXxEaWFsb2d1ZQ0KICB8ICAgICAgICAgfCAg ICAgICAgIHwgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8PC0tLS0tLS0tLS18DQogIHwg ICAgICAgICB8ICAgICAgICAgfCBtdWx0aXBoYXNlIFBvc3R1cmUgZGlhbG9ndWUgIHw8LS0tLS0t LS0tLXwNCiAgfDwtLS0tLS0tPnw8LS0tLS0tLT58PC0tLS0tLS0tLS0tLS18LS0tLS0tLS0tLS0t LS0+fCAgICAgICAgICAgfA0KICB8PC0tLS0tLS0+fCAgICAgICAgIHwgICAgICAgICAgICAgIC4g ICAgICAgICAgICAgICB8PC0tLS0tLS0tLT58DQogIHw8LS0tLS0tLT58ICAgICAgICAgfCAgICAg ICAgICAgICAgLiAgICAgICAgICAgICAgIHw8LS0tLS0tLS0tPnwNCiAgfDwtLS0tLS0tPnwgICAg ICAgICB8ICBtdWx0aXBoYXNlIFBvc3R1cmUgZGlhbG9ndWUgfDwtLS0tLS0tLS0+fA0KICB8PC0t LS0tLS0+fDwtLS0tLS0tPnw8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT58PC0tLS0tLS0t LT58DQogIHwgICAgICAgICB8ICAgICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAg IHwgRGVjaXNpb24gIHwNCiAgfCAgICAgICAgIHwgICAgICAgICB8ICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgfDwtLS0tLS0tLS0tfA0KICB8ICAgICAgICAgfCAgICAgICAgIHwgICAgICAg IFBvc3R1cmUgRGVjaXNpb24gICAgICB8PC0tLS0tLS0tLS18DQogIHwgICAgICAgICB8IERlY2lz aW9ufDwtLS0tLS0tLS0tLS0tfDwtLS0tLS0tLS0tLS0tLXwgICAgICAgICAgIHwNCiAgfCBEZWNp c2lvbnw8LS0tLS0tLS18ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfCAgICAgICAgICAg fA0KICB8PC0tLS0tLS0tfCAgICAgICAgIHwgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8 ICAgICAgICAgICB8DQogIHw8LS0tLS0tLS18ICAgICAgICAgfCAgICAgICAgICAgICAgfCAgICAg ICAgICAgICAgIHwgICAgICAgICAgIHwNCiAgfDwtLS0tLS0tLXwgICAgICAgICB8ICAgICAgICAg ICAgICB8ICAgICAgICAgICAgICAgfCAgICAgICAgICAgfA0KICB8RGVjaXNpb24gZm9yIGNsaWVu dHwgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAgICB8DQogIHwtLS0tLS0t LS0tLS0tLS0tLS0+fCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAgICAgIHwN CiAgfC0tLS0tLS0tLS0tLS0tLS0tLT58ICAgICAgICAgIG1heSBiZT8gICAgICAgICAgICAgfCAg ICAgICAgICAgfA0KICB8ICAgICAgICAgfCAgICAgICAgIHwtLS0tLS0tLS0tLS0tPnwtLS0tLS0t LS0tLS0tLT58ICAgICAgICAgICB8DQogIHwgICAgICAgICB8ICAgICAgICAgfCAgICAgICAgICAg ICAgfCAgICAgICAgICAgICAgIHwgICAgICAgICAgIHwNCiAgfCAgICAgICAgIHwgICAgICAgICB8 ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfCAgICAgICAgICAgfA0KDQoNCjJhKSBSdW50 aW1lIHBvc3R1cmUgcmUtZXZhbHVhdGlvbiAoQ2xpZW50IHNpZGUgZXZlbnQpDQpUaGlzIGlzIGEg dXNlIGNhc2UvZmxvdyBkaWFncmFtIGZvciBydW50aW1lIHBvc3R1cmUgcmUtZXZhbHVhdGlvbiB0 cmlnZ2VyZWQgYnkgYW4gZXZlbnQgb24gdGhlIGNsaWVudCAocG9zdHVyZSBjb2xsZWN0b3IpDQoN Cg0KUG9zdHVyZSAgQ2xpLUJyb2tlciAgQ2xpZW50ICAgICAgICAgICAgICAgICAgICAgIFNCa3It TkFBICAgICAgcG9zdHVyZQ0KY29sbGVjdG9ycyBOQVJlcSAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFBEUCAgICAgICB2YWxpZGF0b3JzDQogIHwgICAgICAgICB8ICAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgIHwNCiAgfCAgICAgICBl dmVudCAgICAgICB8ZXZlbnQgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAgfA0K ICB8PC0tLS0tLS0tfDwtLS0tLS0tLTAgICAgICAgICAgICAgUEVQICAgICAgICAgICAgICB8ICAg ICAgICAgICB8DQogIHxzZWMgYXNzbyhvcHQpICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAg ICAgICAgIHwgc2VjIGFzc28gIHwNCiAgfDwtLS0tLS0tPnwgICAgICAgICB8ICAgICAgICAgICAg ICB8ICAgICAgICAgICAgICAgfDwtLS0tLS0tLS0+fA0KICB8ICAgICAgICAgfCAgICAgICAgIHwg ICAgICAgICAgICAgIHwgIHNlYyBhc3NvICAgICB8ICAgICAgICAgICB8DQogIHxQb3NVcGRhdGV8 ICAgICAgICAgfCAgICAgICAgICAgICAgfDwtLS0tLS0tLS0tLS0tPnwgICAgICAgICAgIHwNCiAg fC0tLS0tLS0tPnwgICAgICAgICB8ICAgQXN5bmMgUG9zdHVyZSBVcGRhdGUgICAgICAgfCAgICAg ICAgICAgfA0KICB8ICAgICAgICAgfC0tLS0tLS0tPnwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLT58ICAgICAgICAgICB8DQogIHwgICAgICAgICB8ICAgICAgICAgfCAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgIHwtLS0tLS0tLS0tPnxQb3N0dXJlDQogIHwgICAgICAgICB8ICAgICAg ICAgfCBtdWx0aXBoYXNlIFBvc3R1cmUgZGlhbG9ndWUgIHw8LS0tLS0tLS0tLXxEaWFsb2d1ZQ0K ICB8PC0tLS0tLS0+fDwtLS0tLS0tPnw8LS0tLS0tLS0tLS0tLXwtLS0tLS0tLS0tLS0tLT58ICAg ICAgICAgICB8DQogIHw8LS0tLS0tLT58ICAgICAgICAgfCAgICAgICAgICAgICAgLiAgICAgICAg ICAgICAgIHw8LS0tLS0tLS0tPnwNCiAgfDwtLS0tLS0tPnwgICAgICAgICB8ICAgICAgICAgICAg ICAuICAgICAgICAgICAgICAgfDwtLS0tLS0tLS0+fA0KICB8PC0tLS0tLS0+fDwtLS0tLS0tPnw8 LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT58PC0tLS0tLS0tLT58DQogIHwgICAgICAgICB8 ICAgICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAgICAgIHwNCiAg fCAgICAgICAgIHwgICAgICAgICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfE4uRGVj aXNpb24gfA0KICB8ICAgICAgICAgfCAgICAgICAgIHwgICAgIE5ldyBQb3N0dXJlIERlY2lzaW9u ICAgICB8PC0tLS0tLS0tLS18DQogIHwgICAgICAgICB8Ti5EZWNpc2lvbnw8LS0tLS0tLS0tLS0t fDwtLS0tLS0tLS0tLS0tLXwgICAgICAgICAgIHwNCiAgfE4uRGVjaXNpb258PC0tLS0tLS18ICAg ICAgICAgICAgICB8ICAgICAgICAgICAgICAgfCAgICAgICAgICAgfA0KICB8PC0tLS0tLS0tfCAg ICAgICAgIHwgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAgICB8DQogIHwg ICBOZXcgRGVjaXNpb24gICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAg ICAgIHwNCiAgfC0tLS0tLS0tLS0tLS0tLS0tLT58ICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgfCAgICAgICAgICAgfA0KICB8ICAgICAgICAgfCAgICAgICAgIHwgICAgICAgICAgbWF5IGJl PyAgICAgICAgICAgICB8ICAgICAgICAgICB8DQogIHwgICAgICAgICB8ICAgICAgICAgfC0tLS0t LS0tLS0tLS0+fC0tLS0tLS0tLS0tLS0tPnwgICAgICAgICAgIHwNCiAgfCAgICAgICAgIHwgICAg ICAgICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfCAgICAgICAgICAgfA0KICB8ICAg ICAgICAgfCAgICAgICAgIHwgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAg ICB8DQoNCjJiKSBSdW50aW1lIHBvc3R1cmUgcmUtZXZhbHVhdGlvbiAoU2VydmVyIHNpZGUgZXZl bnQpDQpUaGlzIGlzIGEgdXNlIGNhc2UvZmxvdyBkaWFncmFtIGZvciBydW50aW1lIHBvc3R1cmUg cmUtZXZhbHVhdGlvbiB0cmlnZ2VyZWQgYnkgYW4gZXZlbnQgb24gdGhlIHNlcnZlciAocG9zdHVy ZSB2YWxpZGF0b3IpDQoNCg0KUG9zdHVyZSAgQ2xpLUJyb2tlciAgQ2xpZW50ICAgICAgICAgICAg ICAgICAgICAgIFNCa3ItTkFBICAgICAgcG9zdHVyZQ0KY29sbGVjdG9ycyBOQVJlcSAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFBEUCAgICAgICB2YWxpZGF0b3JzDQogIHwgICAg ICAgICB8ICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgICAg IHwNCiAgfCAgICAgICAgIHwgICAgICAgICB8ICAgICAgICAgICAgIFBFUCAgICAgICAgICAgICAg fCAgICAgICAgICAgfA0KICB8c2VjIGFzc28gfCAgICAgICAgIHwgICAgICAgICAgICAgIHwgICAg ICAgICAgICAgICB8IHNlYyBhc3NvICB8DQogIHw8LS0tLS0tLT58ICAgICAgICAgfCAgICAgICAg ICAgICAgfCAgICAgICAgICAgICAgIHw8LS0tLS0tLS0tPnwNCiAgfCAgICAgICAgIHwgICAgICAg ICB8ICAgICAgICAgICAgICB8ICBzZWMgYXNzbyAgICAgfCAgICAgICAgICAgfA0KICB8ICAgICAg ICAgfCAgICAgICAgIHwgICAgICAgICAgICAgIHw8LS0tLS0tLS0tLS0tLT58ICAgICAgICAgICB8 DQogIHwgICAgICAgICB8ICAgICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHxO ZXcgUG9zUmVxIDBldmVudA0KICB8ICAgICAgICAgfCAgICAgICAgIHwgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICB8PC0tLS0tLS0tLS18DQogIHwgICAgICAgICB8ICAgICAgICAgfCAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgIHwgc2VjIGFzc28ob3B0KQ0KICB8ICAgICAgICAgfCAg ICAgICAgIHwgICAgICAgTmV3IFBvc3R1cmUgUmVxICAgICAgICB8PC0tLS0tLS0tLT58DQogIHwg ICAgICAgICB8IFBvcyBSZXEgfDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTAgICAgICAg ICAgIHwNCiAgfCBQb3MgUmVxIHw8LS0tLS0tLS18ICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgfCAgICAgICAgICAgfA0KICB8PC0tLS0tLS0tfCAgICAgICAgIHwgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICB8ICAgICAgICAgICB8DQogIHxQb3MgUmVzcCB8ICAgICAgICAgfCAgICAg ICAgICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAgICAgIHwNCiAgfC0tLS0tLS0tPnxQb3Mg UmVzcCB8ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfCAgICAgICAgICAgfA0KICB8ICAg ICAgICAgfC0tLS0tLS0tPnwgICAgICAgTmV3IFBvc3R1cmUgUmVzcCAgICAgICB8ICAgICAgICAg ICB8DQogIHwgICAgICAgICB8ICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t PnwgUG9zIFJlc3AgIHwNCiAgfCAgICAgICAgIHwgICAgICAgICB8ICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICAgfC0tLS0tLS0tLS0+fFBvc3R1cmUNCiAgfCAgICAgICAgIHwgICAgICAgICB8 ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfDwtLS0tLS0tLS0tfERpYWxvZ3VlDQogIHwg ICAgICAgICB8ICAgICAgICAgfCBtdWx0aXBoYXNlIFBvc3R1cmUgZGlhbG9ndWUgIHwgICAgICAg ICAgIHwNCiAgfDwtLS0tLS0tPnw8LS0tLS0tLT58PC0tLS0tLS0tLS0tLS18LS0tLS0tLS0tLS0t LS0+fCAgICAgICAgICAgfA0KICB8PC0tLS0tLS0+fCAgICAgICAgIHwgICAgICAgICAgICAgIC4g ICAgICAgICAgICAgICB8PC0tLS0tLS0tLT58DQogIHw8LS0tLS0tLT58ICAgICAgICAgfCAgICAg ICAgICAgICAgLiAgICAgICAgICAgICAgIHw8LS0tLS0tLS0tPnwNCiAgfDwtLS0tLS0tPnw8LS0t LS0tLT58PC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+fDwtLS0tLS0tLS0+fA0KICB8ICAg ICAgICAgfCAgICAgICAgIHwgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8ICAgICAgICAg ICB8DQogIHwgICAgICAgICB8ICAgICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAg IHxOLkRlY2lzaW9uIHwNCiAgfCAgICAgICAgIHwgICAgICAgICB8ICAgICBOZXcgUG9zdHVyZSBE ZWNpc2lvbiAgICAgfDwtLS0tLS0tLS0tfA0KICB8ICAgICAgICAgfE4uRGVjaXNpb258PC0tLS0t LS0tLS0tLXw8LS0tLS0tLS0tLS0tLS18ICAgICAgICAgICB8DQogIHxOLkRlY2lzaW9ufDwtLS0t LS0tfCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAgICAgIHwNCiAgfDwtLS0t LS0tLXwgICAgICAgICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfCAgICAgICAgICAg fA0KICB8ICAgTmV3IERlY2lzaW9uICAgIHwgICAgICAgICAgICAgIHwgICAgICAgICAgICAgICB8 ICAgICAgICAgICB8DQogIHwtLS0tLS0tLS0tLS0tLS0tLS0+fCAgICAgICAgICAgICAgfCAgICAg ICAgICAgICAgIHwgICAgICAgICAgIHwNCiAgfCAgICAgICAgIHwgICAgICAgICB8ICAgICAgICAg IG1heSBiZT8gICAgICAgICAgICAgfCAgICAgICAgICAgfA0KICB8ICAgICAgICAgfCAgICAgICAg IHwtLS0tLS0tLS0tLS0tPnwtLS0tLS0tLS0tLS0tLT58ICAgICAgICAgICB8DQogIHwgICAgICAg ICB8ICAgICAgICAgfCAgICAgICAgICAgICAgfCAgICAgICAgICAgICAgIHwgICAgICAgICAgIHwN CiAgfCAgICAgICAgIHwgICAgICAgICB8ICAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgfCAg ICAgICAgICAgfA0KDQoNCg0K ------_=_NextPart_001_01C66F3E.279A332A Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea ------_=_NextPart_001_01C66F3E.279A332A-- From nea-bounces@ietf.org Mon May 08 17:57:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdDiy-0006jJ-IO; Mon, 08 May 2006 17:57:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdDiw-0006iy-PE for nea@ietf.org; Mon, 08 May 2006 17:57:02 -0400 Received: from palrel12.hp.com ([156.153.255.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdDis-000413-BX for nea@ietf.org; Mon, 08 May 2006 17:57:02 -0400 Received: from cacexg13.americas.cpqcorp.net (cacexg13.americas.cpqcorp.net [16.92.1.76]) by palrel12.hp.com (Postfix) with ESMTP id AD2F636407 for ; Mon, 8 May 2006 14:56:55 -0700 (PDT) Received: from cacexc08.americas.cpqcorp.net ([16.92.1.35]) by cacexg13.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 May 2006 14:56:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Nea] architectural use cases/system flow diagrams Date: Mon, 8 May 2006 14:56:53 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] architectural use cases/system flow diagrams Thread-Index: AcZvPicaN3aUqCp1S4uRHpxRFZVU1wDrAqMg From: "Sanchez, Mauricio (ProCurve)" To: "Khosravi, Hormuzd M" , X-OriginalArrivalTime: 08 May 2006 21:56:55.0302 (UTC) FILETIME=[5229C260:01C672EA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9af087f15dbdd4c64ae6bbcdbc5b1d44 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: , Content-Type: multipart/mixed; boundary="===============0674871365==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============0674871365== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C672EA.522C22FF" This is a multi-part message in MIME format. ------_=_NextPart_001_01C672EA.522C22FF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Homuzd, John, =20 >From these docs it looks like we're re-inventing the wheel again. Has any consideration been made on pulling in use cases from the TNC side of things? Perhaps to also consider from the CNAC team. =20 To me it seems we're defining a new architecture all over again rather than pulling in what already exists and evaluating is leveragability. =20 MS ________________________________ From: Khosravi, Hormuzd M [mailto:hormuzd.m.khosravi@intel.com]=20 Sent: Wednesday, May 03, 2006 10:47 PM To: nea@ietf.org Subject: [Nea] architectural use cases/system flow diagrams =09 =09 Hi All =20 One of the action items that John Vollbrecht and myself took at the NEA meeting at IETF was to brainstorm on some of the generic architectural use cases or system flows (without any specific existing framework/implementation in mind) and send it out to the list for discussion. Here it is. =20 We would appreciate comments and a lively discussion on this. Its not clear at the moment which draft these diagrams should belong to, for now we want to get some feedback and this will help with some of the Requirements definition as well. =20 =20 Thanks Hormuzd =20 ------_=_NextPart_001_01C672EA.522C22FF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Homuzd,=20 John,
 
From these docs it looks like = we're re-inventing the wheel again.  = Has any=20 consideration been made on pulling in use cases from the TNC side of=20 things?  Perhaps to also consider from the CNAC = team.
 
To me it seems we're defining a new architecture all over again = rather=20 than pulling in what already exists and = evaluating is leveragability.
 
MS

From: Khosravi, Hormuzd M=20 [mailto:hormuzd.m.khosravi@intel.com]
Sent: Wednesday, May = 03, 2006=20 10:47 PM
To: nea@ietf.org
Subject: [Nea] = architectural use=20 cases/system flow diagrams

Hi All

 

One of the action items = that John=20 Vollbrecht and myself took at the NEA meeting at IETF was to = brainstorm on=20 some of the generic architectural use cases or system flows (without = any=20 specific existing framework/implementation in mind) and send it out to = the=20 list for discussion. Here it is.

 

We would appreciate = comments and a=20 lively discussion on this. Its not clear at the moment which draft = these=20 diagrams should belong to, for now we want to get some feedback and = this will=20 help with some of the Requirements definition as = well.

 

 

Thanks

Hormuzd

 

------_=_NextPart_001_01C672EA.522C22FF-- --===============0674871365== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea --===============0674871365==-- From nea-bounces@ietf.org Tue May 09 01:53:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdL9Z-0003RW-3z; Tue, 09 May 2006 01:53:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdL9M-0003JI-1L for nea@ietf.org; Tue, 09 May 2006 01:52:48 -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 1FdL1a-0003Eq-Nm for nea@ietf.org; Tue, 09 May 2006 01:44:49 -0400 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101-1.fm.intel.com with ESMTP; 08 May 2006 22:44:45 -0700 Received: from orsmsx331.jf.intel.com (HELO orsmsx331.amr.corp.intel.com) ([192.168.65.56]) by fmsmga001.fm.intel.com with ESMTP; 08 May 2006 22:44:45 -0700 X-IronPort-AV: i="4.05,103,1146466800"; d="scan'208,217"; a="34347978:sNHT31804465" Received: from orsmsx411.amr.corp.intel.com ([10.22.226.47]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 8 May 2006 22:44:45 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Nea] architectural use cases/system flow diagrams Date: Mon, 8 May 2006 22:44:44 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] architectural use cases/system flow diagrams Thread-Index: AcZvPicaN3aUqCp1S4uRHpxRFZVU1wDrAqMgABAC1jA= From: "Khosravi, Hormuzd M" To: "Sanchez, Mauricio \(ProCurve\)" , X-OriginalArrivalTime: 09 May 2006 05:44:45.0224 (UTC) FILETIME=[AD23F280:01C6732B] X-Spam-Score: 0.0 (/) X-Scan-Signature: e9d8c60d9288f2c774f26bab15869505 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: , Content-Type: multipart/mixed; boundary="===============0351450028==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============0351450028== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6732B.ACC7D518" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6732B.ACC7D518 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mauricio =20 The goal is to leverage existing architectures and make them interoperate. One way to achieve that goal is to define Requirements (System Flows in this particular case) without any particular architecture in mind and then figure out how we can leverage existing architectures to satisfy those requirements or scenarios. Obviously, in some cases the existing architectures/implementations may require some changes in order to meet the requirements or interoperate, but we have to do that in order to achieve the ultimate goal of interoperability. =20 So the next thing I would expect to be discussed in this context is how TNC & NAC would fit in with these particular use cases and we go from there. =20 Let me know if that sounds good, Also if you can provide a TNC example to this list that would be great. =20 Thanks Hormuzd =20 ________________________________ From: Sanchez, Mauricio (ProCurve) [mailto:mauricio.sanchez@hp.com]=20 Sent: Monday, May 08, 2006 2:57 PM To: Khosravi, Hormuzd M; nea@ietf.org Subject: RE: [Nea] architectural use cases/system flow diagrams =20 Homuzd, John, =20 >From these docs it looks like we're re-inventing the wheel again. Has any consideration been made on pulling in use cases from the TNC side of things? Perhaps to also consider from the CNAC team. =20 To me it seems we're defining a new architecture all over again rather than pulling in what already exists and evaluating is leveragability. =20 MS =20 =09 ________________________________ From: Khosravi, Hormuzd M [mailto:hormuzd.m.khosravi@intel.com]=20 Sent: Wednesday, May 03, 2006 10:47 PM To: nea@ietf.org Subject: [Nea] architectural use cases/system flow diagrams Hi All =20 One of the action items that John Vollbrecht and myself took at the NEA meeting at IETF was to brainstorm on some of the generic architectural use cases or system flows (without any specific existing framework/implementation in mind) and send it out to the list for discussion. Here it is. =20 We would appreciate comments and a lively discussion on this. Its not clear at the moment which draft these diagrams should belong to, for now we want to get some feedback and this will help with some of the Requirements definition as well. =20 =20 Thanks Hormuzd =20 ------_=_NextPart_001_01C6732B.ACC7D518 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mauricio

 

The goal is to leverage existing architectures and make them interoperate. One way to achieve that goal = is to define Requirements (System Flows in this particular case) without any particular architecture in mind and then figure out how we can leverage existing architectures to satisfy those requirements or = scenarios.

Obviously, in some cases the = existing architectures/implementations may require some changes in order to meet = the requirements or interoperate, but we have to do that in order to achieve = the ultimate goal of interoperability.

 

So the next thing I would expect to = be discussed in this context is how TNC & NAC would fit in with these particular use cases and we go from there.

 

Let me know if that sounds good, = Also if you can provide a TNC example to this list that would be = great.

 

Thanks

Hormuzd

 

From: = Sanchez, Mauricio (ProCurve) [mailto:mauricio.sanchez@hp.com]
Sent: Monday, May 08, = 2006 2:57 PM
To: Khosravi, Hormuzd M; = nea@ietf.org
Subject: RE: [Nea] = architectural use cases/system flow diagrams

 

Homuzd, John,

 

From these docs it looks like = we're re-inventing the wheel again.  Has any consideration been made on pulling in use = cases from the TNC side of things?  Perhaps to also consider from the = CNAC team.

 

To me it seems we're defining a new architecture all over again rather than pulling in what already exists = and evaluating is leveragability.

 

MS

=

 

From: Khosravi, Hormuzd M = [mailto:hormuzd.m.khosravi@intel.com]
Sent: Wednesday, May 03, = 2006 10:47 PM
To: nea@ietf.org
Subject: [Nea] = architectural use cases/system flow diagrams

Hi All

 

One of the action items that John Vollbrecht and = myself took at the NEA meeting at IETF was to brainstorm on some of the generic architectural use cases or system flows (without any specific existing framework/implementation in mind) and send it out to the list for = discussion. Here it is.

 

We would appreciate comments and a lively discussion = on this. Its not clear at the moment which draft these diagrams should = belong to, for now we want to get some feedback and this will help with some of the Requirements definition as well.

 

 

Thanks

Hormuzd

 

------_=_NextPart_001_01C6732B.ACC7D518-- --===============0351450028== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea --===============0351450028==-- From nea-bounces@ietf.org Tue May 09 13:18:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdVr2-0005wk-Cs; Tue, 09 May 2006 13:18:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdVr1-0005wX-6R for nea@ietf.org; Tue, 09 May 2006 13:18:35 -0400 Received: from mail.signacert.org ([207.162.214.7] helo=mail.signacert.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdVr0-0003Ay-Eq for nea@ietf.org; Tue, 09 May 2006 13:18:35 -0400 Received: from SLEDGEHAMMER.signacert.com (sledgehammer.signacert.com [70.103.105.28]) by mail.signacert.com (Postfix) with ESMTP id 731AE18EC466; Tue, 9 May 2006 10:18:30 -0700 (PDT) Content-class: urn:content-classes:message Subject: RE: [Nea] architectural use cases/system flow diagrams MIME-Version: 1.0 Date: Tue, 9 May 2006 10:18:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <6874726B1AE3D441A3B4635B527E09B135A4@sledgehammer.signacert.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] architectural use cases/system flow diagrams Thread-Index: AcZvPicaN3aUqCp1S4uRHpxRFZVU1wDrAqMgABAC1jAAGF8moA== From: "Thomas Hardjono" To: "Khosravi, Hormuzd M" , "Sanchez, Mauricio (ProCurve)" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 509eeaf340e89c687918a6101c6def35 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: , Content-Type: multipart/mixed; boundary="===============0346020318==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============0346020318== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6738C.97C228BC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6738C.97C228BC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes, we definitely don't want a 4th architecture out there (besides CNAC, TNC and NAP). The Market and the analysts are already confused as it is :) =20 My understanding from the BOF was that we had to write a requirements document (not an architecture document). =20 We then had to decide on specific protocols or EAP-methods to get interoperability across peer layers. =20 /thomas/ ________________________________ From: Khosravi, Hormuzd M [mailto:hormuzd.m.khosravi@intel.com]=20 Sent: Monday, May 08, 2006 10:45 PM To: Sanchez, Mauricio (ProCurve); nea@ietf.org Subject: RE: [Nea] architectural use cases/system flow diagrams Hi Mauricio =20 The goal is to leverage existing architectures and make them interoperate. One way to achieve that goal is to define Requirements (System Flows in this particular case) without any particular architecture in mind and then figure out how we can leverage existing architectures to satisfy those requirements or scenarios. Obviously, in some cases the existing architectures/implementations may require some changes in order to meet the requirements or interoperate, but we have to do that in order to achieve the ultimate goal of interoperability. =20 So the next thing I would expect to be discussed in this context is how TNC & NAC would fit in with these particular use cases and we go from there. =20 Let me know if that sounds good, Also if you can provide a TNC example to this list that would be great. =20 Thanks Hormuzd =20 ________________________________ From: Sanchez, Mauricio (ProCurve) [mailto:mauricio.sanchez@hp.com]=20 Sent: Monday, May 08, 2006 2:57 PM To: Khosravi, Hormuzd M; nea@ietf.org Subject: RE: [Nea] architectural use cases/system flow diagrams =20 Homuzd, John, =20 >From these docs it looks like we're re-inventing the wheel again. Has any consideration been made on pulling in use cases from the TNC side of things? Perhaps to also consider from the CNAC team. =20 To me it seems we're defining a new architecture all over again rather than pulling in what already exists and evaluating is leveragability. =20 MS =20 =09 ________________________________ From: Khosravi, Hormuzd M [mailto:hormuzd.m.khosravi@intel.com]=20 Sent: Wednesday, May 03, 2006 10:47 PM To: nea@ietf.org Subject: [Nea] architectural use cases/system flow diagrams Hi All =20 One of the action items that John Vollbrecht and myself took at the NEA meeting at IETF was to brainstorm on some of the generic architectural use cases or system flows (without any specific existing framework/implementation in mind) and send it out to the list for discussion. Here it is. =20 We would appreciate comments and a lively discussion on this. Its not clear at the moment which draft these diagrams should belong to, for now we want to get some feedback and this will help with some of the Requirements definition as well. =20 =20 Thanks Hormuzd =20 ------_=_NextPart_001_01C6738C.97C228BC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Yes, we definitely don't want a 4th = architecture out there=20 (besides CNAC, TNC and NAP). The Market and the analysts are already = confused as=20 it is :)
 
My understanding from the BOF was that we had = to write a=20 requirements document (not an architecture = document).
 
We then had to decide on specific protocols or = EAP-methods=20 to get interoperability across peer layers.
 
/thomas/

From: Khosravi, Hormuzd M=20 [mailto:hormuzd.m.khosravi@intel.com]
Sent: Monday, May 08, = 2006=20 10:45 PM
To: Sanchez, Mauricio (ProCurve);=20 nea@ietf.org
Subject: RE: [Nea] architectural use cases/system = flow=20 diagrams

Hi=20 Mauricio

 

The goal is = to leverage=20 existing architectures and make them interoperate. One way to achieve = that goal=20 is to define Requirements (System Flows in this particular case) without = any=20 particular architecture in mind and then figure out how we can leverage = existing=20 architectures to satisfy those requirements or = scenarios.

Obviously, in = some=20 cases the existing architectures/implementations may require some = changes in=20 order to meet the requirements or interoperate, but we have to do that = in order=20 to achieve the ultimate goal of interoperability.

 

So the next = thing I=20 would expect to be discussed in this context is how TNC & NAC would = fit in=20 with these particular use cases and we go from there.

 

Let me know = if that=20 sounds good, Also if you can provide a TNC example to this list that = would be=20 great.

 

Thanks

Hormuzd

 

From: Sanchez,=20 Mauricio (ProCurve) [mailto:mauricio.sanchez@hp.com]
Sent: Monday, May 08, 2006 2:57=20 PM
To: Khosravi, = Hormuzd M;=20 nea@ietf.org
Subject: = RE: [Nea]=20 architectural use cases/system flow diagrams

 

Homuzd,=20 John,

 

From these = docs it=20 looks like we're re-inventing the wheel again.  Has any = consideration=20 been made on pulling in use cases from the TNC side of things?  = Perhaps to=20 also consider from the CNAC team.

 

To me it = seems we're=20 defining a new architecture all over again rather than pulling in what = already=20 exists and evaluating is leveragability.

 

MS

 

From:=20 Khosravi, Hormuzd M [mailto:hormuzd.m.khosravi@intel.com]
Sent: Wednesday, May 03, 2006 = 10:47=20 PM
To:=20 nea@ietf.org
Subject: [Nea]=20 architectural use cases/system flow diagrams

Hi All

 

One of the action items = that John=20 Vollbrecht and myself took at the NEA meeting at IETF was to = brainstorm on=20 some of the generic architectural use cases or system flows (without = any=20 specific existing framework/implementation in mind) and send it out to = the=20 list for discussion. Here it is.

 

We would appreciate = comments and a=20 lively discussion on this. Its not clear at the moment which draft = these=20 diagrams should belong to, for now we want to get some feedback and = this will=20 help with some of the Requirements definition as = well.

 

 

Thanks

Hormuzd

 

------_=_NextPart_001_01C6738C.97C228BC-- --===============0346020318== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea --===============0346020318==-- From nea-bounces@ietf.org Thu May 11 12:16:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeDqH-0008Op-5h; Thu, 11 May 2006 12:16:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeDqG-0008Ok-Mp for nea@ietf.org; Thu, 11 May 2006 12:16:44 -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 1FeDqF-0000WL-EK for nea@ietf.org; Thu, 11 May 2006 12:16:44 -0400 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101-1.fm.intel.com with ESMTP; 11 May 2006 09:16:38 -0700 Received: from orsmsx331.jf.intel.com (HELO orsmsx331.amr.corp.intel.com) ([192.168.65.56]) by fmsmga001.fm.intel.com with ESMTP; 11 May 2006 09:14:41 -0700 X-IronPort-AV: i="4.05,116,1146466800"; d="scan'208"; a="35761268:sNHT8455683222" Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 11 May 2006 09:14:05 -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 Date: Thu, 11 May 2006 09:14:04 -0700 Message-ID: <96E39AF1B99FDC47A38DDAB22C3E70CA07C44D01@orsmsx408> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: trying again - PA PB requirements strawman Thread-Index: AcZ1FT0s6eSfJH3wQWCjCwHMaJgmJAAAI/cA From: "Sahita, Ravi" To: X-OriginalArrivalTime: 11 May 2006 16:14:05.0752 (UTC) FILETIME=[ECFEC380:01C67515] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Nea] trying again - PA PB requirements strawman 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 folks, here is a strawman to start discussion in the sub-group interested in drafting PA, PB requirements. Please provide feedback, this is a very basic list to start discussion =20 thanks Ravi =20 Posture Attributes protocol high level requirements: This protocol is used to carry posture attributes between a particular Posture Collector in a NEA client and a particular Posture Validator in a NEA Server. The PA protocol is carried inside the PB protocol. 1. Support expresssion of component health at a coarse level, including vendor, version, operational status 2. Support expresssion of sub-component health including vendor, component, version, operational status 3. Support expresssion of meta-data around updates for components such as last update time, remediation server used 4. Support expression of asynchronous events from collector or validator =20 Posture Broker protocol high level requirements: This protocol aggregates posture attributes from one or more Posture Collectors in an NEA client and sends them to the NEA server for assessment by one or more Posture Validators. 1. Support collection of posture information from multiple posture collectors 2. Support collection of posture resolution from multiple posture validators 3. Support registration, deregistration of posture collectors and validators 4. Support subscription on the NEA server for information from posture collectors 5. Support multiple rounds of posture collection from collectors 6. Support asynchronous push of posture/event information from collectors/NEA client 7. Support asynchronous pull of posture information from validators/NEA server =20 =20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu May 11 13:32:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeF1Y-0002gH-6h; Thu, 11 May 2006 13:32:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeF1W-0002gC-FJ for nea@ietf.org; Thu, 11 May 2006 13:32:26 -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 1FeF1V-00048m-Ll for nea@ietf.org; Thu, 11 May 2006 13:32:26 -0400 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101-1.fm.intel.com with ESMTP; 11 May 2006 10:31:05 -0700 Received: from fmsmsx332.fm.intel.com (HELO fmsmsx332.amr.corp.intel.com) ([132.233.42.148]) by fmsmga001.fm.intel.com with ESMTP; 11 May 2006 10:25:25 -0700 X-IronPort-AV: i="4.05,116,1146466800"; d="scan'208"; a="35800702:sNHT4842866112" Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 May 2006 10:25:24 -0700 Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 May 2006 10:25:24 -0700 Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 11 May 2006 13:25:22 -0400 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] trying again - PA PB requirements strawman Date: Thu, 11 May 2006 13:25:21 -0400 Message-ID: <279DDDAFA85EC74C9300A0598E70405608D858@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] trying again - PA PB requirements strawman Thread-Index: AcZ1FT0s6eSfJH3wQWCjCwHMaJgmJAAAI/cAAAJ51mA= From: "Blumenthal, Uri" To: "Sahita, Ravi" , X-OriginalArrivalTime: 11 May 2006 17:25:22.0955 (UTC) FILETIME=[E26825B0:01C6751F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 I agree - especially with the Posture Broker req's. We'll need all of what you've listed.=20 -----Original Message----- From: Sahita, Ravi [mailto:ravi.sahita@intel.com]=20 Sent: Thursday, May 11, 2006 9:14 AM To: nea@ietf.org Subject: [Nea] trying again - PA PB requirements strawman folks, here is a strawman to start discussion in the sub-group interested in drafting PA, PB requirements. Please provide feedback, this is a very basic list to start discussion =20 thanks Ravi =20 Posture Attributes protocol high level requirements: This protocol is used to carry posture attributes between a particular Posture Collector in a NEA client and a particular Posture Validator in a NEA Server. The PA protocol is carried inside the PB protocol. 1. Support expresssion of component health at a coarse level, including vendor, version, operational status 2. Support expresssion of sub-component health including vendor, component, version, operational status 3. Support expresssion of meta-data around updates for components such as last update time, remediation server used 4. Support expression of asynchronous events from collector or validator =20 Posture Broker protocol high level requirements: This protocol aggregates posture attributes from one or more Posture Collectors in an NEA client and sends them to the NEA server for assessment by one or more Posture Validators. 1. Support collection of posture information from multiple posture collectors 2. Support collection of posture resolution from multiple posture validators 3. Support registration, deregistration of posture collectors and validators 4. Support subscription on the NEA server for information from posture collectors 5. Support multiple rounds of posture collection from collectors 6. Support asynchronous push of posture/event information from collectors/NEA client 7. Support asynchronous pull of posture information from validators/NEA server =20 =20 _______________________________________________ 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 May 11 13:50:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeFJG-0000dj-4l; Thu, 11 May 2006 13:50:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeFJF-0000dd-IM for nea@ietf.org; Thu, 11 May 2006 13:50:45 -0400 Received: from smtp.mail.umich.edu ([141.211.14.81] helo=hackers.mr.itd.umich.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeFJE-0004ol-9U for nea@ietf.org; Thu, 11 May 2006 13:50:45 -0400 Received: FROM [198.108.62.240] (dhcp62-240.merit.edu [198.108.62.240]) BY hackers.mr.itd.umich.edu ID 44637935.C15E1.4520 ; 11 May 2006 13:49:42 -0400 In-Reply-To: <96E39AF1B99FDC47A38DDAB22C3E70CA07C44D01@orsmsx408> References: <96E39AF1B99FDC47A38DDAB22C3E70CA07C44D01@orsmsx408> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6C414F79-96B9-4196-9065-00984C366C6B@umich.edu> Content-Transfer-Encoding: 7bit From: John Vollbrecht Subject: Re: [Nea] trying again - PA PB requirements strawman Date: Thu, 11 May 2006 13:49:40 -0400 To: "Sahita, Ravi" X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 Ravi - Thanks for doing this. Some comments for discussion in line below -- John On May 11, 2006, at 12:14 PM, Sahita, Ravi wrote: > folks, > here is a strawman to start discussion in the sub-group interested in > drafting PA, PB requirements. Please provide feedback, this is a very > basic list to start discussion > > thanks > Ravi > > Posture Attributes protocol high level requirements: > This protocol is used to carry posture attributes between a particular > Posture Collector in a NEA client and a particular Posture > Validator in > a NEA Server. The PA protocol is carried inside the PB protocol. Is PB's only purpose is to carry PA or does it have additional purposes? > 1. Support expresssion of component health at a coarse level, > including > vendor, version, operational status > 2. Support expresssion of sub-component health including vendor, > component, version, operational status > 3. Support expresssion of meta-data around updates for components such > as last update time, remediation server used > 4. Support expression of asynchronous events from collector or > validator does the PA protocol include expressing results to the broker protocol or just between PC and PV? Do we need to define how decisions about posture are made based on the results of posture evalutations? > > Posture Broker protocol high level requirements: > This protocol aggregates posture attributes from one or more Posture > Collectors in an NEA client and sends them to the NEA server for > assessment by one or more Posture Validators. > 1. Support collection of posture information from multiple posture > collectors > 2. Support collection of posture resolution from multiple posture > validators > 3. Support registration, deregistration of posture collectors and > validators > 4. Support subscription on the NEA server for information from posture > collectors > 5. Support multiple rounds of posture collection from collectors > 6. Support asynchronous push of posture/event information from > collectors/NEA client > 7. Support asynchronous pull of posture information from validators/ > NEA > server > a similar question to the one for PA. Does Posture Broker express its opinion about aggregation of Posture validations? Also, does the PB accept input from things other than PA or does some other server element incorporate other information [like user authentication and time-of-day rules]? John > > > _______________________________________________ > 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 Wed May 17 17:59:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgU3W-0007l3-7r; Wed, 17 May 2006 17:59:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgU3V-0007ky-Bn for nea@ietf.org; Wed, 17 May 2006 17:59:45 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgU3U-0005o4-1Q for nea@ietf.org; Wed, 17 May 2006 17:59:45 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 17 May 2006 14:59:43 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,139,1146466800"; d="scan'208"; a="551461235:sNHT22411784" 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, 17 May 2006 17:59:41 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revised draft NEA charter Thread-Index: AcZ5/TK96YKZLzFqSlWmAS+rsP1glQ== From: "Stephen Hanna" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Subject: [Nea] Revised draft NEA charter 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 Folks, Susan and I have revised the draft NEA WG charter to reflect the consensus of the mailing list as reflected in the NEA Action Plan agreed to in April. Please review this draft and send feedback ASAP. Of course, we can revise the charter up to Montreal but I'd like to get a solid version by Friday so we can submit our BOF proposal on Monday as the IESG has requested. Thanks, Steve ------------- Draft NEA WG Charter May 17, 2006 Version Network Endpoint Assessment (NEA) architectures have been implemented in the industry to assess the "posture" of endpoint devices for the purposes of monitoring or enforcing compliance to an organization's policy for access to the network. Posture refers to the hardware or software configuration of an endpoint as it pertains to an organization's security policy. Posture may include knowledge about the types of hardware and software installed and their configurations, e.g. OS name and version, application patch levels, and anti-virus signature file version. On network access, an endpoint with an NEA Client can be queried for posture information which is validated on an NEA Server as part of network access control. Since NEA involves many different components from different vendors, interoperation between NEA architectures and implementations is highly desirable. Given that well-established protocols already exist for the lowest layers in the NEA architectures (such as EAP and RADIUS), the priority of the NEA working group is to standardize protocols at the higher layers in the architectures (known as PA and PB and described later). When used with the existing standards for lower layers, these new protocols will allow interoperability between an NEA Client from one vendor and an NEA Server from another. Since there are already several existing protocols at these higher layers, the NEA working group will consider these existing protocols as candidates for standardization. A requirements document will be written and used as a basis for evaluating the candidate protocols. The working group may decide to standardize one of the candidate protocols, use one of them as a basis for a new or revised protocol, or decide that a new protocol is needed. The NEA Requirements document will include a problem statement, definition of terms, requirements for PA, PB, and an overall security analysis. It will also include requirements for the protocol transporting PA, PB (known as PTT and described below). PA, the Posture Attribute protocol, consists of posture attributes that are carried between a particular Posture Collector in a NEA client and a particular Posture Validator in a NEA Server. The PA protocol is carried inside the PB protocol. Certain posture attributes will be standardized to ensure interoperability but vendor-specific attributes will also be supported. PB, the Posture Broker protocol, aggregates posture attributes from one or more Posture Collectors in an NEA client and sends them to the NEA server for assessment by one or more Posture Validators. PTT, the Posture Transport Tunnel protocol is a transport protocol suitable for carrying the PB protocol at or after network connection. Milestones: June 2006: * Submit first version of NEA Requirements I-D July 2006: * Agree on charter and milestones at IETF 66 September 2006: * WG Last Call on NEA Requirements I-D=20 October 2006: * Deadline for submission of candidate specs for PA and PB * Submit first version of NEA Evaluation I-D=20 November 2006: * Review NEA Evaluation I-D at IETF 67 December 2006: * WG Last Call on NEA Evaluation I-D January 2007: * Submit NEA Requirements I-D and Evaluation I-D to IESG as Info RFC * Submit first draft of PA and PB specs for review March 2007: * Discuss unresolved issues with PA and PB specs at IETF 68 * Agree on solutions to unresolved issues with PA and PB specs April 2007: * Submit revised draft of PA and PB specs June 2007 * WG Last Call on PA and PB specs July 2007 * Resolve outstanding Last Call comments on requirements I-D at IETF 69 August 2007: * Submit PA and PB specs to IESG for publication as Proposed _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed May 17 18:08:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgUBV-0002Ft-52; Wed, 17 May 2006 18:08:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgUBT-0002Fo-Ug for nea@ietf.org; Wed, 17 May 2006 18:07:59 -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 1FgUBS-0006Fl-2G for nea@ietf.org; Wed, 17 May 2006 18:07:59 -0400 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101-1.fm.intel.com with ESMTP; 17 May 2006 15:07:55 -0700 Received: from fmsmsx332.fm.intel.com (HELO fmsmsx332.amr.corp.intel.com) ([132.233.42.148]) by fmsmga001.fm.intel.com with ESMTP; 17 May 2006 15:06:47 -0700 X-IronPort-AV: i="4.05,139,1146466800"; d="scan'208"; a="38836852:sNHT1306729739" Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 May 2006 15:06:07 -0700 Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 May 2006 15:06:06 -0700 Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 May 2006 18:06:05 -0400 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] Revised draft NEA charter Date: Wed, 17 May 2006 18:05:57 -0400 Message-ID: <279DDDAFA85EC74C9300A0598E7040560BE815@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Revised draft NEA charter Thread-Index: AcZ5/TK96YKZLzFqSlWmAS+rsP1glQAALt4w From: "Blumenthal, Uri" To: "Stephen Hanna" , X-OriginalArrivalTime: 17 May 2006 22:06:05.0604 (UTC) FILETIME=[17E2EE40:01C679FE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b 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 I don't see PV interface mentioned in the new charter - this omission should be fixed. =20 -----Original Message----- From: Stephen Hanna [mailto:shanna@juniper.net]=20 Sent: Wednesday, May 17, 2006 6:00 PM To: nea@ietf.org Subject: [Nea] Revised draft NEA charter Folks, Susan and I have revised the draft NEA WG charter to reflect the consensus of the mailing list as reflected in the NEA Action Plan agreed to in April. Please review this draft and send feedback ASAP. Of course, we can revise the charter up to Montreal but I'd like to get a solid version by Friday so we can submit our BOF proposal on Monday as the IESG has requested. Thanks, Steve ------------- Draft NEA WG Charter May 17, 2006 Version Network Endpoint Assessment (NEA) architectures have been implemented in the industry to assess the "posture" of endpoint devices for the purposes of monitoring or enforcing compliance to an organization's policy for access to the network. Posture refers to the hardware or software configuration of an endpoint as it pertains to an organization's security policy. Posture may include knowledge about the types of hardware and software installed and their configurations, e.g. OS name and version, application patch levels, and anti-virus signature file version. On network access, an endpoint with an NEA Client can be queried for posture information which is validated on an NEA Server as part of network access control. Since NEA involves many different components from different vendors, interoperation between NEA architectures and implementations is highly desirable. Given that well-established protocols already exist for the lowest layers in the NEA architectures (such as EAP and RADIUS), the priority of the NEA working group is to standardize protocols at the higher layers in the architectures (known as PA and PB and described later). When used with the existing standards for lower layers, these new protocols will allow interoperability between an NEA Client from one vendor and an NEA Server from another. Since there are already several existing protocols at these higher layers, the NEA working group will consider these existing protocols as candidates for standardization. A requirements document will be written and used as a basis for evaluating the candidate protocols. The working group may decide to standardize one of the candidate protocols, use one of them as a basis for a new or revised protocol, or decide that a new protocol is needed. The NEA Requirements document will include a problem statement, definition of terms, requirements for PA, PB, and an overall security analysis. It will also include requirements for the protocol transporting PA, PB (known as PTT and described below). PA, the Posture Attribute protocol, consists of posture attributes that are carried between a particular Posture Collector in a NEA client and a particular Posture Validator in a NEA Server. The PA protocol is carried inside the PB protocol. Certain posture attributes will be standardized to ensure interoperability but vendor-specific attributes will also be supported. PB, the Posture Broker protocol, aggregates posture attributes from one or more Posture Collectors in an NEA client and sends them to the NEA server for assessment by one or more Posture Validators. PTT, the Posture Transport Tunnel protocol is a transport protocol suitable for carrying the PB protocol at or after network connection. Milestones: June 2006: * Submit first version of NEA Requirements I-D July 2006: * Agree on charter and milestones at IETF 66 September 2006: * WG Last Call on NEA Requirements I-D=20 October 2006: * Deadline for submission of candidate specs for PA and PB * Submit first version of NEA Evaluation I-D=20 November 2006: * Review NEA Evaluation I-D at IETF 67 December 2006: * WG Last Call on NEA Evaluation I-D January 2007: * Submit NEA Requirements I-D and Evaluation I-D to IESG as Info RFC * Submit first draft of PA and PB specs for review March 2007: * Discuss unresolved issues with PA and PB specs at IETF 68 * Agree on solutions to unresolved issues with PA and PB specs April 2007: * Submit revised draft of PA and PB specs June 2007 * WG Last Call on PA and PB specs July 2007 * Resolve outstanding Last Call comments on requirements I-D at IETF 69 August 2007: * Submit PA and PB specs to IESG for publication as Proposed _______________________________________________ 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 Wed May 17 19:56:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgVs1-0006Zg-Hv; Wed, 17 May 2006 19:56:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgVs0-0006Zb-Qj for nea@ietf.org; Wed, 17 May 2006 19:56:00 -0400 Received: from mout.perfora.net ([217.160.230.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgVry-0003rn-Ad for nea@ietf.org; Wed, 17 May 2006 19:56:00 -0400 Received: from [24.7.38.250] (helo=sysadmin13c23c) by mrelay.perfora.net (node=mrelayus1) with ESMTP (Nemesis), id 0MKp2t-1FgVrw26Gy-00021f; Wed, 17 May 2006 19:55:58 -0400 From: "Alper Yegin" To: Subject: RE: [Nea] Revised draft NEA charter Date: Thu, 18 May 2006 02:55:36 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-index: AcZ5/TK96YKZLzFqSlWmAS+rsP1glQADzqPw Message-ID: <0MKp2t-1FgVrw26Gy-00021f@mrelay.perfora.net> X-Provags-ID: perfora.net abuse@perfora.net login:abf7a4bb310ea4dfc9b6841113e2970f X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 that well-established protocols already exist for the > lowest layers in the NEA architectures (such as EAP and RADIUS), the Does the above text take the so-called "EAP lower layer" into consideration? Examples in the bracket misses that aspect. The earlier charter had said: 3. Posture Transport Carrier (PTC) protocol: The EAP framework supports running EAP over multiple carriers. Targeted deployment scenarios for NEA include both L2 and L3 network access scenarios. Existing standards used in NEA include 802.1x for L2 network access. Requirements need to be defined for an EAP over L3 transport for L3 access scenarios. Susan had stated that 802.1X is there for some specific deployments. That's fine. But what about for those that require EAP/L3 as the previous charter stated? Alper _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed May 17 19:57:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgVt4-0007YX-VS; Wed, 17 May 2006 19:57:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgVt3-0007YS-TQ for nea@ietf.org; Wed, 17 May 2006 19:57:05 -0400 Received: from mga02.intel.com ([134.134.136.20] helo=orsmga101-1.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgVt1-0003te-JQ for nea@ietf.org; Wed, 17 May 2006 19:57:05 -0400 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101-1.jf.intel.com with ESMTP; 17 May 2006 16:57:00 -0700 Received: from orsmsx332.jf.intel.com (HELO orsmsx332.amr.corp.intel.com) ([192.168.65.60]) by orsmga001.jf.intel.com with ESMTP; 17 May 2006 16:57:00 -0700 X-IronPort-AV: i="4.05,139,1146466800"; d="scan'208"; a="37815740:sNHT16850526" Received: from orsmsx411.amr.corp.intel.com ([10.22.226.47]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 May 2006 16:56: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 Date: Wed, 17 May 2006 16:56:46 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Requirements team meeting summary (May 11th) Thread-Index: AcZnfgEedAZHPj0/SMWaazdF5s/3FwAQDKXAAAFnjXAAAdwCkAAIr3pAACZyafAAEamBoABTXWLQABCkxrACIM5MMACpi69AASFFV6A= From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 17 May 2006 23:56:47.0392 (UTC) FILETIME=[8EB35A00:01C67A0D] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Subject: [Nea] Requirements team meeting summary (May 11th) 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 All Here is the Requirements team meeting summary from last week (May 11th)... Attendees: Mauricio Sanchez, Ravi Sahita, Kevin Amorin, Paul Sangster, Joe Tardo, Amardeep Sibia, Steve Hanna, Hormuzd Khosravi, John Vollbrecht=20 Agenda... Arch Use Cases discussion: Mauricio will check to see if he can send TNC specs Paul- Rather than using TNC specs directly, just contribute to this group/requirements based on TNC Steve - flow diagrams have too much details John - having some flow diagrams is important Amardeep - lets discuss the 10 high level reqs and bin this for now High level Common Requirements 1. NEA protocols must provide a way for multi-round posture exchange between the client and server. (Add some more explanation text-tbd) 2. NEA protocols must provide a way for the server or posture validators to query for specific posture information during initial network access time as well as at a later time. 3. NEA protocols must provide a way for the client (client broker or posture collector) to initiate a posture re-evaluation based on an event on the client. 4. NEA protocols must support non-capable or non-participating hosts or legacy devices in the network such as printers to be able to access the corporate network=20 a. without a posture exchange, just based on authentication b. without any posture exchange, and no authentication 5. NEA protocols may allow the association between posture profiles and user credentials, i.e. the network administrator must be able to configure different posture profiles on the backend server for different user groups and associate the two. (suggestions - Different section on End-point Policy Reqs, part of Informational text) 6. NEA protocols must not allow man-in-the-middle attacks by tying the machine/user authentication with the posture exchange, i.e. a malicious machine A should not be allowed to use the posture of a good machine B to get network access. NEA protocols must provide secure posture exchange. 7. The PA, PB & PV interfaces defined by NEA must be agnostic of the transport i.e. PT interface. 8. NEA protocols must reuse existing open standards for its different interfaces before defining new ones. 9. NEA protocols must be highly scalable in terms of adding multiple servers, clients, posture collectors, posture validators, etc=20 10. Configuration of NEA protocol behavior should use existing manageability protocols such as SNMP (suggestion - bin this requirement for now till Steve checks with Russ Housley) Amardeep - define a requirement for the attributes, minimum set of attributes (default set) must be defined by NEA - PA/PB interface Next Steps Paul - to provide some text for Reqs draft and help out with editing All - to send more Reqs to the team for discussion next week Team - to discuss other interface Reqs at next meeting Regards Hormuzd _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed May 17 20:27:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgWMO-0003Eq-62; Wed, 17 May 2006 20:27:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgWMN-0003Ef-2Z for nea@ietf.org; Wed, 17 May 2006 20:27:23 -0400 Received: from mga02.intel.com ([134.134.136.20] helo=orsmga101-1.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgWMK-00053t-Ii for nea@ietf.org; Wed, 17 May 2006 20:27:23 -0400 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101-1.jf.intel.com with ESMTP; 17 May 2006 17:27:19 -0700 Received: from orsmsx332.jf.intel.com (HELO orsmsx332.amr.corp.intel.com) ([192.168.65.60]) by orsmga001.jf.intel.com with ESMTP; 17 May 2006 17:27:19 -0700 X-IronPort-AV: i="4.05,139,1146466800"; d="scan'208"; a="37827240:sNHT27307770" Received: from orsmsx411.amr.corp.intel.com ([10.22.226.47]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 May 2006 17:27: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] Revised draft NEA charter Date: Wed, 17 May 2006 17:27:16 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Revised draft NEA charter Thread-Index: AcZ5/TK96YKZLzFqSlWmAS+rsP1glQAFBXew From: "Khosravi, Hormuzd M" To: "Stephen Hanna" , X-OriginalArrivalTime: 18 May 2006 00:27:17.0672 (UTC) FILETIME=[D1A1EA80:01C67A11] X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c 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, In the milestones, I saw PA & PB specs, but not any PT specs. Shouldn't this group invite PT candidates as well? Or will those be standardized in another WG, namely, EMU? This is not clear to me. Also, probably mention something about our relationship with EMU...as a clarification. Thanks Hormuzd -----Original Message----- From: Stephen Hanna [mailto:shanna@juniper.net]=20 Sent: Wednesday, May 17, 2006 3:00 PM To: nea@ietf.org Subject: [Nea] Revised draft NEA charter Folks, Susan and I have revised the draft NEA WG charter to reflect the consensus of the mailing list as reflected in the NEA Action Plan agreed to in April. Please review this draft and send feedback ASAP. Of course, we can revise the charter up to Montreal but I'd like to get a solid version by Friday so we can submit our BOF proposal on Monday as the IESG has requested. Thanks, Steve ------------- Draft NEA WG Charter May 17, 2006 Version Network Endpoint Assessment (NEA) architectures have been implemented in the industry to assess the "posture" of endpoint devices for the purposes of monitoring or enforcing compliance to an organization's policy for access to the network. Posture refers to the hardware or software configuration of an endpoint as it pertains to an organization's security policy. Posture may include knowledge about the types of hardware and software installed and their configurations, e.g. OS name and version, application patch levels, and anti-virus signature file version. On network access, an endpoint with an NEA Client can be queried for posture information which is validated on an NEA Server as part of network access control. Since NEA involves many different components from different vendors, interoperation between NEA architectures and implementations is highly desirable. Given that well-established protocols already exist for the lowest layers in the NEA architectures (such as EAP and RADIUS), the priority of the NEA working group is to standardize protocols at the higher layers in the architectures (known as PA and PB and described later). When used with the existing standards for lower layers, these new protocols will allow interoperability between an NEA Client from one vendor and an NEA Server from another. Since there are already several existing protocols at these higher layers, the NEA working group will consider these existing protocols as candidates for standardization. A requirements document will be written and used as a basis for evaluating the candidate protocols. The working group may decide to standardize one of the candidate protocols, use one of them as a basis for a new or revised protocol, or decide that a new protocol is needed. The NEA Requirements document will include a problem statement, definition of terms, requirements for PA, PB, and an overall security analysis. It will also include requirements for the protocol transporting PA, PB (known as PTT and described below). PA, the Posture Attribute protocol, consists of posture attributes that are carried between a particular Posture Collector in a NEA client and a particular Posture Validator in a NEA Server. The PA protocol is carried inside the PB protocol. Certain posture attributes will be standardized to ensure interoperability but vendor-specific attributes will also be supported. PB, the Posture Broker protocol, aggregates posture attributes from one or more Posture Collectors in an NEA client and sends them to the NEA server for assessment by one or more Posture Validators. PTT, the Posture Transport Tunnel protocol is a transport protocol suitable for carrying the PB protocol at or after network connection. Milestones: June 2006: * Submit first version of NEA Requirements I-D July 2006: * Agree on charter and milestones at IETF 66 September 2006: * WG Last Call on NEA Requirements I-D=20 October 2006: * Deadline for submission of candidate specs for PA and PB * Submit first version of NEA Evaluation I-D=20 November 2006: * Review NEA Evaluation I-D at IETF 67 December 2006: * WG Last Call on NEA Evaluation I-D January 2007: * Submit NEA Requirements I-D and Evaluation I-D to IESG as Info RFC * Submit first draft of PA and PB specs for review March 2007: * Discuss unresolved issues with PA and PB specs at IETF 68 * Agree on solutions to unresolved issues with PA and PB specs April 2007: * Submit revised draft of PA and PB specs June 2007 * WG Last Call on PA and PB specs July 2007 * Resolve outstanding Last Call comments on requirements I-D at IETF 69 August 2007: * Submit PA and PB specs to IESG for publication as Proposed _______________________________________________ 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 Wed May 17 22:14:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgY1m-00038s-0x; Wed, 17 May 2006 22:14:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgY1k-00038k-Fd for nea@ietf.org; Wed, 17 May 2006 22:14:12 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgY1h-0000fK-Ui for nea@ietf.org; Wed, 17 May 2006 22:14:12 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4I2E4e9005992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 17 May 2006 19:14:05 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4I2E1i2024681; Wed, 17 May 2006 19:14:02 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 May 2006 19:13:58 -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] Revised draft NEA charter Date: Wed, 17 May 2006 19:13:57 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB8488281C@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Revised draft NEA charter Thread-Index: AcZ5/TK96YKZLzFqSlWmAS+rsP1glQAI0qrg From: "Narayanan, Vidya" To: "Stephen Hanna" , X-OriginalArrivalTime: 18 May 2006 02:13:58.0504 (UTC) FILETIME=[B8D35E80:01C67A20] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 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 A high level question - is the work solely targeting enterprise environments? The problem statement alludes to this, but, this is not clear from the charter.=20 Thanks, Vidya > -----Original Message----- > From: Stephen Hanna [mailto:shanna@juniper.net]=20 > Sent: Wednesday, May 17, 2006 3:00 PM > To: nea@ietf.org > Subject: [Nea] Revised draft NEA charter >=20 > Folks, >=20 > Susan and I have revised the draft NEA WG charter to reflect=20 > the consensus of the mailing list as reflected in the NEA=20 > Action Plan agreed to in April. >=20 > Please review this draft and send feedback ASAP. Of course,=20 > we can revise the charter up to Montreal but I'd like to get=20 > a solid version by Friday so we can submit our BOF proposal=20 > on Monday as the IESG has requested. >=20 > Thanks, >=20 > Steve >=20 > ------------- >=20 > Draft NEA WG Charter > May 17, 2006 Version >=20 > Network Endpoint Assessment (NEA) architectures have been=20 > implemented in the industry to assess the "posture" of=20 > endpoint devices for the purposes of monitoring or enforcing=20 > compliance to an organization's policy for access to the=20 > network. Posture refers to the hardware or software=20 > configuration of an endpoint as it pertains to an=20 > organization's security policy. Posture may include knowledge=20 > about the types of hardware and software installed and their=20 > configurations, e.g. > OS name and version, application patch levels, and anti-virus=20 > signature file version. On network access, an endpoint with=20 > an NEA Client can be queried for posture information which is=20 > validated on an NEA Server as part of network access control. >=20 > Since NEA involves many different components from different=20 > vendors, interoperation between NEA architectures and=20 > implementations is highly desirable. Given that=20 > well-established protocols already exist for the lowest=20 > layers in the NEA architectures (such as EAP and RADIUS), the=20 > priority of the NEA working group is to standardize protocols=20 > at the higher layers in the architectures (known as PA and PB=20 > and described later). When used with the existing standards=20 > for lower layers, these new protocols will allow=20 > interoperability between an NEA Client from one vendor and an=20 > NEA Server from another. >=20 > Since there are already several existing protocols at these=20 > higher layers, the NEA working group will consider these=20 > existing protocols as candidates for standardization. A=20 > requirements document will be written and used as a basis for=20 > evaluating the candidate protocols. The working group may=20 > decide to standardize one of the candidate protocols, use one=20 > of them as a basis for a new or revised protocol, or decide=20 > that a new protocol is needed. >=20 > The NEA Requirements document will include a problem=20 > statement, definition of terms, requirements for PA, PB, and=20 > an overall security analysis. It will also include=20 > requirements for the protocol transporting PA, PB (known as=20 > PTT and described below). >=20 > PA, the Posture Attribute protocol, consists of posture=20 > attributes that are carried between a particular Posture=20 > Collector in a NEA client and a particular Posture Validator=20 > in a NEA Server. The PA protocol is carried inside the PB=20 > protocol. Certain posture attributes will be standardized to=20 > ensure interoperability but vendor-specific attributes will=20 > also be supported. >=20 > PB, the Posture Broker protocol, aggregates posture=20 > attributes from one or more Posture Collectors in an NEA=20 > client and sends them to the NEA server for assessment by one=20 > or more Posture Validators. >=20 > PTT, the Posture Transport Tunnel protocol is a transport=20 > protocol suitable for carrying the PB protocol at or after=20 > network connection. >=20 > Milestones: >=20 > June 2006: > * Submit first version of NEA Requirements I-D >=20 > July 2006: > * Agree on charter and milestones at IETF 66 >=20 > September 2006: > * WG Last Call on NEA Requirements I-D=20 >=20 > October 2006: > * Deadline for submission of candidate specs for PA and PB > * Submit first version of NEA Evaluation I-D=20 >=20 > November 2006: > * Review NEA Evaluation I-D at IETF 67 >=20 > December 2006: > * WG Last Call on NEA Evaluation I-D >=20 > January 2007: > * Submit NEA Requirements I-D and Evaluation I-D to IESG as Info RFC > * Submit first draft of PA and PB specs for review >=20 > March 2007: > * Discuss unresolved issues with PA and PB specs at IETF 68 > * Agree on solutions to unresolved issues with PA and PB specs >=20 > April 2007: > * Submit revised draft of PA and PB specs >=20 > June 2007 > * WG Last Call on PA and PB specs >=20 > July 2007 > * Resolve outstanding Last Call comments on requirements I-D=20 > at IETF 69 >=20 > August 2007: > * Submit PA and PB specs to IESG for publication as Proposed >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu May 18 00:07:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgZnW-0001TW-4V; Thu, 18 May 2006 00:07:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgZnV-0001ST-KS for nea@ietf.org; Thu, 18 May 2006 00:07:37 -0400 Received: from mga02.intel.com ([134.134.136.20] helo=orsmga101-1.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgZnV-0000bv-1r for nea@ietf.org; Thu, 18 May 2006 00:07:37 -0400 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101-1.jf.intel.com with ESMTP; 17 May 2006 21:07:36 -0700 Received: from fmsmsx332.fm.intel.com (HELO fmsmsx332.amr.corp.intel.com) ([132.233.42.148]) by orsmga001.jf.intel.com with ESMTP; 17 May 2006 21:07:36 -0700 X-IronPort-AV: i="4.05,139,1146466800"; d="scan'208"; a="37889402:sNHT23502633" Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 May 2006 21:06:35 -0700 Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 May 2006 21:06:35 -0700 Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 18 May 2006 00:06:34 -0400 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] Revised draft NEA charter Date: Thu, 18 May 2006 00:06:26 -0400 Message-ID: <279DDDAFA85EC74C9300A0598E7040560BE86F@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Revised draft NEA charter Thread-Index: AcZ5/TK96YKZLzFqSlWmAS+rsP1glQAFBXewAAfAt9A= From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 18 May 2006 04:06:34.0559 (UTC) FILETIME=[73BF8CF0:01C67A30] X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f 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 > In the milestones, I saw PA & PB specs, but not any PT specs. > Shouldn't this group invite PT candidates as well? > Or will those be standardized in another WG, namely, EMU? And in any case it has to be explicitly stated where those specs are to come from. -----Original Message----- From: Stephen Hanna [mailto:shanna@juniper.net]=20 Sent: Wednesday, May 17, 2006 3:00 PM To: nea@ietf.org Subject: [Nea] Revised draft NEA charter Folks, Susan and I have revised the draft NEA WG charter to reflect the consensus of the mailing list as reflected in the NEA Action Plan agreed to in April. Please review this draft and send feedback ASAP. Of course, we can revise the charter up to Montreal but I'd like to get a solid version by Friday so we can submit our BOF proposal on Monday as the IESG has requested. Thanks, Steve ------------- Draft NEA WG Charter May 17, 2006 Version Network Endpoint Assessment (NEA) architectures have been implemented in the industry to assess the "posture" of endpoint devices for the purposes of monitoring or enforcing compliance to an organization's policy for access to the network. Posture refers to the hardware or software configuration of an endpoint as it pertains to an organization's security policy. Posture may include knowledge about the types of hardware and software installed and their configurations, e.g. OS name and version, application patch levels, and anti-virus signature file version. On network access, an endpoint with an NEA Client can be queried for posture information which is validated on an NEA Server as part of network access control. Since NEA involves many different components from different vendors, interoperation between NEA architectures and implementations is highly desirable. Given that well-established protocols already exist for the lowest layers in the NEA architectures (such as EAP and RADIUS), the priority of the NEA working group is to standardize protocols at the higher layers in the architectures (known as PA and PB and described later). When used with the existing standards for lower layers, these new protocols will allow interoperability between an NEA Client from one vendor and an NEA Server from another. Since there are already several existing protocols at these higher layers, the NEA working group will consider these existing protocols as candidates for standardization. A requirements document will be written and used as a basis for evaluating the candidate protocols. The working group may decide to standardize one of the candidate protocols, use one of them as a basis for a new or revised protocol, or decide that a new protocol is needed. The NEA Requirements document will include a problem statement, definition of terms, requirements for PA, PB, and an overall security analysis. It will also include requirements for the protocol transporting PA, PB (known as PTT and described below). PA, the Posture Attribute protocol, consists of posture attributes that are carried between a particular Posture Collector in a NEA client and a particular Posture Validator in a NEA Server. The PA protocol is carried inside the PB protocol. Certain posture attributes will be standardized to ensure interoperability but vendor-specific attributes will also be supported. PB, the Posture Broker protocol, aggregates posture attributes from one or more Posture Collectors in an NEA client and sends them to the NEA server for assessment by one or more Posture Validators. PTT, the Posture Transport Tunnel protocol is a transport protocol suitable for carrying the PB protocol at or after network connection. Milestones: June 2006: * Submit first version of NEA Requirements I-D July 2006: * Agree on charter and milestones at IETF 66 September 2006: * WG Last Call on NEA Requirements I-D=20 October 2006: * Deadline for submission of candidate specs for PA and PB * Submit first version of NEA Evaluation I-D=20 November 2006: * Review NEA Evaluation I-D at IETF 67 December 2006: * WG Last Call on NEA Evaluation I-D January 2007: * Submit NEA Requirements I-D and Evaluation I-D to IESG as Info RFC * Submit first draft of PA and PB specs for review March 2007: * Discuss unresolved issues with PA and PB specs at IETF 68 * Agree on solutions to unresolved issues with PA and PB specs April 2007: * Submit revised draft of PA and PB specs June 2007 * WG Last Call on PA and PB specs July 2007 * Resolve outstanding Last Call comments on requirements I-D at IETF 69 August 2007: * Submit PA and PB specs to IESG for publication as Proposed _______________________________________________ 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 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu May 18 00:41:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgaKT-0005j3-T4; Thu, 18 May 2006 00:41:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgaKS-0005ix-UZ for nea@ietf.org; Thu, 18 May 2006 00:41:40 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgaKQ-00039B-KW for nea@ietf.org; Thu, 18 May 2006 00:41:40 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4I4fXJk015717 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 17 May 2006 21:41:33 -0700 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4I4fXXL026346 for ; Wed, 17 May 2006 21:41:33 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 May 2006 21:41:32 -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 Date: Wed, 17 May 2006 21:41:32 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB84882839@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Device compromise and NEA? Thread-Index: AcZ6NVX1ksds8VHLQlqbsKsku6zLAQ== From: "Narayanan, Vidya" To: X-OriginalArrivalTime: 18 May 2006 04:41:32.0388 (UTC) FILETIME=[5626DA40:01C67A35] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [Nea] Device compromise and NEA? 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 All, I have a fundamental question regarding the NEA work. If a device is compromised, how can there be any trust in the posture attributes that it may be reporting?=20 Vidya _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu May 18 04:17:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgdgu-0005px-H3; Thu, 18 May 2006 04:17:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgdgt-0005pQ-3T for nea@ietf.org; Thu, 18 May 2006 04:17:03 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgdgt-0008Mb-1z for nea@ietf.org; Thu, 18 May 2006 04:17:03 -0400 Received: from [207.47.37.170] (helo=SCES1.sc.nevisnetworks.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FgdT5-00088v-Uq for nea@ietf.org; Thu, 18 May 2006 04:02:49 -0400 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] Device compromise and NEA? Date: Thu, 18 May 2006 01:02:41 -0700 Message-ID: <126EBB1F0092E14B9E595D03263235AA911751@SCES1.sc.nevisnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Device compromise and NEA? Thread-Index: AcZ6NVX1ksds8VHLQlqbsKsku6zLAQABGNdQ From: "Joseph Tardo" To: "Narayanan, Vidya" , X-Spam-Score: -0.6 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 Vidya, I personally believe NEA is purely a proactive play, that is, it strives to remediate the truthful but vulnerable endpoint before that endpoint becomes infected. It does this by not admitting the vulnerable or questionable endpoint onto the network until it is brought into compliance, thus keeping malware from infecting that client. NEA is not necessarily effective as a reactive mechanism. It provides no guarantee that it will detect an already infected endpoint, since that endpoint cannot be trusted not to lie. In such a case, NEA might not prevent an infected and out of compliance endpoint from being admitted onto the network. Such an event would have limited consequence anyway if you have deployed NEA everywhere, or so it is said, since there will be very few available victims around. Thus you can only be sure that if an endpoint is in compliance then it will be admitted, and if an endpoint is not admitted then it is not in compliance, but not vice-versa. That is, these are not if-an-only-if. If an endpoint is admitted if might or might not be in compliance, and if it is out of compliance it might or might not be admitted. It would thus be highly unadvisable to rely on NEA alone for preventing malware from entering the network. Other reactive measures should be used as well. Of course, all this applies to today's software-only implementations on available OS. With hardware or other isolation in place, things would be quite different=20 Thanks, --Joe =20 -----Original Message----- From: Narayanan, Vidya [mailto:vidyan@qualcomm.com]=20 Sent: Wednesday, May 17, 2006 9:42 PM To: nea@ietf.org Subject: [Nea] Device compromise and NEA? All, I have a fundamental question regarding the NEA work. If a device is compromised, how can there be any trust in the posture attributes that it may be reporting?=20 Vidya _______________________________________________ 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 May 18 04:44:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fge7l-0007Ti-C6; Thu, 18 May 2006 04:44:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fge7k-0007Td-KH for nea@ietf.org; Thu, 18 May 2006 04:44:48 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fge7k-0000vr-0h for nea@ietf.org; Thu, 18 May 2006 04:44:48 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4I8igsu032157 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 18 May 2006 01:44:43 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-64-187.qualcomm.com [10.50.64.187]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4I8icde022154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 18 May 2006 01:44:40 -0700 (PDT) Message-Id: <6.2.5.6.2.20060518012251.040af708@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 18 May 2006 01:44:46 -0700 To: "Joseph Tardo" , "Narayanan, Vidya" , From: Lakshminath Dondeti Subject: RE: [Nea] Device compromise and NEA? In-Reply-To: <126EBB1F0092E14B9E595D03263235AA911751@SCES1.sc.nevisnetwo rks.com> References: <126EBB1F0092E14B9E595D03263235AA911751@SCES1.sc.nevisnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 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, I am naive here, so, please bear with me: At 01:02 AM 5/18/2006, Joseph Tardo wrote: >Vidya, > >I personally believe NEA is purely a proactive play, that is, it strives >to remediate the truthful but vulnerable endpoint before that endpoint >becomes infected. It does this by not admitting the vulnerable or >questionable endpoint onto the network until it is brought into >compliance, thus keeping malware from infecting that client. Pardon the analogy, but this sounds like that old airport security question "did you pack your bags?" It was not effective there and so why would it be in an IETF protocol? >NEA is not necessarily effective as a reactive mechanism. It provides no >guarantee that it will detect an already infected endpoint, since that >endpoint cannot be trusted not to lie. In such a case, NEA might not >prevent an infected and out of compliance endpoint from being admitted >onto the network. Such an event would have limited consequence anyway if >you have deployed NEA everywhere, or so it is said, since there will be >very few available victims around. Big assumption! But, I don't think it matters. An adversary can still introduce a non-compliant device (as you note above) into the network, which of course can go on to infect compliant devices and make them non-compliant but undetectable (or admittable into the network). I guess the natural course from there on is that the attack is detected and the network (or in some cases, humans) may have to force *all* devices to install a fix, and change the parameters for NEA reporting. And the cycle would continue. Is this the expected mode of operation? Since all devices need to install the fix and in some cases, humans may have to be involved, what's NEA buying us? I am sure I am missing something here, so looking for a clue. Thanks. >Thus you can only be sure that if an endpoint is in compliance then it >will be admitted, and if an endpoint is not admitted then it is not in >compliance, but not vice-versa. That is, these are not if-an-only-if. If >an endpoint is admitted if might or might not be in compliance, and if >it is out of compliance it might or might not be admitted. > >It would thus be highly unadvisable to rely on NEA alone for preventing >malware from entering the network. Other reactive measures should be >used as well. Some details on the "other reactive measures" would be educative to me. >Of course, all this applies to today's software-only implementations on >available OS. With hardware or other isolation in place, things would be >quite different I have been told this about h/w before, and was at some point willing to believe it at face value, but need some education here as well. Perhaps you might point me to a document that explains how. Thanks in advance. best regards, Lakshminath >Thanks, >--Joe > > >-----Original Message----- >From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] >Sent: Wednesday, May 17, 2006 9:42 PM >To: nea@ietf.org >Subject: [Nea] Device compromise and NEA? > > >All, >I have a fundamental question regarding the NEA work. If a device is >compromised, how can there be any trust in the posture attributes that >it may be reporting? > >Vidya > >_______________________________________________ >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 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu May 18 08:09:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FghJq-0001ff-6j; Thu, 18 May 2006 08:09:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FghJo-0001fa-3h for nea@ietf.org; Thu, 18 May 2006 08:09:28 -0400 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FghJl-000687-KA for nea@ietf.org; Thu, 18 May 2006 08:09:28 -0400 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k4IC4FS15523; Thu, 18 May 2006 08:04:16 -0400 (EDT) Received: from [47.248.126.240] ([47.248.126.240] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 08:09:09 -0400 Message-ID: <446C63E2.80104@nortel.com> Date: Thu, 18 May 2006 08:09:06 -0400 From: "Marcus Leech" User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: "Narayanan, Vidya" Subject: Re: [Nea] Device compromise and NEA? References: <2EBB8025B6D1BA41B567DB32C1D8DB84882839@NAEX06.na.qualcomm.com> In-Reply-To: <2EBB8025B6D1BA41B567DB32C1D8DB84882839@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 May 2006 12:09:09.0362 (UTC) FILETIME=[DE27DD20:01C67A73] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 Narayanan, Vidya wrote: > All, > I have a fundamental question regarding the NEA work. If a device is > compromised, how can there be any trust in the posture attributes that > it may be reporting? > > Vidya > Indeed. Consider Turing-Completeness, and the Halting Problem. It gives one pause.... _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu May 18 10:04:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgj6s-0008JN-0m; Thu, 18 May 2006 10:04:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgj6r-0008JI-0Y for nea@ietf.org; Thu, 18 May 2006 10:04:13 -0400 Received: from nokia350.mtghouse.com ([64.140.235.198] helo=mail.mtghouse.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Fgj6q-0003C3-Id for nea@ietf.org; Thu, 18 May 2006 10:04:12 -0400 Received: (qmail 13868 invoked from network); 18 May 2006 10:04:07 -0400 Received: from unknown (HELO genec) (172.22.18.115) by mail.mtghouse.com with SMTP; 18 May 2006 10:04:07 -0400 From: "Eugene Chang" To: "'Stephen Hanna'" , Subject: RE: [Nea] Revised draft NEA charter Date: Thu, 18 May 2006 10:03:50 -0400 Organization: Meetinghouse Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZ5/TK96YKZLzFqSlWmAS+rsP1glQAg58tg X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: echang@mtghouse.com List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org I have some novice's questions. Since I am new to this group, I don't know how significant these questions are to crafting a charter. How tightly will the language defining PA, PB and PTT be interpreted for defining the scope of work? The definitions generally match my intuition about the problem. However I can read some constraints in the definitions that do not match my long term views. Here are my questions below. Do these need to be anticipated in the definitions in the charter? PA, the Posture Attribute protocol. What is the proper interpretation for what could qualify as an "attribute"? This definition works for me if an attribute could be any data object. I would have reservations if an attribute implies constraints on the richness of the data object. PB, Posture Broker protocol. I read the definition to imply that given a set of Posture Collectors and a set of Posture Validators, the PB strictly partitions PCs into subsets and PVs into subsets so that a PC subset maps one-to-one to a PV subset. This would recognize a near term reality that PC subsets and PV subsets maybe from a single implementer (vendor) and that the PB maintains the separation of PA between implementers (vendors). This definition does not work for me if we envision a future where posture attributes could flow between different implementers. PTT, Posture Tunnel Transport protocol. I read this definition as a transport for a bundle (set) of PB. This definition works were we see the partitioning of the PC and PV. My concern here is the same as for the PB. Thanks, Gene -------------------------------------------------------------------------- Eugene Chang Meetinghouse voice: +1-603-610-8678 mobile: +1-781-799-0233 fax: +1-603-430-8436 email: echang@mtghouse.com email: eugene.chang@ieee.org skype: gene02421 -----Original Message----- From: Stephen Hanna [mailto:shanna@juniper.net] Sent: Wednesday, May 17, 2006 6:00 PM To: nea@ietf.org Subject: [Nea] Revised draft NEA charter Folks, Susan and I have revised the draft NEA WG charter to reflect the consensus of the mailing list as reflected in the NEA Action Plan agreed to in April. Please review this draft and send feedback ASAP. Of course, we can revise the charter up to Montreal but I'd like to get a solid version by Friday so we can submit our BOF proposal on Monday as the IESG has requested. Thanks, Steve ------------- Draft NEA WG Charter May 17, 2006 Version Network Endpoint Assessment (NEA) architectures have been implemented in the industry to assess the "posture" of endpoint devices for the purposes of monitoring or enforcing compliance to an organization's policy for access to the network. Posture refers to the hardware or software configuration of an endpoint as it pertains to an organization's security policy. Posture may include knowledge about the types of hardware and software installed and their configurations, e.g. OS name and version, application patch levels, and anti-virus signature file version. On network access, an endpoint with an NEA Client can be queried for posture information which is validated on an NEA Server as part of network access control. Since NEA involves many different components from different vendors, interoperation between NEA architectures and implementations is highly desirable. Given that well-established protocols already exist for the lowest layers in the NEA architectures (such as EAP and RADIUS), the priority of the NEA working group is to standardize protocols at the higher layers in the architectures (known as PA and PB and described later). When used with the existing standards for lower layers, these new protocols will allow interoperability between an NEA Client from one vendor and an NEA Server from another. Since there are already several existing protocols at these higher layers, the NEA working group will consider these existing protocols as candidates for standardization. A requirements document will be written and used as a basis for evaluating the candidate protocols. The working group may decide to standardize one of the candidate protocols, use one of them as a basis for a new or revised protocol, or decide that a new protocol is needed. The NEA Requirements document will include a problem statement, definition of terms, requirements for PA, PB, and an overall security analysis. It will also include requirements for the protocol transporting PA, PB (known as PTT and described below). PA, the Posture Attribute protocol, consists of posture attributes that are carried between a particular Posture Collector in a NEA client and a particular Posture Validator in a NEA Server. The PA protocol is carried inside the PB protocol. Certain posture attributes will be standardized to ensure interoperability but vendor-specific attributes will also be supported. PB, the Posture Broker protocol, aggregates posture attributes from one or more Posture Collectors in an NEA client and sends them to the NEA server for assessment by one or more Posture Validators. PTT, the Posture Transport Tunnel protocol is a transport protocol suitable for carrying the PB protocol at or after network connection. Milestones: June 2006: * Submit first version of NEA Requirements I-D July 2006: * Agree on charter and milestones at IETF 66 September 2006: * WG Last Call on NEA Requirements I-D October 2006: * Deadline for submission of candidate specs for PA and PB * Submit first version of NEA Evaluation I-D November 2006: * Review NEA Evaluation I-D at IETF 67 December 2006: * WG Last Call on NEA Evaluation I-D January 2007: * Submit NEA Requirements I-D and Evaluation I-D to IESG as Info RFC * Submit first draft of PA and PB specs for review March 2007: * Discuss unresolved issues with PA and PB specs at IETF 68 * Agree on solutions to unresolved issues with PA and PB specs April 2007: * Submit revised draft of PA and PB specs June 2007 * WG Last Call on PA and PB specs July 2007 * Resolve outstanding Last Call comments on requirements I-D at IETF 69 August 2007: * Submit PA and PB specs to IESG for publication as Proposed _______________________________________________ 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 May 18 11:01:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgjzu-0004sg-Hs; Thu, 18 May 2006 11:01:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgjzt-0004sb-Ni for nea@ietf.org; Thu, 18 May 2006 11:01:05 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgjzt-00070c-7y for nea@ietf.org; Thu, 18 May 2006 11:01:05 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 18 May 2006 08:01:04 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,142,1146466800"; d="scan'208"; a="547496850:sNHT24237744" 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] Revised draft NEA charter Date: Thu, 18 May 2006 11:01:05 -0400 Message-ID: In-Reply-To: <279DDDAFA85EC74C9300A0598E7040560BE815@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Revised draft NEA charter Thread-Index: AcZ5/TK96YKZLzFqSlWmAS+rsP1glQAALt4wAB+xMIA= From: "Stephen Hanna" To: "Blumenthal, Uri" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 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 Uri, Thanks for your prompt and clear response. The action plan agreed to on the mailing list in April included this item: B) Revise proposed NEA charter to focus on transport-independent PA and PB and requirements for PTT=20 Therefore, PV is not considered in scope for NEA, at least not for now. We could perhaps consider working on it after we have finished the work items in our initial charter. Why was the action plan defined in this way? Because the feedback from the first BOF was to focus on a single clear interoperability goal--client-server interoperability--and to avoid defining transport protocols since some exist already and in any case that is the domain of other working groups. Thanks, Steve > -----Original Message----- > From: Blumenthal, Uri [mailto:uri.blumenthal@intel.com]=20 > Sent: Wednesday, May 17, 2006 6:06 PM > To: Stephen Hanna; nea@ietf.org > Subject: RE: [Nea] Revised draft NEA charter >=20 > I don't see PV interface mentioned in the new charter - this omission > should be fixed. > =20 >=20 > -----Original Message----- > From: Stephen Hanna [mailto:shanna@juniper.net]=20 > Sent: Wednesday, May 17, 2006 6:00 PM > To: nea@ietf.org > Subject: [Nea] Revised draft NEA charter >=20 > Folks, >=20 > Susan and I have revised the draft NEA WG charter to reflect > the consensus of the mailing list as reflected in the NEA Action > Plan agreed to in April. >=20 > Please review this draft and send feedback ASAP. Of course, > we can revise the charter up to Montreal but I'd like to get > a solid version by Friday so we can submit our BOF proposal > on Monday as the IESG has requested. >=20 > Thanks, >=20 > Steve >=20 > ------------- >=20 > Draft NEA WG Charter > May 17, 2006 Version >=20 > Network Endpoint Assessment (NEA) architectures have been=20 > implemented in > the industry to assess the "posture" of endpoint devices for the > purposes of monitoring or enforcing compliance to an organization's > policy for access to the network. Posture refers to the hardware or > software configuration of an endpoint as it pertains to an > organization's security policy. Posture may include knowledge=20 > about the > types of hardware and software installed and their=20 > configurations, e.g. > OS name and version, application patch levels, and anti-virus=20 > signature > file version. On network access, an endpoint with an NEA Client can be > queried for posture information which is validated on an NEA Server as > part of network access control. >=20 > Since NEA involves many different components from different vendors, > interoperation between NEA architectures and implementations is highly > desirable. Given that well-established protocols already exist for the > lowest layers in the NEA architectures (such as EAP and RADIUS), the > priority of the NEA working group is to standardize protocols at the > higher layers in the architectures (known as PA and PB and described > later). When used with the existing standards for lower layers, these > new protocols will allow interoperability between an NEA Client from > one vendor and an NEA Server from another. >=20 > Since there are already several existing protocols at these higher > layers, the NEA working group will consider these existing protocols > as candidates for standardization. A requirements document will be > written and used as a basis for evaluating the candidate > protocols. The working group may decide to standardize one of the > candidate protocols, use one of them as a basis for a new or revised > protocol, or decide that a new protocol is needed. >=20 > The NEA Requirements document will include a problem statement, > definition of terms, requirements for PA, PB, and an overall security > analysis. It will also include requirements for the protocol > transporting PA, PB (known as PTT and described below). >=20 > PA, the Posture Attribute protocol, consists of posture attributes > that are carried between a particular Posture Collector in a NEA > client and a particular Posture Validator in a NEA Server. The PA > protocol is carried inside the PB protocol. Certain posture attributes > will be standardized to ensure interoperability but vendor-specific > attributes will also be supported. >=20 > PB, the Posture Broker protocol, aggregates posture attributes > from one or more Posture Collectors in an NEA client and sends them to > the NEA server for assessment by one or more Posture Validators. >=20 > PTT, the Posture Transport Tunnel protocol is a transport protocol > suitable for carrying the PB protocol at or after network connection. >=20 > Milestones: >=20 > June 2006: > * Submit first version of NEA Requirements I-D >=20 > July 2006: > * Agree on charter and milestones at IETF 66 >=20 > September 2006: > * WG Last Call on NEA Requirements I-D=20 >=20 > October 2006: > * Deadline for submission of candidate specs for PA and PB > * Submit first version of NEA Evaluation I-D=20 >=20 > November 2006: > * Review NEA Evaluation I-D at IETF 67 >=20 > December 2006: > * WG Last Call on NEA Evaluation I-D >=20 > January 2007: > * Submit NEA Requirements I-D and Evaluation I-D to IESG as Info RFC > * Submit first draft of PA and PB specs for review >=20 > March 2007: > * Discuss unresolved issues with PA and PB specs at IETF 68 > * Agree on solutions to unresolved issues with PA and PB specs >=20 > April 2007: > * Submit revised draft of PA and PB specs >=20 > June 2007 > * WG Last Call on PA and PB specs >=20 > July 2007 > * Resolve outstanding Last Call comments on requirements I-D=20 > at IETF 69 >=20 > August 2007: > * Submit PA and PB specs to IESG for publication as Proposed >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu May 18 11:31:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgkTP-0007xJ-JA; Thu, 18 May 2006 11:31:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgkTN-0007wa-US for nea@ietf.org; Thu, 18 May 2006 11:31:33 -0400 Received: from mga02.intel.com ([134.134.136.20] helo=orsmga101-1.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgkTL-0000H3-6q for nea@ietf.org; Thu, 18 May 2006 11:31:33 -0400 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101-1.jf.intel.com with ESMTP; 18 May 2006 08:31:19 -0700 Received: from fmsmsx332.fm.intel.com (HELO fmsmsx332.amr.corp.intel.com) ([132.233.42.148]) by orsmga001.jf.intel.com with ESMTP; 18 May 2006 08:31:08 -0700 X-IronPort-AV: i="4.05,142,1146466800"; d="scan'208"; a="38122930:sNHT10899868259" Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 08:30:51 -0700 Received: from hdsmsx402.amr.corp.intel.com ([10.127.2.62]) by fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 08:30:50 -0700 Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by hdsmsx402.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 18 May 2006 11:30:49 -0400 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] Revised draft NEA charter Date: Thu, 18 May 2006 11:30:41 -0400 Message-ID: <279DDDAFA85EC74C9300A0598E7040560BE9CE@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Revised draft NEA charter Thread-Index: AcZ5/TK96YKZLzFqSlWmAS+rsP1glQAALt4wAB+xMIAABEcngA== From: "Blumenthal, Uri" To: "Stephen Hanna" , X-OriginalArrivalTime: 18 May 2006 15:30:49.0637 (UTC) FILETIME=[0A7B4D50:01C67A90] X-Spam-Score: 0.0 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 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 > Thanks for your prompt and clear response. You're wlecome. > The action plan agreed to on the mailing list in > April included this item: >=20 > B) Revise proposed NEA charter to focus on > transport-independent PA and PB and > requirements for PTT=20 Here's an excerpt from the High Level Architectural Requirements for NEA, posted in May - as April is long gone: 7. The PA, PB & PV interfaces defined by NEA must be agnostic of the transport i.e. PT interface. Consensus at the last BOF was that PA, PB and PV are all to be defined. > Therefore, PV is not considered in scope for NEA, > at least not for now. We could perhaps consider > working on it after we have finished the work items > in our initial charter. Phasing is good. Putting necessary components out of scope is not. Posture Validators may not run on the same box as Server Broker. > Why was the action plan defined in this way? Because > the feedback from the first BOF was to focus on a > single clear interoperability goal--client-server > interoperability--and to avoid defining transport > protocols since some exist already and in any case > that is the domain of other working groups. 1. Clear interoperability is clearly the goal. Which is why an important piece of the puzzle - the protocol between Posture Validator and Server Broker - must be defined. 2. IETF usually deals exclusively with transport protocols - and nothing else. > -----Original Message----- > From: Blumenthal, Uri [mailto:uri.blumenthal@intel.com]=20 > Sent: Wednesday, May 17, 2006 6:06 PM > To: Stephen Hanna; nea@ietf.org > Subject: RE: [Nea] Revised draft NEA charter >=20 > I don't see PV interface mentioned in the new charter - this omission > should be fixed. > =20 >=20 > -----Original Message----- > From: Stephen Hanna [mailto:shanna@juniper.net]=20 > Sent: Wednesday, May 17, 2006 6:00 PM > To: nea@ietf.org > Subject: [Nea] Revised draft NEA charter >=20 > Folks, >=20 > Susan and I have revised the draft NEA WG charter to reflect > the consensus of the mailing list as reflected in the NEA Action > Plan agreed to in April. >=20 > Please review this draft and send feedback ASAP. Of course, > we can revise the charter up to Montreal but I'd like to get > a solid version by Friday so we can submit our BOF proposal > on Monday as the IESG has requested. >=20 > Thanks, >=20 > Steve >=20 > ------------- >=20 > Draft NEA WG Charter > May 17, 2006 Version >=20 > Network Endpoint Assessment (NEA) architectures have been=20 > implemented in > the industry to assess the "posture" of endpoint devices for the > purposes of monitoring or enforcing compliance to an organization's > policy for access to the network. Posture refers to the hardware or > software configuration of an endpoint as it pertains to an > organization's security policy. Posture may include knowledge=20 > about the > types of hardware and software installed and their=20 > configurations, e.g. > OS name and version, application patch levels, and anti-virus=20 > signature > file version. On network access, an endpoint with an NEA Client can be > queried for posture information which is validated on an NEA Server as > part of network access control. >=20 > Since NEA involves many different components from different vendors, > interoperation between NEA architectures and implementations is highly > desirable. Given that well-established protocols already exist for the > lowest layers in the NEA architectures (such as EAP and RADIUS), the > priority of the NEA working group is to standardize protocols at the > higher layers in the architectures (known as PA and PB and described > later). When used with the existing standards for lower layers, these > new protocols will allow interoperability between an NEA Client from > one vendor and an NEA Server from another. >=20 > Since there are already several existing protocols at these higher > layers, the NEA working group will consider these existing protocols > as candidates for standardization. A requirements document will be > written and used as a basis for evaluating the candidate > protocols. The working group may decide to standardize one of the > candidate protocols, use one of them as a basis for a new or revised > protocol, or decide that a new protocol is needed. >=20 > The NEA Requirements document will include a problem statement, > definition of terms, requirements for PA, PB, and an overall security > analysis. It will also include requirements for the protocol > transporting PA, PB (known as PTT and described below). >=20 > PA, the Posture Attribute protocol, consists of posture attributes > that are carried between a particular Posture Collector in a NEA > client and a particular Posture Validator in a NEA Server. The PA > protocol is carried inside the PB protocol. Certain posture attributes > will be standardized to ensure interoperability but vendor-specific > attributes will also be supported. >=20 > PB, the Posture Broker protocol, aggregates posture attributes > from one or more Posture Collectors in an NEA client and sends them to > the NEA server for assessment by one or more Posture Validators. >=20 > PTT, the Posture Transport Tunnel protocol is a transport protocol > suitable for carrying the PB protocol at or after network connection. >=20 > Milestones: >=20 > June 2006: > * Submit first version of NEA Requirements I-D >=20 > July 2006: > * Agree on charter and milestones at IETF 66 >=20 > September 2006: > * WG Last Call on NEA Requirements I-D=20 >=20 > October 2006: > * Deadline for submission of candidate specs for PA and PB > * Submit first version of NEA Evaluation I-D=20 >=20 > November 2006: > * Review NEA Evaluation I-D at IETF 67 >=20 > December 2006: > * WG Last Call on NEA Evaluation I-D >=20 > January 2007: > * Submit NEA Requirements I-D and Evaluation I-D to IESG as Info RFC > * Submit first draft of PA and PB specs for review >=20 > March 2007: > * Discuss unresolved issues with PA and PB specs at IETF 68 > * Agree on solutions to unresolved issues with PA and PB specs >=20 > April 2007: > * Submit revised draft of PA and PB specs >=20 > June 2007 > * WG Last Call on PA and PB specs >=20 > July 2007 > * Resolve outstanding Last Call comments on requirements I-D=20 > at IETF 69 >=20 > August 2007: > * Submit PA and PB specs to IESG for publication as Proposed >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu May 18 12:16:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FglAU-0000mK-06; Thu, 18 May 2006 12:16:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FglAT-0000mF-Ga for nea@ietf.org; Thu, 18 May 2006 12:16:05 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgjoT-0006ba-G6 for nea@ietf.org; Thu, 18 May 2006 10:49:17 -0400 Received: from mga03.intel.com ([143.182.124.21] helo=azsmga101-1.ch.intel.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fgjbq-0003ic-PC for nea@ietf.org; Thu, 18 May 2006 10:36:16 -0400 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101-1.ch.intel.com with ESMTP; 18 May 2006 07:36:13 -0700 Received: from fmsmsx332.fm.intel.com (HELO fmsmsx332.amr.corp.intel.com) ([132.233.42.148]) by azsmga001.ch.intel.com with ESMTP; 18 May 2006 07:34:45 -0700 X-IronPort-AV: i="4.05,142,1146466800"; d="scan'208"; a="38324475:sNHT648358375" Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 07:34:25 -0700 Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 07:34:24 -0700 Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 18 May 2006 10:34:23 -0400 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] Device compromise and NEA? Date: Thu, 18 May 2006 10:34:14 -0400 Message-ID: <279DDDAFA85EC74C9300A0598E7040560BE960@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Device compromise and NEA? Thread-Index: AcZ6NVX1ksds8VHLQlqbsKsku6zLAQATiJ7w From: "Blumenthal, Uri" To: "Narayanan, Vidya" , X-OriginalArrivalTime: 18 May 2006 14:34:23.0765 (UTC) FILETIME=[28583C50:01C67A88] X-Spam-Score: -2.6 (--) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 You don't remember that this fundamental question was already asked at the last BOF by Bob Hinden in your presence? And that it was answered at the mike right then and there? For the benefits of others who were not present, I'm repeating that fundamental answer (as I happened to contribute a part of it, as you might recall now). First - there are hardware trust anchors that stand secure even when the software gets compromised (for your education, look up TCG TPM architecture, IBM Cell processor, AMD Presidio approach, and various Intel technologies such as SIS/VISN). When those are employed, even a "compromised" host may still be unable to falsify its posture. Posture Collectors may well be protected by hardware. NEA doesn't protect a system merely by itself. The greater its collaboration with other security mechanisms - the greater its strength.=20 Second - several people in the field, such as large enterprise customers - expressed their need for a mechanism like NEA, EVEN if there is no hardware-based security. Because in that case NEA acts for them as "vaccination" rather than "cure". NEA can help IT to determine what as-of-yet-healthy systems may need patches to their critical software, etc - and put the unpatched ones to remediation network for scanning and software upgrade. So all the systems connected to the intranet stay at the top of security level, currently available to IT department. Doesn't guarantee health - but improves its likelihood considerably. And to dispel illusions - no, NEA is not the answer to every problem on the planet - and it is technically possible (though highly improbable) that despite NEA and every other security technology utilized, a host is compromised to such an extent that its posture CAN be falsified. So what? We know that even bank vaults are occasionally burglarized - because of that do we stop installing door locks (of normal size) and security systems in our houses??? -----Original Message----- From: Narayanan, Vidya [mailto:vidyan@qualcomm.com]=20 Sent: Thursday, May 18, 2006 12:42 AM To: nea@ietf.org Subject: [Nea] Device compromise and NEA? All, I have a fundamental question regarding the NEA work. If a device is compromised, how can there be any trust in the posture attributes that it may be reporting?=20 Vidya _______________________________________________ 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 May 18 12:39:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FglX8-0001C7-82; Thu, 18 May 2006 12:39:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FglX7-0001C2-DT for nea@ietf.org; Thu, 18 May 2006 12:39:29 -0400 Received: from rwcrmhc11.comcast.net ([216.148.227.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FglX6-00052t-36 for nea@ietf.org; Thu, 18 May 2006 12:39:29 -0400 Received: from tardis (unknown[198.208.36.29]) by comcast.net (rwcrmhc11) with SMTP id <20060518163927m11008ks5se>; Thu, 18 May 2006 16:39:27 +0000 From: "Michael Lindskov" To: Subject: RE: [Nea] Device compromise and NEA? Date: Thu, 18 May 2006 12:39:25 -0400 Message-ID: <004301c67a99$9fff4710$1d24d0c6@tardis> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <279DDDAFA85EC74C9300A0598E7040560BE960@hdsmsx412.amr.corp.intel.com> Thread-Index: AcZ6NVX1ksds8VHLQlqbsKsku6zLAQATiJ7wAATuZaA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be 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 agree completely. The main purpose of NEA needs to be keeping honest systems honest. Reality dictates that any host that is compromised could potentially override just about any host based security system. The point is to prevent honest systems from getting infected by creating a necessity for machines to stay up to date. The idea behind NEA is that machines that are kept up to date are harder to infect. NEA works to motivate honest users to keep things current. The motivation provided by NEA solutions provides a lot of value. No single security layer can be considered sufficient and NEA should not be expected to provide a perfect solution. We should be more interested in creating an architecture that is extensible and flexible. That would allow us to improve the technology in the future. (e.g. integration of hardware based security features) However, I don't think we can expect these technologies to be integrated within the next year. NEA can provide value and should not be held up waiting for a better/perfect solution. Sincerely, Michael Lindskov -----Original Message----- From: Blumenthal, Uri [mailto:uri.blumenthal@intel.com] Sent: Thursday, May 18, 2006 10:34 AM To: Narayanan, Vidya; nea@ietf.org Subject: RE: [Nea] Device compromise and NEA? You don't remember that this fundamental question was already asked at the last BOF by Bob Hinden in your presence? And that it was answered at the mike right then and there? For the benefits of others who were not present, I'm repeating that fundamental answer (as I happened to contribute a part of it, as you might recall now). First - there are hardware trust anchors that stand secure even when the software gets compromised (for your education, look up TCG TPM architecture, IBM Cell processor, AMD Presidio approach, and various Intel technologies such as SIS/VISN). When those are employed, even a "compromised" host may still be unable to falsify its posture. Posture Collectors may well be protected by hardware. NEA doesn't protect a system merely by itself. The greater its collaboration with other security mechanisms - the greater its strength. Second - several people in the field, such as large enterprise customers - expressed their need for a mechanism like NEA, EVEN if there is no hardware-based security. Because in that case NEA acts for them as "vaccination" rather than "cure". NEA can help IT to determine what as-of-yet-healthy systems may need patches to their critical software, etc - and put the unpatched ones to remediation network for scanning and software upgrade. So all the systems connected to the intranet stay at the top of security level, currently available to IT department. Doesn't guarantee health - but improves its likelihood considerably. And to dispel illusions - no, NEA is not the answer to every problem on the planet - and it is technically possible (though highly improbable) that despite NEA and every other security technology utilized, a host is compromised to such an extent that its posture CAN be falsified. So what? We know that even bank vaults are occasionally burglarized - because of that do we stop installing door locks (of normal size) and security systems in our houses??? -----Original Message----- From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] Sent: Thursday, May 18, 2006 12:42 AM To: nea@ietf.org Subject: [Nea] Device compromise and NEA? All, I have a fundamental question regarding the NEA work. If a device is compromised, how can there be any trust in the posture attributes that it may be reporting? Vidya _______________________________________________ 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 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu May 18 12:48:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fglfh-0004a1-JN; Thu, 18 May 2006 12:48:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fglfg-0004Zw-IG for nea@ietf.org; Thu, 18 May 2006 12:48:20 -0400 Received: from zrtps0kp.nortel.com ([47.140.192.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fglfe-0005IF-7f for nea@ietf.org; Thu, 18 May 2006 12:48:20 -0400 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k4IGm5R19833; Thu, 18 May 2006 12:48:05 -0400 (EDT) Received: from [47.248.126.240] ([47.248.126.240] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 12:48:00 -0400 Message-ID: <446CA535.1030903@nortel.com> Date: Thu, 18 May 2006 12:47:49 -0400 From: "Marcus Leech" User-Agent: Thunderbird 1.5 (X11/20051201) MIME-Version: 1.0 To: "Blumenthal, Uri" Subject: Re: [Nea] Device compromise and NEA? References: <279DDDAFA85EC74C9300A0598E7040560BE960@hdsmsx412.amr.corp.intel.com> In-Reply-To: <279DDDAFA85EC74C9300A0598E7040560BE960@hdsmsx412.amr.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 May 2006 16:48:00.0659 (UTC) FILETIME=[D2C92E30:01C67A9A] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 Blumenthal, Uri wrote: > First - there are hardware trust anchors that stand secure even when the > software gets compromised (for your education, look up TCG TPM > architecture, IBM Cell processor, AMD Presidio approach, and various > Intel technologies such as SIS/VISN). When those are employed, even a > "compromised" host may still be unable to falsify its posture. Posture > Collectors may well be protected by hardware. NEA doesn't protect a > system merely by itself. The greater its collaboration with other > security mechanisms - the greater its strength. > > The fact that there's a hardware device that signs data doesn't prevent that device from being lied to by the host computer that it's embedded in. You know that, Uri. All that TPM gives you is "plausible-sounding lies". But this work in NEA must proceed on the assumption that despite the fundamental "shaky science" aspects of all this, there's some value to it, and that to the extent that there's value in it, standardizing protocols and architectures is a good thing. But we should never kid ourselves that "TPM fix everything". It doesn't. It's a cryptographic co-processor no different, from a high-level function perspective, than an ISO-7816 smartcard embedded in the machine. You can't get around the Halting Problem, and you can't pretend that the host machines aren't Turing Complete. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu May 18 13:00:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FglrN-0007u8-Pj; Thu, 18 May 2006 13:00:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FglrM-0007u2-DI for nea@ietf.org; Thu, 18 May 2006 13:00:24 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FglrM-0005yE-3R for nea@ietf.org; Thu, 18 May 2006 13:00:24 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 18 May 2006 10:00:23 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,142,1146466800"; d="scan'208"; a="551660837:sNHT23340824" 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] Device compromise and NEA? Date: Thu, 18 May 2006 13:00:24 -0400 Message-ID: In-Reply-To: <279DDDAFA85EC74C9300A0598E7040560BE960@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Device compromise and NEA? Thread-Index: AcZ6NVX1ksds8VHLQlqbsKsku6zLAQATiJ7wAAZB7HA= From: "Stephen Hanna" To: "Blumenthal, Uri" , "Narayanan, Vidya" , X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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 Uri, This was an excellent response. Thanks for sending it. Take care, Steve > -----Original Message----- > From: Blumenthal, Uri [mailto:uri.blumenthal@intel.com]=20 > Sent: Thursday, May 18, 2006 10:34 AM > To: Narayanan, Vidya; nea@ietf.org > Subject: RE: [Nea] Device compromise and NEA? >=20 > You don't remember that this fundamental question was already asked at > the last BOF by Bob Hinden in your presence? And that it was=20 > answered at > the mike right then and there? For the benefits of others who were not > present, I'm repeating that fundamental answer (as I happened to > contribute a part of it, as you might recall now). >=20 > First - there are hardware trust anchors that stand secure=20 > even when the > software gets compromised (for your education, look up TCG TPM > architecture, IBM Cell processor, AMD Presidio approach, and various > Intel technologies such as SIS/VISN). When those are employed, even a > "compromised" host may still be unable to falsify its posture. Posture > Collectors may well be protected by hardware. NEA doesn't protect a > system merely by itself. The greater its collaboration with other > security mechanisms - the greater its strength.=20 >=20 > Second - several people in the field, such as large=20 > enterprise customers > - expressed their need for a mechanism like NEA, EVEN if there is no > hardware-based security. Because in that case NEA acts for them as > "vaccination" rather than "cure". NEA can help IT to determine what > as-of-yet-healthy systems may need patches to their critical software, > etc - and put the unpatched ones to remediation network for=20 > scanning and > software upgrade. So all the systems connected to the=20 > intranet stay at > the top of security level, currently available to IT=20 > department. Doesn't > guarantee health - but improves its likelihood considerably. >=20 >=20 > And to dispel illusions - no, NEA is not the answer to every=20 > problem on > the planet - and it is technically possible (though highly improbable) > that despite NEA and every other security technology=20 > utilized, a host is > compromised to such an extent that its posture CAN be falsified. So > what? We know that even bank vaults are occasionally burglarized - > because of that do we stop installing door locks (of normal size) and > security systems in our houses??? >=20 >=20 >=20 > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com]=20 > Sent: Thursday, May 18, 2006 12:42 AM > To: nea@ietf.org > Subject: [Nea] Device compromise and NEA? >=20 >=20 > All, > I have a fundamental question regarding the NEA work. If a device is > compromised, how can there be any trust in the posture attributes that > it may be reporting?=20 >=20 > Vidya >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu May 18 13:04:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FglvP-0001Zf-1H; Thu, 18 May 2006 13:04:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FglvO-0001Wj-3l for nea@ietf.org; Thu, 18 May 2006 13:04:34 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FglvN-000674-Q1 for nea@ietf.org; Thu, 18 May 2006 13:04:34 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 18 May 2006 10:04:33 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,142,1146466800"; d="scan'208"; a="551661724:sNHT23086048" 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] Device compromise and NEA? Date: Thu, 18 May 2006 13:04:34 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Device compromise and NEA? Thread-Index: AcZ6NVX1ksds8VHLQlqbsKsku6zLAQATiJ7wAAZB7HAAACGkAA== From: "Stephen Hanna" To: "Blumenthal, Uri" , "Narayanan, Vidya" , X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f 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 Oops. Reply-All !=3D Reply. Thanks, Steve > -----Original Message----- > From: Stephen Hanna=20 > Sent: Thursday, May 18, 2006 1:00 PM > To: Blumenthal, Uri; Narayanan, Vidya; nea@ietf.org > Subject: RE: [Nea] Device compromise and NEA? >=20 > Uri, >=20 > This was an excellent response. Thanks for sending it. >=20 > Take care, >=20 > Steve >=20 > > -----Original Message----- > > From: Blumenthal, Uri [mailto:uri.blumenthal@intel.com]=20 > > Sent: Thursday, May 18, 2006 10:34 AM > > To: Narayanan, Vidya; nea@ietf.org > > Subject: RE: [Nea] Device compromise and NEA? > >=20 > > You don't remember that this fundamental question was=20 > already asked at > > the last BOF by Bob Hinden in your presence? And that it was=20 > > answered at > > the mike right then and there? For the benefits of others=20 > who were not > > present, I'm repeating that fundamental answer (as I happened to > > contribute a part of it, as you might recall now). > >=20 > > First - there are hardware trust anchors that stand secure=20 > > even when the > > software gets compromised (for your education, look up TCG TPM > > architecture, IBM Cell processor, AMD Presidio approach, and various > > Intel technologies such as SIS/VISN). When those are=20 > employed, even a > > "compromised" host may still be unable to falsify its=20 > posture. Posture > > Collectors may well be protected by hardware. NEA doesn't protect a > > system merely by itself. The greater its collaboration with other > > security mechanisms - the greater its strength.=20 > >=20 > > Second - several people in the field, such as large=20 > > enterprise customers > > - expressed their need for a mechanism like NEA, EVEN if there is no > > hardware-based security. Because in that case NEA acts for them as > > "vaccination" rather than "cure". NEA can help IT to determine what > > as-of-yet-healthy systems may need patches to their=20 > critical software, > > etc - and put the unpatched ones to remediation network for=20 > > scanning and > > software upgrade. So all the systems connected to the=20 > > intranet stay at > > the top of security level, currently available to IT=20 > > department. Doesn't > > guarantee health - but improves its likelihood considerably. > >=20 > >=20 > > And to dispel illusions - no, NEA is not the answer to every=20 > > problem on > > the planet - and it is technically possible (though highly=20 > improbable) > > that despite NEA and every other security technology=20 > > utilized, a host is > > compromised to such an extent that its posture CAN be falsified. So > > what? We know that even bank vaults are occasionally burglarized - > > because of that do we stop installing door locks (of normal=20 > size) and > > security systems in our houses??? > >=20 > >=20 > >=20 > > -----Original Message----- > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com]=20 > > Sent: Thursday, May 18, 2006 12:42 AM > > To: nea@ietf.org > > Subject: [Nea] Device compromise and NEA? > >=20 > >=20 > > All, > > I have a fundamental question regarding the NEA work. If a device is > > compromised, how can there be any trust in the posture=20 > attributes that > > it may be reporting?=20 > >=20 > > Vidya > >=20 > > _______________________________________________ > > Nea mailing list > > Nea@ietf.org > > https://www1.ietf.org/mailman/listinfo/nea > >=20 > > _______________________________________________ > > Nea mailing list > > Nea@ietf.org > > https://www1.ietf.org/mailman/listinfo/nea > >=20 >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu May 18 13:18:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgm8V-0007Kh-8y; Thu, 18 May 2006 13:18:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgm8T-0007Kc-Pd for nea@ietf.org; Thu, 18 May 2006 13:18:05 -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 1Fgm8T-0006fw-Ee for nea@ietf.org; Thu, 18 May 2006 13:18:05 -0400 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101-1.ch.intel.com with ESMTP; 18 May 2006 10:18:00 -0700 Received: from fmsmsx331.fm.intel.com (HELO fmsmsx331.amr.corp.intel.com) ([132.233.42.156]) by azsmga001.ch.intel.com with ESMTP; 18 May 2006 10:17:00 -0700 X-IronPort-AV: i="4.05,142,1146466800"; d="scan'208"; a="38410508:sNHT62797882826" Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 10:16:21 -0700 Received: from hdsmsx401.amr.corp.intel.com ([10.127.2.60]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 10:16:20 -0700 Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by hdsmsx401.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 18 May 2006 13:16:19 -0400 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] Device compromise and NEA? Date: Thu, 18 May 2006 13:16:11 -0400 Message-ID: <279DDDAFA85EC74C9300A0598E7040560BEA48@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Device compromise and NEA? Thread-Index: AcZ6mvaaGTmecijGSB2zM1sgkxnJPAAAf4dg From: "Blumenthal, Uri" To: "Marcus Leech" X-OriginalArrivalTime: 18 May 2006 17:16:19.0369 (UTC) FILETIME=[C74BC190:01C67A9E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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 Blumenthal, Uri wrote: >> First - there are hardware trust anchors that stand secure even when the >> software gets compromised (for your education, look up TCG TPM >> architecture, IBM Cell processor, AMD Presidio approach, and various >> Intel technologies such as SIS/VISN). When those are employed, even a >> "compromised" host may still be unable to falsify its posture. Posture >> Collectors may well be protected by hardware. NEA doesn't protect a >> system merely by itself. The greater its collaboration with other >> security mechanisms - the greater its strength.=20 > =20 > The fact that there's a hardware device that signs data doesn't > prevent that device from being lied to by the host computer that > it's embedded in. You know that, Uri. Yes I do - which is why I listed TPM as only ONE of several technologies that can be used (together) to secure the host. > But this work in NEA must proceed on the assumption that despite > the fundamental "shaky science" aspects of all this, there's some > value to it, and that to the extent that there's value in it, > standardizing protocols and architectures is a good thing. Certainly. Paraphrasing - there are ways to steal a car, but their existence does not invalidate the need for car locks. :-) > But we should never kid ourselves that "TPM fix everything".=20 > It doesn't.=20 No, of course not. And TPM will just as happily sign things for me as it does for you (assuming I managed to steal the "access key").=20 But consider something like, say Embedded IT or Active Management Technology (or similar initiatives by others) - it (together with TPM) helps quite a bit. > You can't get around the Halting Problem, and you can't pretend > that the host machines aren't Turing Complete. :-) I'm not going to. =20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu May 18 14:36:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgnM9-0001hi-8w; Thu, 18 May 2006 14:36:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgnM8-0001hd-2q for nea@ietf.org; Thu, 18 May 2006 14:36:16 -0400 Received: from e32.co.us.ibm.com ([32.97.110.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgnM7-0002ou-Fj for nea@ietf.org; Thu, 18 May 2006 14:36:16 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k4IIaEqh004261 for ; Thu, 18 May 2006 14:36:14 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k4IIaEan188684 for ; Thu, 18 May 2006 12:36:14 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id k4IIaDmP008898 for ; Thu, 18 May 2006 12:36:14 -0600 Received: from d03nm129.boulder.ibm.com (d03nm129.boulder.ibm.com [9.17.195.155]) by d03av03.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id k4IIaD2E008883; Thu, 18 May 2006 12:36:13 -0600 In-Reply-To: <126EBB1F0092E14B9E595D03263235AA911751@SCES1.sc.nevisnetworks.com> Subject: RE: [Nea] Device compromise and NEA? To: "Joseph Tardo" X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 Message-ID: From: Frank Yeh Jr Date: Thu, 18 May 2006 11:36:06 -0700 X-MIMETrack: Serialize by Router on D03NM129/03/M/IBM(Release 7.0.1HF123 | April 14, 2006) at 05/18/2006 12:39:21 MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9c7d7a899dc8f3389bf7ace6f0ad8e29 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: , Content-Type: multipart/mixed; boundary="===============1293083364==" Errors-To: nea-bounces@ietf.org --===============1293083364== Content-type: multipart/related; Boundary="0__=07BBFBE1DFF617158f9e8a93df938690918c07BBFBE1DFF61715" --0__=07BBFBE1DFF617158f9e8a93df938690918c07BBFBE1DFF61715 Content-type: multipart/alternative; Boundary="1__=07BBFBE1DFF617158f9e8a93df938690918c07BBFBE1DFF61715" --1__=07BBFBE1DFF617158f9e8a93df938690918c07BBFBE1DFF61715 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Greetings, In and of itself, I would agree that NEA is not a good reactive mechanism. However, other developments in the area of trusted computing= would allow NEA to leverage a trusted computing model to ensure that endpoints CAN be trusted not to lie. IMHO, NEA can support the deployme= nt of trusted computing solutions. I question whether this dynamic needs t= o bespecifically accomodated by the NEA work or if we can just leave thin= gs transparent to each other. Regards, Frank Yeh Corporate Security Strategy Team IBM Tivoli Software = "Joseph Tardo" = = To "Narayanan, Vidya" = 05/18/2006 01:02 , = AM = = cc = Subj= ect RE: [Nea] Device compromise and = NEA? = = = = = = = Vidya, I personally believe NEA is purely a proactive play, that is, it strive= s to remediate the truthful but vulnerable endpoint before that endpoint becomes infected. It does this by not admitting the vulnerable or questionable endpoint onto the network until it is brought into compliance, thus keeping malware from infecting that client. NEA is not necessarily effective as a reactive mechanism. It provides n= o guarantee that it will detect an already infected endpoint, since that endpoint cannot be trusted not to lie. In such a case, NEA might not prevent an infected and out of compliance endpoint from being admitted onto the network. Such an event would have limited consequence anyway i= f you have deployed NEA everywhere, or so it is said, since there will be= very few available victims around. Thus you can only be sure that if an endpoint is in compliance then it will be admitted, and if an endpoint is not admitted then it is not in compliance, but not vice-versa. That is, these are not if-an-only-if. I= f an endpoint is admitted if might or might not be in compliance, and if it is out of compliance it might or might not be admitted. It would thus be highly unadvisable to rely on NEA alone for preventing= malware from entering the network. Other reactive measures should be used as well. Of course, all this applies to today's software-only implementations on= available OS. With hardware or other isolation in place, things would b= e quite different Thanks, --Joe -----Original Message----- From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] Sent: Wednesday, May 17, 2006 9:42 PM To: nea@ietf.org Subject: [Nea] Device compromise and NEA? All, I have a fundamental question regarding the NEA work. If a device is compromised, how can there be any trust in the posture attributes that it may be reporting? Vidya _______________________________________________ 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 = --1__=07BBFBE1DFF617158f9e8a93df938690918c07BBFBE1DFF61715 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Greetings,

In and of itself, I would agree that NEA is not a good reactive mechan= ism. However, other developments in the area of trusted computing would= allow NEA to leverage a trusted computing model to ensure that endpoin= ts CAN be trusted not to lie. IMHO, NEA can support the deployment of t= rusted computing solutions. I question whether this dynamic needs to be= specifically accomodated by the NEA work or if we can just leave things= transparent to each other.

Regards,
Frank Yeh
Corporate Security Strategy Team
IBM
Tivoli Software

3D"Inactive"Josep= h Tardo" <joseph.tardo@nevisnetworks.com>


=
          "Joseph Tardo" <joseph.tardo@nevis= networks.com>

          05/18/2006 01:02 AM

 =
3D=
To
3D""
"Narayanan, Vidya" <vidyan@qualcomm.com&g= t;, <nea@ietf.org>
3D=
cc
3D""
3D=
Subject
3D""
RE: [Nea] Device compromise and NEA?
3D=3D""

Vidya,

I personally believe NEA is purely a proactive play, that is, it strive= s
to remediate the truthful but vulnerable endpoint before that endpoint<= br> becomes infected. It does this by not admitting the vulnerable or
questionable endpoint onto the network until it is brought into
compliance, thus keeping malware from infecting that client.

NEA is not necessarily effective as a reactive mechanism. It provides n= o
guarantee that it will detect an already infected endpoint, since that<= br> endpoint cannot be trusted not to lie. In such a case, NEA might not prevent an infected and out of compliance endpoint from being admitted<= br> onto the network. Such an event would have limited consequence anyway i= f
you have deployed NEA everywhere, or so it is said, since there will be=
very few available victims around.

Thus you can only be sure that if an endpoint is in compliance then it<= br> will be admitted, and if an endpoint is not admitted then it is not in<= br> compliance, but not vice-versa. That is, these are not if-an-only-if. I= f
an endpoint is admitted if might or might not be in compliance, and if<= br> it is out of compliance it might or might not be admitted.

It would thus be highly unadvisable to rely on NEA alone for preventing=
malware from entering the network. Other reactive measures should be used as well.

Of course, all this applies to today's software-only implementations on=
available OS. With hardware or other isolation in place, things would b= e
quite different

Thanks,
--Joe


-----Original Message-----
From: Narayanan, Vidya [mailto:v= idyan@qualcomm.com]
Sent: Wednesday, May 17, 2006 9:42 PM
To: nea@ietf.org
Subject: [Nea] Device compromise and NEA?


All,
I have a fundamental question regarding the NEA work. If a device is compromised, how can there be any trust in the posture attributes that<= br> it may be reporting?

Vidya

_______________________________________________
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

= --1__=07BBFBE1DFF617158f9e8a93df938690918c07BBFBE1DFF61715-- --0__=07BBFBE1DFF617158f9e8a93df938690918c07BBFBE1DFF61715 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=07BBFBE1DFF617158f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=07BBFBE1DFF617158f9e8a93df938690918c07BBFBE1DFF61715 Content-type: image/gif; name="pic15790.gif" Content-Disposition: inline; filename="pic15790.gif" Content-ID: <2__=07BBFBE1DFF617158f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=07BBFBE1DFF617158f9e8a93df938690918c07BBFBE1DFF61715 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <3__=07BBFBE1DFF617158f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=07BBFBE1DFF617158f9e8a93df938690918c07BBFBE1DFF61715-- --===============1293083364== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea --===============1293083364==-- From nea-bounces@ietf.org Thu May 18 14:50:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgnZZ-0000K4-20; Thu, 18 May 2006 14:50:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgnZX-0000Jy-Hl for nea@ietf.org; Thu, 18 May 2006 14:50:07 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgnZV-00043r-3i for nea@ietf.org; Thu, 18 May 2006 14:50:07 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4IInxlO019675 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 18 May 2006 11:50:00 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4IInwsa002481; Thu, 18 May 2006 11:49:59 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 11:49:58 -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] Device compromise and NEA? Date: Thu, 18 May 2006 11:49:58 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB8488292E@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Device compromise and NEA? Thread-Index: AcZ6NVX1ksds8VHLQlqbsKsku6zLAQATiJ7wAAj7StA= From: "Narayanan, Vidya" To: "Blumenthal, Uri" , X-OriginalArrivalTime: 18 May 2006 18:49:58.0720 (UTC) FILETIME=[DCB0AC00:01C67AAB] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 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 Uri, >=20 > You don't remember that this fundamental question was already=20 > asked at the last BOF by Bob Hinden in your presence? And=20 > that it was answered at the mike right then and there? For=20 > the benefits of others who were not present, I'm repeating=20 > that fundamental answer (as I happened to contribute a part=20 > of it, as you might recall now). >=20 I remember very well and in fact, went back to the minutes to re-read the response before I sent this email :) I still lack clarity on this point (maybe it is just my ignorance)!=20 > First - there are hardware trust anchors that stand secure=20 > even when the software gets compromised (for your education,=20 > look up TCG TPM architecture, IBM Cell processor, AMD=20 > Presidio approach, and various Intel technologies such as=20 > SIS/VISN). When those are employed, even a "compromised" host=20 > may still be unable to falsify its posture. Posture=20 > Collectors may well be protected by hardware. NEA doesn't=20 > protect a system merely by itself. The greater its=20 > collaboration with other security mechanisms - the greater=20 > its strength.=20 >=20 I admit that I'm not too familiar with the TCG TPM architecture - however, I understand the basis you are talking about here. I saw that Marcus made some excellent points here and don't feel the need to rehash those.=20 > Second - several people in the field, such as large=20 > enterprise customers > - expressed their need for a mechanism like NEA, EVEN if=20 > there is no hardware-based security. Because in that case NEA=20 > acts for them as "vaccination" rather than "cure". NEA can=20 > help IT to determine what as-of-yet-healthy systems may need=20 > patches to their critical software, etc - and put the=20 > unpatched ones to remediation network for scanning and=20 > software upgrade. So all the systems connected to the=20 > intranet stay at the top of security level, currently=20 > available to IT department. Doesn't guarantee health - but=20 > improves its likelihood considerably. >=20 While I can see some limited applicability here, I am very curious to see the threat model for NEA. Perhaps I should wait for the security analysis document. The plan is to have this prior to the next BoF, right?=20 >=20 > And to dispel illusions - no, NEA is not the answer to every=20 > problem on the planet - and it is technically possible=20 > (though highly improbable) that despite NEA and every other=20 > security technology utilized, a host is compromised to such=20 > an extent that its posture CAN be falsified. So what? We know=20 > that even bank vaults are occasionally burglarized - because=20 > of that do we stop installing door locks (of normal size) and=20 > security systems in our houses??? >=20 >=20 I don't see how it is highly improbable as you say above. If the point of NEA is to ensure the health of well-behaved hosts, then, the scope should explicitly say so. First of all, I see it as a huge deal of complexity to even get to a point of posture attribute collection from applications - on top of that, I see this solving a narrow use case. We have to keep in mind that unless there is a big change in mindset, a trusted kernel and trusted hardware needed to really make NEA useful puts it out of the enterprise market. Even with that, this seems like a perception of trust within a perimeter which does not necessarily reflect reality!=20 Regards, Vidya >=20 > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > Sent: Thursday, May 18, 2006 12:42 AM > To: nea@ietf.org > Subject: [Nea] Device compromise and NEA? >=20 >=20 > All, > I have a fundamental question regarding the NEA work. If a device is > compromised, how can there be any trust in the posture attributes that > it may be reporting?=20 >=20 > Vidya >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu May 18 15:09:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgns8-0007ZL-98; Thu, 18 May 2006 15:09:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgns6-0007ZG-T4 for nea@ietf.org; Thu, 18 May 2006 15:09:18 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgns4-0005OE-J8 for nea@ietf.org; Thu, 18 May 2006 15:09:18 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 18 May 2006 12:09:16 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,142,1146466800"; d="scan'208"; a="547547130:sNHT21381276" 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] Revised draft NEA charter Date: Thu, 18 May 2006 15:09:17 -0400 Message-ID: In-Reply-To: <0MKp2t-1FgVrw26Gy-00021f@mrelay.perfora.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Revised draft NEA charter Thread-Index: AcZ5/TK96YKZLzFqSlWmAS+rsP1glQADzqPwAB+KJQA= From: "Stephen Hanna" To: "Alper Yegin" , 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 As we all know, the "EAP lower layer" (protocols that carry EAP) is somewhat standardized. Less so than EAP and RADIUS. The rough consensus on the NEA mailing list after the last BOF was that the NEA should not focus on standardization in this area, at least not at this time. NEA should provide requirements for transport protocols (PTT/PTC) based on the needs of PA and PB but not otherwise address this area for now. I think the charter should be revised to make this clear. Thanks, Steve > -----Original Message----- > From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 > Sent: Wednesday, May 17, 2006 7:56 PM > To: nea@ietf.org > Subject: RE: [Nea] Revised draft NEA charter >=20 > > Given that well-established protocols already exist for the > > lowest layers in the NEA architectures (such as EAP and RADIUS), the >=20 > Does the above text take the so-called "EAP lower layer" into=20 > consideration? > Examples in the bracket misses that aspect. >=20 > The earlier charter had said: >=20 > 3. Posture Transport Carrier (PTC) protocol: The EAP=20 > framework supports > running EAP over multiple carriers. Targeted deployment scenarios for > NEA include both L2 and L3 network access scenarios. Existing=20 > standards > used in NEA include 802.1x for L2 network access. Requirements need to > be defined for an EAP over L3 transport for L3 access scenarios. >=20 > Susan had stated that 802.1X is there for some specific=20 > deployments. That's > fine. But what about for those that require EAP/L3 as the=20 > previous charter > stated? >=20 > Alper >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu May 18 15:27:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgoA1-0004Mn-KZ; Thu, 18 May 2006 15:27:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgoA1-0004Mi-0H for nea@ietf.org; Thu, 18 May 2006 15:27:49 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgo9z-0007g5-Nq for nea@ietf.org; Thu, 18 May 2006 15:27:48 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 18 May 2006 12:27:44 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,142,1146466800"; d="scan'208"; a="551694178:sNHT4657887760" 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] Revised draft NEA charter Date: Thu, 18 May 2006 15:27:44 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Revised draft NEA charter Thread-Index: AcZ5/TK96YKZLzFqSlWmAS+rsP1glQAg58tgAALGizA= From: "Stephen Hanna" To: , X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 Gene, Thanks for your comments. Let me address your questions directly. > PA, the Posture Attribute protocol. What is the proper=20 > interpretation for > what could qualify as an "attribute"? This definition works=20 > for me if an > attribute could be any data object. I would have reservations if an > attribute implies constraints on the richness of the data object. As the charter says, both standard attributes and vendor-specific attributes will be supported. I don't want to prejudge the work of the NEA WG but I suspect that few constraints will be placed on the contents or format of vendor-specific attributes. > PB, Posture Broker protocol. I read the definition to imply=20 > that given a set > of Posture Collectors and a set of Posture Validators, the PB strictly > partitions PCs into subsets and PVs into subsets so that a PC=20 > subset maps > one-to-one to a PV subset. This would recognize a near term=20 > reality that PC > subsets and PV subsets maybe from a single implementer=20 > (vendor) and that the > PB maintains the separation of PA between implementers (vendors). This > definition does not work for me if we envision a future where posture > attributes could flow between different implementers. Once standard attributes are defined, the one-to-one PC-PV pair model breaks down. So I agree with you that such a model should not be employed. I don't think the charter implies such a thing but maybe the language could be clarified. Any suggestions? > PTT, Posture Tunnel Transport protocol. I read this definition as a > transport for a bundle (set) of PB. This definition works=20 > were we see the > partitioning of the PC and PV. My concern here is the same as=20 > for the PB. PTT is only "a transport protocol suitable for carrying the PB protocol". No implication about partitioning PCs and PVs was intended. I don't see how it's implied by the current language. Could you point that out? Maybe clarifying the description of PB will help. Or maybe we'll just let people read the requirements document which will presumably clarify this. Thanks, Steve _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu May 18 16:59:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgpb3-0000ri-LK; Thu, 18 May 2006 16:59:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgpb2-0000r9-LR for nea@ietf.org; Thu, 18 May 2006 16:59:48 -0400 Received: from mout.perfora.net ([217.160.230.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgpb2-0005qw-Dk for nea@ietf.org; Thu, 18 May 2006 16:59:48 -0400 Received: from [24.7.38.250] (helo=sysadmin13c23c) by mrelay.perfora.net (node=mrelayus1) with ESMTP (Nemesis), id 0MKp2t-1Fgpaw2bcI-00020V; Thu, 18 May 2006 16:59:45 -0400 From: "Alper Yegin" To: "'Stephen Hanna'" , Subject: RE: [Nea] Revised draft NEA charter Date: Thu, 18 May 2006 23:59:34 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-index: AcZ5/TK96YKZLzFqSlWmAS+rsP1glQADzqPwAB+KJQAADKL5gA== Message-ID: <0MKp2t-1Fgpaw2bcI-00020V@mrelay.perfora.net> X-Provags-ID: perfora.net abuse@perfora.net login:abf7a4bb310ea4dfc9b6841113e2970f X-Spam-Score: 0.0 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 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, I agree with what you are saying. In fact, what you said is aligned with the earlier charter as I had quoted below. Than maybe we should restore that text. As you know, L3 transport for EAP is PANA. If we understand the requirements, we can figure out what additional things need to be done, if any. We may need to define NEA-specific AVPs, maybe. Alper > -----Original Message----- > From: Stephen Hanna [mailto:shanna@juniper.net] > Sent: Thursday, May 18, 2006 10:09 PM > To: Alper Yegin; nea@ietf.org > Subject: RE: [Nea] Revised draft NEA charter > > As we all know, the "EAP lower layer" (protocols that carry > EAP) is somewhat standardized. Less so than EAP and RADIUS. > The rough consensus on the NEA mailing list after the last > BOF was that the NEA should not focus on standardization > in this area, at least not at this time. NEA should provide > requirements for transport protocols (PTT/PTC) based on > the needs of PA and PB but not otherwise address this area > for now. > > I think the charter should be revised to make this clear. > > Thanks, > > Steve > > > -----Original Message----- > > From: Alper Yegin [mailto:alper.yegin@yegin.org] > > Sent: Wednesday, May 17, 2006 7:56 PM > > To: nea@ietf.org > > Subject: RE: [Nea] Revised draft NEA charter > > > > > Given that well-established protocols already exist for the > > > lowest layers in the NEA architectures (such as EAP and RADIUS), the > > > > Does the above text take the so-called "EAP lower layer" into > > consideration? > > Examples in the bracket misses that aspect. > > > > The earlier charter had said: > > > > 3. Posture Transport Carrier (PTC) protocol: The EAP > > framework supports > > running EAP over multiple carriers. Targeted deployment scenarios for > > NEA include both L2 and L3 network access scenarios. Existing > > standards > > used in NEA include 802.1x for L2 network access. Requirements need to > > be defined for an EAP over L3 transport for L3 access scenarios. > > > > Susan had stated that 802.1X is there for some specific > > deployments. That's > > fine. But what about for those that require EAP/L3 as the > > previous charter > > stated? > > > > Alper > > > > > > > > > > > > > > > > > > _______________________________________________ > > 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 May 18 22:12:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FguTb-0008As-K2; Thu, 18 May 2006 22:12:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FguTZ-0008Ac-B7 for nea@ietf.org; Thu, 18 May 2006 22:12:25 -0400 Received: from nokia350.mtghouse.com ([64.140.235.198] helo=mail.mtghouse.com) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FguTY-0007ad-1X for nea@ietf.org; Thu, 18 May 2006 22:12:25 -0400 Received: (qmail 14526 invoked from network); 18 May 2006 22:12:16 -0400 Received: from unknown (HELO genec) (172.22.22.216) by mail.mtghouse.com with SMTP; 18 May 2006 22:12:16 -0400 From: "Eugene Chang" To: "'Stephen Hanna'" , Subject: RE: [Nea] Revised draft NEA charter Date: Thu, 18 May 2006 22:12:11 -0400 Organization: Meetinghouse Message-ID: <04c201c67ae9$a3bf9c10$0c0aa8c0@genec> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZ5/TK96YKZLzFqSlWmAS+rsP1glQAg58tgAALGizAAFw48UA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: echang@mtghouse.com List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Steve, I reread the definition for the PB. "PB, the Posture Broker protocol, aggregates posture attributes from one or more Posture Collectors in an NEA client and sends them to the NEA server for assessment by one or more Posture Validators." It maybe that the problem I described comes from my reading that the definition allows for more than one instance of the PB. If there is more than one instance, then the partitioning can happen. If there is only one PB then there is no partitioning. I don't see a graceful way to change the wording to prevent a reading that has more than one instance of the PB. I would agree to leaving the language as is and leave further discussion to the requirements document. Thanks for clarification. Gene -------------------------------------------------------------------------- Eugene Chang Meetinghouse voice: +1-603-610-8678 mobile: +1-781-799-0233 fax: +1-603-430-8436 email: echang@mtghouse.com email: eugene.chang@ieee.org skype: gene02421 -----Original Message----- From: Stephen Hanna [mailto:shanna@juniper.net] Sent: Thursday, May 18, 2006 3:28 PM To: echang@mtghouse.com; nea@ietf.org Subject: RE: [Nea] Revised draft NEA charter Gene, Thanks for your comments. Let me address your questions directly. > PA, the Posture Attribute protocol. What is the proper > interpretation for > what could qualify as an "attribute"? This definition works > for me if an > attribute could be any data object. I would have reservations if an > attribute implies constraints on the richness of the data object. As the charter says, both standard attributes and vendor-specific attributes will be supported. I don't want to prejudge the work of the NEA WG but I suspect that few constraints will be placed on the contents or format of vendor-specific attributes. > PB, Posture Broker protocol. I read the definition to imply > that given a set > of Posture Collectors and a set of Posture Validators, the PB strictly > partitions PCs into subsets and PVs into subsets so that a PC > subset maps > one-to-one to a PV subset. This would recognize a near term > reality that PC > subsets and PV subsets maybe from a single implementer > (vendor) and that the > PB maintains the separation of PA between implementers (vendors). This > definition does not work for me if we envision a future where posture > attributes could flow between different implementers. Once standard attributes are defined, the one-to-one PC-PV pair model breaks down. So I agree with you that such a model should not be employed. I don't think the charter implies such a thing but maybe the language could be clarified. Any suggestions? > PTT, Posture Tunnel Transport protocol. I read this definition as a > transport for a bundle (set) of PB. This definition works > were we see the > partitioning of the PC and PV. My concern here is the same as > for the PB. PTT is only "a transport protocol suitable for carrying the PB protocol". No implication about partitioning PCs and PVs was intended. I don't see how it's implied by the current language. Could you point that out? Maybe clarifying the description of PB will help. Or maybe we'll just let people read the requirements document which will presumably clarify this. Thanks, Steve _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri May 19 16:49:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhBur-0007o2-VR; Fri, 19 May 2006 16:49:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhBuq-0007nx-Hq for nea@ietf.org; Fri, 19 May 2006 16:49:44 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhBuo-0004su-0T for nea@ietf.org; Fri, 19 May 2006 16:49:44 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 19 May 2006 13:49:41 -0700 X-IronPort-AV: i="4.05,147,1146466800"; d="scan'208"; a="551973250:sNHT34760952" 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] Revised draft NEA charter Date: Fri, 19 May 2006 16:49:42 -0400 Message-ID: In-Reply-To: <2EBB8025B6D1BA41B567DB32C1D8DB8488281C@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Revised draft NEA charter Thread-Index: AcZ5/TK96YKZLzFqSlWmAS+rsP1glQAI0qrgAFkpUOA= From: "Stephen Hanna" To: "Narayanan, Vidya" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba 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 I don't think the NEA work needs to be restricted to enterprise environments. As the problem statement says, "Network assessment architectures have been targeted primarily at enterprise deployment scenarios to date." That's true of the past but I don't think it needs to be the case in the future. Could you review the charter and documents from a non-enterprise point of view (service provider, I presume?) and point out any deficiencies? Thanks, Steve > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com]=20 > Sent: Wednesday, May 17, 2006 10:14 PM > To: Stephen Hanna; nea@ietf.org > Subject: RE: [Nea] Revised draft NEA charter >=20 > A high level question - is the work solely targeting enterprise > environments? The problem statement alludes to this, but, this is not > clear from the charter.=20 >=20 > Thanks, > Vidya >=20 > > -----Original Message----- > > From: Stephen Hanna [mailto:shanna@juniper.net]=20 > > Sent: Wednesday, May 17, 2006 3:00 PM > > To: nea@ietf.org > > Subject: [Nea] Revised draft NEA charter > >=20 > > Folks, > >=20 > > Susan and I have revised the draft NEA WG charter to reflect=20 > > the consensus of the mailing list as reflected in the NEA=20 > > Action Plan agreed to in April. > >=20 > > Please review this draft and send feedback ASAP. Of course,=20 > > we can revise the charter up to Montreal but I'd like to get=20 > > a solid version by Friday so we can submit our BOF proposal=20 > > on Monday as the IESG has requested. > >=20 > > Thanks, > >=20 > > Steve > >=20 > > ------------- > >=20 > > Draft NEA WG Charter > > May 17, 2006 Version > >=20 > > Network Endpoint Assessment (NEA) architectures have been=20 > > implemented in the industry to assess the "posture" of=20 > > endpoint devices for the purposes of monitoring or enforcing=20 > > compliance to an organization's policy for access to the=20 > > network. Posture refers to the hardware or software=20 > > configuration of an endpoint as it pertains to an=20 > > organization's security policy. Posture may include knowledge=20 > > about the types of hardware and software installed and their=20 > > configurations, e.g. > > OS name and version, application patch levels, and anti-virus=20 > > signature file version. On network access, an endpoint with=20 > > an NEA Client can be queried for posture information which is=20 > > validated on an NEA Server as part of network access control. > >=20 > > Since NEA involves many different components from different=20 > > vendors, interoperation between NEA architectures and=20 > > implementations is highly desirable. Given that=20 > > well-established protocols already exist for the lowest=20 > > layers in the NEA architectures (such as EAP and RADIUS), the=20 > > priority of the NEA working group is to standardize protocols=20 > > at the higher layers in the architectures (known as PA and PB=20 > > and described later). When used with the existing standards=20 > > for lower layers, these new protocols will allow=20 > > interoperability between an NEA Client from one vendor and an=20 > > NEA Server from another. > >=20 > > Since there are already several existing protocols at these=20 > > higher layers, the NEA working group will consider these=20 > > existing protocols as candidates for standardization. A=20 > > requirements document will be written and used as a basis for=20 > > evaluating the candidate protocols. The working group may=20 > > decide to standardize one of the candidate protocols, use one=20 > > of them as a basis for a new or revised protocol, or decide=20 > > that a new protocol is needed. > >=20 > > The NEA Requirements document will include a problem=20 > > statement, definition of terms, requirements for PA, PB, and=20 > > an overall security analysis. It will also include=20 > > requirements for the protocol transporting PA, PB (known as=20 > > PTT and described below). > >=20 > > PA, the Posture Attribute protocol, consists of posture=20 > > attributes that are carried between a particular Posture=20 > > Collector in a NEA client and a particular Posture Validator=20 > > in a NEA Server. The PA protocol is carried inside the PB=20 > > protocol. Certain posture attributes will be standardized to=20 > > ensure interoperability but vendor-specific attributes will=20 > > also be supported. > >=20 > > PB, the Posture Broker protocol, aggregates posture=20 > > attributes from one or more Posture Collectors in an NEA=20 > > client and sends them to the NEA server for assessment by one=20 > > or more Posture Validators. > >=20 > > PTT, the Posture Transport Tunnel protocol is a transport=20 > > protocol suitable for carrying the PB protocol at or after=20 > > network connection. > >=20 > > Milestones: > >=20 > > June 2006: > > * Submit first version of NEA Requirements I-D > >=20 > > July 2006: > > * Agree on charter and milestones at IETF 66 > >=20 > > September 2006: > > * WG Last Call on NEA Requirements I-D=20 > >=20 > > October 2006: > > * Deadline for submission of candidate specs for PA and PB > > * Submit first version of NEA Evaluation I-D=20 > >=20 > > November 2006: > > * Review NEA Evaluation I-D at IETF 67 > >=20 > > December 2006: > > * WG Last Call on NEA Evaluation I-D > >=20 > > January 2007: > > * Submit NEA Requirements I-D and Evaluation I-D to IESG as Info RFC > > * Submit first draft of PA and PB specs for review > >=20 > > March 2007: > > * Discuss unresolved issues with PA and PB specs at IETF 68 > > * Agree on solutions to unresolved issues with PA and PB specs > >=20 > > April 2007: > > * Submit revised draft of PA and PB specs > >=20 > > June 2007 > > * WG Last Call on PA and PB specs > >=20 > > July 2007 > > * Resolve outstanding Last Call comments on requirements I-D=20 > > at IETF 69 > >=20 > > August 2007: > > * Submit PA and PB specs to IESG for publication as Proposed > >=20 > > _______________________________________________ > > Nea mailing list > > Nea@ietf.org > > https://www1.ietf.org/mailman/listinfo/nea > >=20 >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri May 19 17:56:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhCx6-00053d-2g; Fri, 19 May 2006 17:56:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FhCx4-00053Y-Df for nea@ietf.org; Fri, 19 May 2006 17:56:06 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FhCx1-00019R-UY for nea@ietf.org; Fri, 19 May 2006 17:56:06 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 19 May 2006 14:56:03 -0700 X-IronPort-AV: i="4.05,148,1146466800"; d="scan'208"; a="551984656:sNHT33723968" 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, 19 May 2006 17:56:04 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: May 19 NEA charter draft Thread-Index: AcZ7jwZE8Zzun/yDSFyxDopclheXjQ== From: "Stephen Hanna" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Subject: [Nea] May 19 NEA charter draft 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's today's NEA charter draft. In response to comments, I have made these changes (omitting minor rewordings): * Clarified that PA and PB will be designed to support a variety of lower layer protocols * Changed PTT to PT in the charter since the split between PTT and PTC is specific to EAP and we want our initial work to be transport-independent * Added several notes saying that specific requirements for EAP will be identified in order to achieve eventual interoperability via EAP * Added paragraph to clarify that work beyond PA and PB will be considered via the standard rechartering process after the completion of these milestones I hope and think that these changes will address most of the comments raised to date. If more comments emerge, I will do another draft on Monday to address those. We can continue to refine the text as needed up to the BOF. Thanks, Steve ------------ Proposed NEA WG Charter May 19, 2006 Version Network Endpoint Assessment (NEA) architectures have been implemented in the industry to assess the "posture" of endpoint devices for the purposes of monitoring or enforcing compliance to an organization's policy for access to the network. Posture refers to the hardware or software configuration of an endpoint as it pertains to an organization's security policy. Posture may include knowledge about the types of hardware and software installed and their configurations, e.g. OS name and version, application patch levels, and anti-virus signature file version. On network access, an endpoint with an NEA Client can be queried for posture information which is validated on an NEA Server as part of network access control. Since NEA involves many different components from different vendors, interoperation between NEA architectures and implementations is highly desirable. Given that well-established protocols already exist for the lowest layers in the NEA architectures (such as EAP and RADIUS), the priority of the NEA working group is to standardize protocols at the higher layers in the architectures: the Posture Attribute protocol (PA) and the Posture Broker protocol (PB). When used with the existing standards for lower layers, these new protocols will allow interoperability between an NEA Client from one vendor and an NEA Server from another. PA and PB will be designed to support a variety of lower layer protocols. In order to achieve eventual interoperability via EAP, specific requirements for EAP will be identified. Since there are already several existing protocols at these higher layers, the NEA working group will consider these existing protocols as candidates for standardization. A requirements document will be written and used as a basis for evaluating the candidate protocols. The working group may decide to standardize one of the candidate protocols, use one of them as a basis for a new or revised protocol, or decide that a new protocol is needed. The NEA Requirements document will include a problem statement, definition of terms, requirements for PA, PB, and an overall security analysis. It will also include requirements for the protocol transporting PA, PB: the Posture Transport protocol (PT). Specific requirements for an EAP instantiation of PT will be identified. PA, the Posture Attribute protocol, consists of posture attributes that are carried between a particular Posture Collector in a NEA client and a particular Posture Validator in a NEA Server. The PA protocol is carried inside the PB protocol. Certain posture attributes will be standardized to ensure interoperability but vendor-specific attributes will also be supported. PB, the Posture Broker protocol, aggregates posture attributes from one or more Posture Collectors in an NEA client and sends them to the NEA server for assessment by one or more Posture Validators. PT, the Posture Transport protocol, is a protocol (or stack of protocols) suitable for carrying the PB protocol at or after network connection. The NEA working group will not work on standardizing protocols other than PA and PB at this time. Such work will be considered via the standard rechartering process after the completion of these milestones. Milestones: June 2006: * Submit first version of NEA Requirements I-D July 2006: * Agree on charter and milestones at IETF 66 September 2006: * WG Last Call on NEA Requirements I-D=20 October 2006: * Deadline for submission of candidate specs for PA and PB * Submit first version of NEA Evaluation I-D=20 November 2006: * At IETF 67, review NEA Evaluation I-D December 2006: * WG Last Call on NEA Evaluation I-D January 2007: * Submit NEA Requirements I-D and Evaluation I-D to IESG as Info RFC * Submit first draft of PA and PB specs for review March 2007: * Discuss unresolved issues with PA and PB specs at IETF 68 * Agree on solutions to unresolved issues with PA and PB specs April 2007: * Submit revised draft of PA and PB specs June 2007 * WG Last Call on PA and PB specs July 2007 * Resolve outstanding Last Call comments on requirements I-D at IETF 69 August 2007: * Submit PA and PB specs to IESG for publication as Proposed _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon May 22 21:19:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiLYM-00086N-38; Mon, 22 May 2006 21:19:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiLYK-00086H-Jm; Mon, 22 May 2006 21:19:16 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiLYI-0000dI-1B; Mon, 22 May 2006 21:19:16 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 22 May 2006 18:19:03 -0700 X-IronPort-AV: i="4.05,158,1146466800"; d="scan'208"; a="548516871:sNHT26769189578" 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: Mon, 22 May 2006 21:19:04 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NEA BOF Request Thread-Index: AcYuejfIHhVT50FnSaquzZnZuO/WLBPX/jFAAArjPzA= From: "Stephen Hanna" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Cc: nea@ietf.org, housley@vigilsec.com Subject: [Nea] NEA BOF Request 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 This is a request on behalf of the Network Endpoint=20 Assessment (NEA) mailing list to have a BOF session at IETF 66 in the Security area. The members of the NEA mailing list have revised the proposed WG charter in response to feedback received at our last BOF at IETF 65. We have reached rough consensus for the charter below and a design team has started work on our requirements document. A draft is almost ready. The primary focus of this BOF will be to confirm the consensus on the charter with a broader audience. The latest requirements and problem statement documents will be submitted as Internet Drafts this evening and should appear in the repository soon. Thanks, Steve Hanna Susan Thomson ------------------------- BOF name: Network Endpoint Assessment (NEA) Area: Security Area Chair Names: Steve Hanna , Susan Thomson Conflicts: EMU WG, EAP WG, TLS WG, RADEXT WG, SAAG, PANA Expected Attendance: 100 Number of sessions: 1 Length of session: 2 hours email list: nea@ietf.org Draft Agenda: see below Proposed WG Charter: see below ------------ Network Endpoint Assessment (NEA) BOF Draft Agenda =20 Agenda Bashing (5 minutes) Discuss and Agree on NEA Charter (115 minutes) At IETF 65, an NEA BOF was held. Several things were clear: 1) This is important work. Many people spoke about this. 2) We need clear interoperability goals. 3) We should standardize at least a minimal set of posture attributes to allow any client and server to have some interoperability. 4) PA and PB should be transport independent. 5) We should not spend too much time on requirements. Since then, the members of the NEA mailing list have revised the proposed WG charter in response to this feedback. We have reached rough consensus on the charter below and a design team has started work on the requirements document. A draft is ready. The focus of the NEA BOF at IETF 66 will be to confirm the consensus on the revised charter with a broader audience and resolve any issues raised. NEA BOF participants are expected to have read the documents=20 listed below before the BOF meeting. Discussion of these=20 documents before the BOF meeting is strongly encouraged. It will take place on the nea@ietf.org mailing list. Network Endpoint Assessment (NEA) Problem Statement draft-thomson-nea-problem-statement-02.txt (Note that the problem statement will be combined into the requirements document after the WG charter is approved.) Requirements for Network Endpoint Access (NEA) draft-khosravi-nea-requirements-00.txt Proposed NEA Charter Mailing List nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea -------------------------- Proposed NEA WG Charter Network Endpoint Assessment (NEA) architectures have been implemented in the industry to assess the "posture" of endpoint devices for the purposes of monitoring or enforcing compliance to an organization's policy for access to the network. Posture refers to the hardware or software configuration of an endpoint as it pertains to an organization's security policy. Posture may include knowledge about the types of hardware and software installed and their configurations, e.g. OS name and version, application patch levels, and anti-virus signature file version. On network access, an endpoint with an NEA Client can be queried for posture information which is validated on an NEA Server as part of network access control. Since NEA involves many different components from different vendors, interoperation between NEA architectures and implementations is highly desirable. Given that well-established protocols already exist for the lowest layers in the NEA architectures (such as EAP and RADIUS), the priority of the NEA working group is to standardize protocols at the higher layers in the architectures: the Posture Attribute protocol (PA) and the Posture Broker protocol (PB). When used with the existing standards for lower layers, these new protocols will allow interoperability between an NEA Client from one vendor and an NEA Server from another. PA and PB will be designed to support a variety of lower layer protocols. In order to achieve eventual interoperability via EAP, specific requirements for EAP will be identified. Since there are already several existing protocols at these higher layers, the NEA working group will consider these existing protocols as candidates for standardization. A requirements document will be written and used as a basis for evaluating the candidate protocols. The working group may decide to standardize one of the candidate protocols, use one of them as a basis for a new or revised protocol, or decide that a new protocol is needed. The NEA Requirements document will include a problem statement, definition of terms, requirements for PA, PB, and an overall security analysis. It will also include requirements for the protocol transporting PA, PB: the Posture Transport protocol (PT). Specific requirements for an EAP instantiation of PT will be identified. PA, the Posture Attribute protocol, consists of posture attributes that are carried between a particular Posture Collector in a NEA client and a particular Posture Validator in a NEA Server. The PA protocol is carried inside the PB protocol. Certain posture attributes will be standardized to ensure interoperability but vendor-specific attributes will also be supported. PB, the Posture Broker protocol, aggregates posture attributes from one or more Posture Collectors in an NEA client and sends them to the NEA server for assessment by one or more Posture Validators. PT, the Posture Transport protocol, is a protocol (or stack of protocols) suitable for carrying the PB protocol at or after network connection. The NEA working group will not work on standardizing protocols other than PA and PB at this time. Such work will be considered via the standard rechartering process after the completion of these milestones. Milestones: June 2006: * Submit first version of NEA Requirements I-D July 2006: * Agree on charter and milestones at IETF 66 September 2006: * WG Last Call on NEA Requirements I-D=20 October 2006: * Deadline for submission of candidate specs for PA and PB * Submit first version of NEA Evaluation I-D=20 November 2006: * At IETF 67, review NEA Evaluation I-D December 2006: * WG Last Call on NEA Evaluation I-D January 2007: * Submit NEA Requirements I-D and Evaluation I-D to IESG as Info RFC * Submit first draft of PA and PB specs for review March 2007: * Discuss unresolved issues with PA and PB specs at IETF 68 * Agree on solutions to unresolved issues with PA and PB specs April 2007: * Submit revised draft of PA and PB specs June 2007 * WG Last Call on PA and PB specs July 2007 * Resolve outstanding Last Call comments on requirements I-D at IETF 69 August 2007: * Submit PA and PB specs to IESG for publication as Proposed _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon May 22 21:34:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiLmu-0004KZ-JR; Mon, 22 May 2006 21:34:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiLmt-0004KU-G7 for nea@ietf.org; Mon, 22 May 2006 21:34: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 1FiLmr-0001I1-U0 for nea@ietf.org; Mon, 22 May 2006 21:34:19 -0400 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101-1.ch.intel.com with ESMTP; 22 May 2006 18:33:37 -0700 Received: from orsmsx332.jf.intel.com (HELO orsmsx332.amr.corp.intel.com) ([192.168.65.60]) by azsmga001.ch.intel.com with ESMTP; 22 May 2006 18:33:37 -0700 X-IronPort-AV: i="4.05,158,1146466800"; d="scan'208"; a="40120222:sNHT26716543" Received: from orsmsx411.amr.corp.intel.com ([10.22.226.47]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 22 May 2006 18:33:36 -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 Date: Mon, 22 May 2006 18:33:35 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Meeting summary for May 17th Thread-Index: AcZnfgEedAZHPj0/SMWaazdF5s/3FwAQDKXAAAFnjXAAAdwCkAAIr3pAACZyafAAEamBoABTXWLQABCkxrACIM5MMACpi69AABtvmVAAyPeZ8ABxG9dgAABmc2AAylHcoA== From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 23 May 2006 01:33:36.0558 (UTC) FILETIME=[E94C7CE0:01C67E08] X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Subject: [Nea] Meeting summary for May 17th 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 All, Here is my rough meeting summary (for May 17th) Attendees Ravi, Paul, Hao, Diana, Amardeep, Kevin, Joe, Susan, Uri, Hormuzd Posture Attributes protocol high level requirements - Ravi 1. PA MUST define the data model to carry posture attributes between a particular Posture Collector in a NEA client and a particular Posture Validator in a NEA Server.=20 2. The PA protocol MUST be carried inside the PB protocol. 3. PA MUST support expression of default attributes to report component health at a coarse level for example, including vendor, version, operational status 4. PA MUST support expression of sub-component health including vendor, component, version, operational status Instead of MUST this must be a SHOULD or MAY PA MUST support Core and Vendor defined attributes Diana - Is PA a messaging format or a protocol? Paul - There is a control part to PA 5. PA MUST support expression of asynchronous attribute reportting, for example events, from collector or validator Hormuzd - common Req covers this Paul - Agreed Ravi - ok will remove this 6. PA MUST use open standard interfaces as far as possible for example, structured formats such as XML. 7. PA SHOULD support expression of meta-data around updates for components such as last update time, remediation server used Paul - clean the text up, not sure if this is a SHOULD or MAY Hao - Not about the protocol, about core attributes 8. PA MUST define the decision/remediation Hao - Any size limitation on PA protocol? Paul - collector & validator to authenticate each other? SHOULD req. Uri/Amardeep - discussion over emails =20 Posture Broker protocol high level requirements - Ravi 1. PB MUST aggregate posture attributes from one or more Posture Collectors in a NEA client Hao - PB protocol MUST allow 2. PB MUST support sending posture attributes to a NEA server for assessment by one or more Posture Validators. definition 3. PB MUST aggregate remediation attributes from one or more Posture Validators in a NEA server. definition 4. PB MUST carry additional decisions from the NEA server along with posture validator specific information. Paul - PB has very few reqs Open for discussion 5. PB MUST support dynamic registration, deregistration of posture collectors and validators Paul - doesnt belong to the protocol, more about the broker... Paul - this has to do with message routing, needs rewording Paul - discuss overall dynamic PC, PV requirement as common req 6. PB MUST support subscription on the NEA server for asynchronous information, example events from posture collectors 7. PB MUST support multiple rounds of posture collection from collectors within a transaction Hormuzd - do we need to repeat common reqs for different interfaces Ravi - this will have more protocol specific information 8. PB MUST support asynchronous push of posture/event information from collectors/NEA client Uri - leave this in for now and lets revisit this later Joe - this is not the norm right now Ravi - bin this now and revisit these later 9. PB MUST support asynchronous pull of posture information from validators/NEA server Paul - add a security requirement Security considerations should talk about the threats that are being addressed _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon May 22 21:35:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiLo0-0004U1-SD; Mon, 22 May 2006 21:35:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiLnz-0004Tw-4X for nea@ietf.org; Mon, 22 May 2006 21:35:27 -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 1FiLnx-0001Mw-Mc for nea@ietf.org; Mon, 22 May 2006 21:35:27 -0400 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101-1.ch.intel.com with ESMTP; 22 May 2006 18:34:32 -0700 Received: from orsmsx332.jf.intel.com (HELO orsmsx332.amr.corp.intel.com) ([192.168.65.60]) by azsmga001.ch.intel.com with ESMTP; 22 May 2006 18:34:31 -0700 X-IronPort-AV: i="4.05,158,1146466800"; d="scan'208"; a="40120640:sNHT39388776" Received: from orsmsx411.amr.corp.intel.com ([10.22.226.47]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 22 May 2006 18:34:08 -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 Date: Mon, 22 May 2006 18:34:08 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Meeting summary for May 18th Thread-Index: AcZnfgEedAZHPj0/SMWaazdF5s/3FwAQDKXAAAFnjXAAAdwCkAAIr3pAACZyafAAEamBoABTXWLQABCkxrACIM5MMACpi69AABtvmVAAyPeZ8ABxG9dgAMq//7A= From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 23 May 2006 01:34:08.0840 (UTC) FILETIME=[FC8A5480:01C67E08] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b Subject: [Nea] Meeting summary for May 18th 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 All, Here is my rough meeting summary (for May 18th)... Attendees- Steve, Uri, Susan, Hao, Diana, Kevin, Mauricio, Thomas, Paul, Amardeep, Ravi, Joe Susan - plan for this draft? Hormuzd - plan is to send 00 rev to chairs by Monday 3PM PST PTT Requirements Kevin - 1. The transport should use standard based protocols whenever possible. 2. The protocol should incur low overhead to accommodate for low bandwidth links 3. The Protocol should support half duplex communication 4. No assumptions of the data being transported (size,type,format).i.e. PA & PB -Data is opaque 5. Integrity and confidentiality of the data being transported. Should this be PTT or PTC? - The protocol MUST allow... 6. PTT should be able to be fragmented, detect duplicates, and ordered reassembled if necessary (reliable/guaranteed delivery) *Should make no assumptions of the PTC - remove this *Option for Server initiated? Client/server initiated -remove this, already in the common reqs or use same text from common reqs 7. Should be able to do Mutual authentication, or NAA/server authentication at a minimum or MUST. Allow for client authentication Uri - thinks mutual authentication should be a MUST Protocols MUST allow/support mutual authentication John - doesnt agree that mutual authentication is a MUST Hormuzd - bin this for now, revisit this *Reuse of negotiated session key - remove this *Should protect against MIM attacks (maybe) - remove this John - 1. Transport requirements a) Must be able to do Net endpoint evaluation prior to allowing access to the net - this implies being able to do as part of tunneled EAP conversation - at least for cases where the access control uses EAP - for cases where EAP is optional we need to either require use of tunneled EAP or define a different way to provide transport b) Must be able top NEA while endpoint has access to the network - this implies that a transport must be created between the endpoint (NAR) and the Endpoint Authorizer (NAA) - this probably implies setting up a TLS connection between NAR and NAA - addressing issues [who knows how to connect to the other, who initiates the connection] are not resolved - the conversation between NAA and PEP is not well understood for the already connected state Steve - Good requirements but cannot be met by a single protocol Hoa - same as server initiated or client initiated John - not clear what wg would do 1b) Kevin - rephrase 1 a& b. make into single requirement - agreement c) Must have secure transport between NAR and NAA - this seems to imply that the identity of the NAR as well as the user must be knownto the NAA - it is not clear to me exactly what the requirements for knowledge of NAA by the NAR Hao - is this a PTT requirement or generic req? Paul - agree with kevin, bin this for now John - take this discussion to the mailing list 2. PEP requirements a) PEP must be capable of using RADIUS for control prior to allowing access b) We may define other methods of control [e.g. SNMP, DHCP, more generic policy] for future use 3. Security a) NEA should define requirements for ensuring the use of valid NEA code at both client and server b) NEA should describe dangers of allowing Agents access to clients in terms of privacy for individuals and groups within organizations Security Considerations Action Items -=20 Everyone review the text sent out by Uri and send comments to team by Friday (tomorrow). Hormuzd/Paul - Send out initial rev of the draft to the team for review by Friday (tomorrow) Hormuzd/Paul - Send out -00rev draft to chairs by Monday May 22nd 3PM PST _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue May 23 00:57:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiOxO-0001he-6w; Tue, 23 May 2006 00:57:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiOxM-0001hY-8s for nea@ietf.org; Tue, 23 May 2006 00:57:20 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiOxL-0002B5-1p for nea@ietf.org; Tue, 23 May 2006 00:57:20 -0400 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 22 May 2006 21:57:19 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,158,1146466800"; d="scan'208"; a="28673664:sNHT21959256" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k4N4vIvF015463 for ; Tue, 23 May 2006 00:57:18 -0400 (EDT) Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 23 May 2006 00:57:18 -0400 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: Tue, 23 May 2006 00:57:17 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated problem statement I-D thread-index: AcZ+JV2r4BmkImCdSEeU/C2NciqkAA== From: "Susan Thomson \(sethomso\)" To: X-OriginalArrivalTime: 23 May 2006 04:57:18.0570 (UTC) FILETIME=[5E2F84A0:01C67E25] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Nea] Updated problem statement I-D 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 Have submitted an updated draft (-02 version) to IETF secretariat for publication. Relatively minor changes since -01 version to be consistent with revised charter and take into account comments received to -01 version. Change log in document and included below. There have been a few other comments on -01 doc that have not been addressed, in particular, a couple of requests for some terminology changes. Have not included these in this version, but will be discussed prior to next version which should be out before cut-off date of June 26. Thanks Susan --------------------- Change Log: * Section 7: Omitted specifying proposed initial scope of WG since this is the job of a charter. Replaced with more general text. * Clarified in Section 2 and 7 NEA-specific components/interfaces from transport part of architecture * Updates to reflect Mauricio Sanchez's comments to mailing list 03/08/2006 and response 03/13/2006 * Updated figures to have "vertical" line for PV protocol * Editorial updates _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue May 23 00:59:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiOzH-0001mT-6E; Tue, 23 May 2006 00:59:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiLea-0001kb-Cu for nea@ietf.org; Mon, 22 May 2006 21:25:44 -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 1FiLeW-0000rS-NZ for nea@ietf.org; Mon, 22 May 2006 21:25:44 -0400 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101-1.ch.intel.com with ESMTP; 22 May 2006 18:25:40 -0700 Received: from orsmsx331.jf.intel.com (HELO orsmsx331.amr.corp.intel.com) ([192.168.65.56]) by azsmga001.ch.intel.com with ESMTP; 22 May 2006 18:25:39 -0700 X-IronPort-AV: i="4.05,158,1146466800"; d="txt'?scan'208,217"; a="40117668:sNHT41337772" Received: from orsmsx411.amr.corp.intel.com ([10.22.226.47]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 22 May 2006 18:25:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C67E07.CCAF5EA6" Date: Mon, 22 May 2006 18:25:38 -0700 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: rev-00 of the Requirements draft Thread-Index: AcZ+B8xQYiaRPIKzSjOzw9M9Y+HbIA== From: "Khosravi, Hormuzd M" To: X-OriginalArrivalTime: 23 May 2006 01:25:39.0254 (UTC) FILETIME=[CCCDAD60:01C67E07] X-Spam-Score: 2.3 (++) X-Scan-Signature: a4ba408990f83ef962b4876088b8c71a X-Mailman-Approved-At: Tue, 23 May 2006 00:59:17 -0400 Subject: [Nea] rev-00 of the Requirements draft 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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C67E07.CCAF5EA6 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C67E07.CCAF5EA6" ------_=_NextPart_002_01C67E07.CCAF5EA6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi All, =20 Here is the -00 rev of the Requirements draft that the Requirements team has produced in just a couple of weeks. It has been submitted to the IETF. =20 I would like to thank everyone on the Requirements team for their extraordinary effort in pulling this through in a short period of time! =20 The team will continue working on this draft and we plan to submit rev-01 of this draft by June 26th. =20 Comments from the mailing list are welcome! =20 Regards Hormuzd =20 ------_=_NextPart_002_01C67E07.CCAF5EA6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

Here is the -00 rev of the Requirements draft that = the Requirements team has produced in just a couple of weeks. It has been = submitted to the IETF.

 

I would like to thank everyone on the Requirements = team for their extraordinary effort in pulling this through in a short period of = time!

 

The team will continue working on this draft and we = plan to submit rev-01 of this draft by June = 26th.

 

Comments from the mailing list are = welcome!

 

Regards

Hormuzd

 

------_=_NextPart_002_01C67E07.CCAF5EA6-- ------_=_NextPart_001_01C67E07.CCAF5EA6 Content-Type: text/plain; name="draft-khosravi-nea-requirements-00.txt" Content-Transfer-Encoding: base64 Content-Description: draft-khosravi-nea-requirements-00.txt Content-Disposition: attachment; filename="draft-khosravi-nea-requirements-00.txt" DQogIEludGVybmV0IERyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAgIEhvcm11emQgS2hv c3JhdmksIEludGVsIA0KICBFeHBpcmVzOiBOb3ZlbWJlciAyMDA2ICAgICAgICAgICAgICAgICAg ICBQYXVsIFNhbmdzdGVyLCBTeW1hbnRlYyAgICAgICAgICANCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgDQogIFdvcmtpbmcgR3JvdXA6IE5FQSAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBNYXkgMjAwNiANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgDQogICANCiAgIA0KICAgDQogICAgICAgICAgICAgICAgIFJl cXVpcmVtZW50cyBmb3IgTmV0d29yayBFbmRwb2ludCBBY2Nlc3MgKE5FQSkgDQogICAgICAgICAg ICAgICAgICAgIGRyYWZ0LWtob3NyYXZpLW5lYS1yZXF1aXJlbWVudHMtMDAudHh0IA0KICAgDQog ICANCiAgIA0KICBTdGF0dXMgb2YgdGhpcyBNZW1vIA0KICAgIA0KICAgQnkgc3VibWl0dGluZyB0 aGlzIEludGVybmV0LURyYWZ0LCBlYWNoIGF1dGhvciByZXByZXNlbnRzIHRoYXQgYW55IA0KICAg YXBwbGljYWJsZSBwYXRlbnQgb3Igb3RoZXIgSVBSIGNsYWltcyBvZiB3aGljaCBoZSBvciBzaGUg aXMgYXdhcmUgDQogICBoYXZlIGJlZW4gb3Igd2lsbCBiZSBkaXNjbG9zZWQsIGFuZCBhbnkgb2Yg d2hpY2ggaGUgb3Igc2hlIGJlY29tZXMgDQogICBhd2FyZSB3aWxsIGJlIGRpc2Nsb3NlZCwgaW4g YWNjb3JkYW5jZSB3aXRoIFNlY3Rpb24gNiBvZiBCQ1AgNzkuIA0KICAgICAgIA0KICAgSW50ZXJu ZXQtRHJhZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJp bmcgDQogICBUYXNrIEZvcmNlIChJRVRGKSwgaXRzIGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3Jv dXBzLiAgTm90ZSB0aGF0IA0KICAgb3RoZXIgZ3JvdXBzIG1heSBhbHNvIGRpc3RyaWJ1dGUgd29y a2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtDQogICBEcmFmdHMuIA0KICAgIA0KICAgSW50ZXJu ZXQtRHJhZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXgg DQogICBtb250aHMgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5 IG90aGVyIGRvY3VtZW50cyANCiAgIGF0IGFueSB0aW1lLiAgSXQgaXMgaW5hcHByb3ByaWF0ZSB0 byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIA0KICAgcmVmZXJlbmNlIG1hdGVyaWFsIG9yIHRvIGNp dGUgdGhlbSBvdGhlciB0aGFuIGFzIGBgd29yayBpbiANCiAgIHByb2dyZXNzLicnIA0KICAgIA0K ICAgVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRlcm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0 IA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pZXRmLzFpZC1hYnN0cmFjdHMudHh0LiANCiAgICAN CiAgIFRoZSBsaXN0IG9mIEludGVybmV0LURyYWZ0IFNoYWRvdyBEaXJlY3RvcmllcyBjYW4gYmUg YWNjZXNzZWQgYXQgIA0KICAgaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbC4gDQogICAg DQogIENvcHlyaWdodCBOb3RpY2UgDQogICAgDQogICAgICBDb3B5cmlnaHQgKEMpIFRoZSBJbnRl cm5ldCBTb2NpZXR5ICgyMDA2KS4gDQogICAgDQogIENvbnZlbnRpb25zIHVzZWQgaW4gdGhpcyBk b2N1bWVudCAgDQogICAgDQogICBUaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJF UVVJUkVEIiwgIlNIQUxMIiwgIlNIQUxMIE5PVCIsICANCiAgICJTSE9VTEQiLCAiU0hPVUxEIE5P VCIsICJSRUNPTU1FTkRFRCIsICJNQVkiLCBhbmQgIk9QVElPTkFMIiBpbiAgDQogICB0aGlzIGRv Y3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBkZXNjcmliZWQgaW4gW1JGQy0yMTE5XS4g DQogICAgDQogIEFic3RyYWN0IA0KICAgIA0KICAgVGhpcyBkb2N1bWVudCBkZWZpbmVzIHRoZSBp bnRlcmZhY2UgcmVxdWlyZW1lbnRzIGJldHdlZW4gdGhlIA0KICAgY29tcG9uZW50cyBvZiB0aGUg TkVBIChOZXR3b3JrIEVuZHBvaW50IEFzc2Vzc21lbnQpIGNvbmNlcHR1YWwgDQogICBhcmNoaXRl Y3R1cmUuICBORUEgcHJvdmlkZXMgb3duZXJzIG9mIG5ldHdvcmtzIChlLmcuIGFuIGVudGVycHJp c2UgDQoNCg0KDQpLaG9zcmF2aSwgZXQuIGFsLiAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDIwMDYg ICAgICAgICAgICAgICAgW1BhZ2UgMV0NCg0KDQoNCkludGVybmV0IERyYWZ0ICAgICAgICAgICAg IE5FQSBSZXF1aXJlbWVudHMgICAgICAgICAgICAgICAgIE1heSAyMDA2IA0KICAgb2ZmZXJpbmcg cmVtb3RlIGFjY2VzcykgYSBtZWNoYW5pc20gdG8gbGVhcm4gdGhlIG9wZXJhdGlvbmFsIHN0YXRl IA0KICAgb3IgcG9zdHVyZSBvZiBhIHN5c3RlbSByZXF1ZXN0aW5nIG5ldHdvcmsgYWNjZXNzIGFu ZCB0aGVuIGFwcGx5IHRoaXMgDQogICBrbm93bGVkZ2UgdG8gdGhlIG5ldHdvcmsgYWRtaXNzaW9u IGRlY2lzaW9uLiAgSW4gdGhpcyBjYXNlLCANCiAgIG9wZXJhdGlvbmFsIHBvc3R1cmUgcmVmZXJz IHRvIGluZm9ybWF0aW9uIGFib3V0IHRoZSBjb25maWd1cmF0aW9uIA0KICAgYW5kIHVzZSBvZiBo YXJkd2FyZSBhbmQgc29mdHdhcmUgY2FwYWJpbGl0aWVzIGF2YWlsYWJsZSBvciBydW5uaW5nIA0K ICAgb24gdGhlIHN5c3RlbS4gIFRoaXMgaW5mb3JtYXRpb24gaXMgZnJlcXVlbnRseSB1c2VmdWwg Zm9yIGRldGVjdGluZyANCiAgIHN5c3RlbXMgdGhhdCBhcmUgbGFja2luZyAob3IgaGF2ZSBvdXQg b2YgZGF0ZSkgc2VjdXJpdHkgcHJvdGVjdGl2ZSANCiAgIG1lY2hhbmlzbXMgKGUuZy4gYW50aS12 aXJ1cywgZmlyZXdhbGwuKSANCiANCiAgIEluIG9yZGVyIHRvIHByb3ZpZGUgY29udGV4dCBmb3Ig dGhlIHJlcXVpcmVtZW50cywgYSBjb25jZXB0dWFsIA0KICAgYXJjaGl0ZWN0dXJlIGFuZCB0ZXJt aW5vbG9neSBpcyBpbnRyb2R1Y2VkLiAgVGhpcyBhcmNoaXRlY3R1cmUgaXMgDQogICBwcm92aWRl ZCBmb3IgaW5mb3JtYXRpb25hbCBwdXJwb3NlcyBidXQgaXMgYmFzZWQgb24gdGhlIG1vZGVscyB1 c2VkIA0KICAgYnkgTkFDWzldLCBOQVBbMTBdIGFuZCBUTkNbOF0uIA0KIA0KICBBdXRob3JzIA0K ICAgIA0KICAgVGhlIHBhcnRpY2lwYW50cyBpbiB0aGUgTkVBIFJlcXVpcmVtZW50cyBUZWFtIHdo byB3ZXJlIGluc3RydW1lbnRhbCANCiAgIGluIHRoZSBjcmVhdGlvbiBvZiB0aGlzIHJlcXVpcmVt ZW50cyBkcmFmdCBhcmU6ICANCiAgICANCiAgIEtldmluX0Ftb3JpbiwgRGlhbmEgQXJyb3lvLCBV cmkgQmx1bWVudGhhbCwgU3RldmUgSGFubmEsIFRob21hcyANCiAgIEhhcmRqb25vLCBIb3JtdXpk IEtob3NyYXZpLCBSYXZpIFNhaGl0YSwgTWF1cmljaW8gU2FuY2hleiwgUGF1bCANCiAgIFNhbmdz dGVyLCBKZWZmIFNpeCwgSm9zZXBoIFRhcmRvLCBTdXNhbiBUaG9tcHNvbiwgSm9obiBWb2xsYnJl Y2h0LCANCiAgIEhhbyBaaG91ICANCiANCiANCiAgIDEuIEludHJvZHVjdGlvbi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4yIA0KICAgMi4gRGVmaW5p dGlvbnMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u LjMgDQogICAzLiBBcmNoaXRlY3R1cmUgYW5kIENvbXBvbmVudHMuLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uNCANCiAgIDQuIENvbW1vbiBBcmNoaXRlY3R1cmFsIFJlcXVpcmVt ZW50cy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi40IA0KICAgNS4gSW50ZXJmYWNlIFJl cXVpcmVtZW50cy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjUgDQog NS4xLiBQb3N0dXJlIEF0dHJpYnV0ZSAoUEEpIGludGVyZmFjZSBSZXF1aXJlbWVudHMuLi4uLi4u Li4uLi4uLi4uLi4uNSANCiA1LjIuIFBvc3R1cmUgQnJva2VyIChQQikgSW50ZXJmYWNlIFJlcXVp cmVtZW50cy4uLi4uLi4uLi4uLi4uLi4uLi4uLi42IA0KIDUuMy4gUG9zdHVyZSBUcmFuc3BvcnQg KFBUKUludGVyZmFjZSBSZXF1aXJlbWVudHMuLi4uLi4uLi4uLi4uLi4uLi4uLjggDQogICA2LiBT ZWN1cml0eSBBbmFseXNpcy9SZXF1aXJlbWVudHMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uOSANCiAgIDcuIE9wZXJhdGlvbmFsIENvbnNpZGVyYXRpb25zLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLjEwIA0KICAgOC4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMu Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTEgDQogOC4xLiBTY29wZSBh bmQgT3ZlcmxhcC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4x MSANCiA4LjIuIEludGVyZXN0aW5nIEF0dGFjayBDbGFzc2VzLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLjEyIA0KICA4LjIuMS4gTWFuLWluLXRoZS1NaWRkbGUgKE1JVE0pLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTIgDQogIDguMi4yLiBNZXNzYWdlIE1v ZGlmaWNhdGlvbi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xMyANCiAg OC4yLjMuIE1lc3NhZ2UgUmVwbGF5IG9yIFRoZWZ0Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLjEzIA0KICAgOS4gUmVmZXJlbmNlcy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uMTQgDQogOS4xLiBOb3JtYXRpdmUgUmVmZXJlbmNl cy4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4xNCANCiA5LjIuIElu Zm9ybWF0aXZlIFJlZmVyZW5jZXMuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLjE0IA0KICAgQXV0aG9ycycgQWRkcmVzc2VzICYgQWNrbm93bGVkZ21lbnRzLi4uLi4uLi4u Li4uLi4uLi4uLi4uLi4uLi4uLi4uMTUNCiAgICANCiAxLkludHJvZHVjdGlvbiANCiAgICANCg0K DQoNCiAgDQpLaG9zcmF2aSwgZXQuIGFsLiAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDIwMDYgICAg ICAgICAgICAgICAgW1BhZ2UgMl0NCg0KDQoNCkludGVybmV0IERyYWZ0ICAgICAgICAgICAgIE5F QSBSZXF1aXJlbWVudHMgICAgICAgICAgICAgICAgIE1heSAyMDA2IA0KICAgVG9kYXksIG1vc3Qg bmV0d29yayBwcm92aWRlcnMgY2FuIGxldmVyYWdlIGV4aXN0aW5nIHN0YW5kYXJkcy1iYXNlZCAN CiAgIHRlY2hub2xvZ2llcyB0byByZXN0cmljdCBhY2Nlc3MgdG8gdGhlIG5ldHdvcmsgYmFzZWQg dXBvbiB0aGUgDQogICByZXF1ZXN0aW5nIHN5c3RlbSdzIHVzZXIgb3IgaG9zdC1iYXNlZCBpZGVu dGl0eSwgc291cmNlIElQIGFkZHJlc3MgDQogICBvciBwaHlzaWNhbCBhY2Nlc3MgcG9pbnQuICBI b3dldmVyIHRoZXNlIGFwcHJvYWNoZXMgc3RpbGwgbGVhdmUgdGhlIA0KICAgbmV0d29yayBwcm9u ZSB0byBtYWx3YXJlLWJhc2VkIGF0dGFjaywgd2hlbiBhbiBhdXRob3JpemVkIGJ1dCANCiAgIGlu ZmVjdGVkIHN5c3RlbSBpcyBhZG1pdHRlZCBhbmQgdGhlIG1hbHdhcmUgaXMgYWJsZSB0byBzcHJl YWQgDQogICB0aHJvdWdob3V0IHRoZSBpbnRlcm5hbCBuZXR3b3JrLiANCiAgICANCiAgIEFzIGEg cmVzdWx0LCBuZXR3b3JrIG9wZXJhdG9ycyBuZWVkIHRoZSBhYmlsaXR5IHRvIHByZWVtcHRpdmVs eSANCiAgIGRldGVjdCBzeXN0ZW1zIHRoYXQgYXJlIHByb25lIG9yIGFscmVhZHkgY29udGFpbiBt YWx3YXJlIHBvdGVudGlhbGx5IA0KICAgZGFuZ2Vyb3VzIHRvIHRoZSBuZXR3b3JrLiAgSWYgYSBz eXN0ZW0gaXMgZGV0ZXJtaW5lZCB0byBiZSBwcm9uZSB0byANCiAgIGF0dGFjayBieSBsYWNraW5n IHByb3BlciBkZWZlbnNpdmUgbWVjaGFuaXNtcyBzdWNoIGFzIHRoZSBhYnNlbmNlIG9mIA0KICAg dXAgdG8gZGF0ZSBmaXJld2FsbCBhbmQgYW50aS12aXJ1cyBzb2Z0d2FyZSwgdGhlcmUgc2hvdWxk IGJlIGEgd2F5IA0KICAgdG8gc2FmZWx5IHJlcGFpciAocmVtZWRpYXRlKSB0aGUgc3lzdGVtIHNv IHRoYXQgaXQgY2FuIGJlIA0KICAgc3Vic2VxdWVudGx5IHRydXN0ZWQgdG8gam9pbiBhbmQgb3Bl cmF0ZSBvbiB0aGUgbmV0d29yay4gDQogICAgDQogICBUaGUgTmV0d29yayBFbmRwb2ludCBBc3Nl c3NtZW50IChORUEpIHN5c3RlbSBpcyBhIGNvbXBsZW1lbnRhcnkgDQogICB0ZWNobm9sb2d5IHRv IGV4aXN0aW5nIGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRob3JpemF0aW9uIGFwcHJvYWNoZXMgDQog ICBhbGxvd2luZyB0aGUgbmV0d29yayB0byBoYXZlIHZpc2liaWxpdHkgaW50byB0aGUgY29udGVu dHMgb2YgdGhlIA0KICAgc3lzdGVtIChzZWN1cml0eSBwb3N0dXJlKSByZXF1ZXN0aW5nIGFjY2Vz cyBzbyB0aGF0IGl0cyByaXNrIHByb2ZpbGUgDQogICBjYW4gYmUgZmFjdG9yZWQgaW50byB0aGUg YWRtaXNzaW9uIGRlY2lzaW9uLiAgTkVBIHR5cGljYWxseSBpbnZvbHZlcyANCiAgIHRoZSB1c2Ug b2YgdHJ1c3RlZCBhZ2VudHMgcnVubmluZyBvbiB0aGUgcmVxdWVzdGluZyBtYWNoaW5lIHdoaWNo IA0KICAgb2JzZXJ2ZSBhbmQgcmVwb3J0IG9uIHRoZSBwb3N0dXJlIG9mIHRoZSBzeXN0ZW0gdG8g bmV0d29yayANCiAgIGluZnJhc3RydWN0dXJlLiAgVGhlIGluZnJhc3RydWN0dXJlIGhhcyBlcXVp dmFsZW50IGNvbXBvbmVudHMgd2hpY2ggDQogICBhcmUgY2FwYWJsZSBvZiBldmFsdWF0aW5nIHRo ZSBwb3N0dXJlIGluZm9ybWF0aW9uIGFuZCBmZWVkaW5nIHRoZSANCiAgIHJlc3VsdCB0byBhbiBh cHByb3ByaWF0ZSBuZXR3b3JrIGFkbWlzc2lvbiBkZWNpc2lvbiBtYWtlci4gIEZpbmFsbHkgDQog ICB0aGUgYWRtaXNzaW9uIGRlY2lzaW9uIGlzIHByb3Zpc2lvbmVkIHRvIHRoZSBlbmZvcmNlbWVu dCBtZWNoYW5pc21zIA0KICAgb24gdGhlIG5ldHdvcmsgYW5kL29yIHN5c3RlbSByZXF1ZXN0aW5n IGFjY2Vzcy4gIFRoZSBkZWNpc2lvbiBtaWdodCANCiAgIGFsbG93IGZvciBubyBhY2Nlc3MsIGxp bWl0ZWQgYWNjZXNzIChwb3NzaWJseSB0byBhbGxvdyBmb3IgDQogICByZW1lZGlhdGlvbiksIG9y IGZ1bGwgYWNjZXNzIHRvIHRoZSBuZXR3b3JrLiANCiAgICANCiAgIEFyY2hpdGVjdHVyZXMsIHNp bWlsYXIgdG8gTkVBLCBoYXZlIGJlZW4gZGVmaW5lZCBpbiB0aGUgaW5kdXN0cnkgDQogICAoZS5n LiBUTkMsIE5BUCwgTkFDKSB0byBhc3Nlc3MgdGhlIHNvZnR3YXJlIG9yIGhhcmR3YXJlIA0KICAg Y29uZmlndXJhdGlvbiBvZiBlbmRwb2ludCBkZXZpY2VzIGZvciB0aGUgcHVycG9zZXMgb2YgbW9u aXRvcmluZyBvciANCiAgIGVuZm9yY2luZyBjb21wbGlhbmNlIG9mIGVuZHBvaW50cyB0byBhbiBv cmdhbml6YXRpb24ncyBwb2xpY3kgb24gDQogICBhY2Nlc3MgdG8gdGhlIG5ldHdvcmsuIFRoZXNl IGFyY2hpdGVjdHVyZXMgYXJlIG5vdCBpbnRlcm9wZXJhYmxlIA0KICAgc2luY2UgbW9zdCBvZiB0 aGUgdGVjaG5vbG9naWVzIHVzZWQgdG8gaW1wbGVtZW50IHRoZSBhcmNoaXRlY3R1cmUgDQogICBh cmUgbm90IHN0YW5kYXJkcy4gDQogICAgDQogICBUaGUgTkVBIHdvcmtpbmcgZ3JvdXAgaXMgd29y a2luZyBvbiBkZWZpbmluZyBzdGFuZGFyZCBpbnRlcmZhY2UgDQogICBwcm90b2NvbHMgc28gYXMg dG8gZW5hYmxlIGludGVyb3BlcmFiaWxpdHkgYmV0d2VlbiBkZXZpY2VzIGZyb20gDQogICBkaWZm ZXJlbnQgdmVuZG9ycyBhbGxvd2luZyBuZXR3b3JrIG93bmVycyB0byBkZXBsb3kgdHJ1bHkgDQog ICBoZXRlcm9nZW5lb3VzIHNvbHV0aW9ucy4gVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIHJl cXVpcmVtZW50cyANCiAgIGZvciBORUEgY2FuZGlkYXRlIHRlY2hub2xvZ2llcyBhbmQgcHJvdG9j b2xzLiAgDQogDQogMi5EZWZpbml0aW9ucyANCiAgICANCiAgIFBsZWFzZSByZWZlciB0byBbM10g Zm9yIHRoZSBORUEgdGVybWlub2xvZ3kuICAgDQogDQoNCg0KICANCktob3NyYXZpLCBldC4gYWwu ICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMjAwNiAgICAgICAgICAgICAgICBbUGFnZSAzXQ0KDQoN Cg0KSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgTkVBIFJlcXVpcmVtZW50cyAgICAgICAgICAg ICAgICAgTWF5IDIwMDYgDQogMy5BcmNoaXRlY3R1cmUgYW5kIENvbXBvbmVudHMgDQogICAgDQog ICBUaGUgbWFqb3IgY29tcG9uZW50cyBvZiBORUEgYXJjaGl0ZWN0dXJlIGFyZSBhcyBmb2xsb3dz LiANCiAgICANCiAgICAgfC0tLS0tLS0tLS0tLS18ICAgICAgICAgICAgICAgICAgICAgICAgICB8 LS0tLS0tLS0tLS0tLS0tLXwgDQogICAgIHwgUG9zdHVyZSAgICAgfCAgPC0tLS0tLS0tUEEtLS0t LS0tLS0+ICAgfCAgIFBvc3R1cmUgICAgICB8IA0KICAgICB8IENvbGxlY3RvcnMgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgIHwgICBWYWxpZGF0b3JzICAgfCANCiAgICAgfCAoMSAuLi5OKSAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgKDEgLi4uTikgICAgIHwgDQogICAgIHwt LS0tLS0tLS0tLS0tfCAgICAgICAgICAgICAgICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS18 IA0KICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg fCANCiAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg UFYgDQogICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB8IA0KICAgICB8LS0tLS0tLS0tLS0tLXwgICAgICAgICAgICAgICAgICAgICAgICAgIHwtLS0t LS0tLS0tLS0tLS0tfCANCiAgICAgfCAgIENsaWVudCAgICB8ICA8LS0tLS0tLS1QQi0tLS0tLS0t LT4gICB8ICAgICBTZXJ2ZXIgICAgIHwgDQogICAgIHwgICBCcm9rZXIgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgfCAgICAgQnJva2VyICAgICB8IA0KICAgICB8LS0tLS0tLS0tIC0tLXwg ICAgICAgICAgICAgICAgICAgICAgICAgIHwtLS0tLS0tLS0tLS0tLS0tfCANCiAgICAgICAgICAg fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgDQogICAgICAgICAg IHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IA0KICAgICB8LS0t LS0tLS0tLS0tLXwgIDwtLS0tLS0tLVBULS0tLS0tLS0tPiAgIHwtLS0tLS0tLS0tLS0tLS0tfCAN CiAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgICAg ICAgICAgIHwgDQogICAgIHwgTmV0d29yayAgICAgfCAgICB8LS0tLS0tLS18ICAgICAgICAgICAg fCAgIE5ldHdvcmsgICAgICB8IA0KICAgICB8IEFjY2VzcyAgICAgIHwtLS0tfE5ldHdvcmsgfC0t LS0tLS0tLS0tLXwgICBBY2Nlc3MgICAgICAgfCANCiAgICAgfCBSZXF1ZXN0b3IgICB8ICAgIHxF bmZvcmNlcnwgPC0tLU5BRS0tPiB8ICAgQXV0aG9yaXR5ICAgIHwgDQogICAgIHwtLS0tLS0tLS0t LS0tfCAgICB8LS0tLS0tLS18ICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS18IA0KIA0KICAg ICAgIE5FQSBDTElFTlQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTkVBIFNFUlZF UiANCiANCiANCiAgICAgICAgICAgICAgRmlndXJlIDE6IE5FQSBDb21wb25lbnRzIGFuZCBJbnRl cmZhY2VzIA0KICAgIA0KIDQuQ29tbW9uIEFyY2hpdGVjdHVyYWwgUmVxdWlyZW1lbnRzIA0KICAg IA0KICAgVGhlIGZvbGxvd2luZyBhcmUgdGhlIGNvbW1vbiBhcmNoaXRlY3R1cmFsIHJlcXVpcmVt ZW50cyBhY3Jvc3MgYWxsIA0KICAgTkVBIGludGVyZmFjZXMvcHJvdG9jb2xzOiANCiAgICANCiAg IDEuIE5FQSBwcm90b2NvbHMgTVVTVCBiZSBjYXBhYmxlIG9mIHBlcmZvcm1pbmcgYSBtdWx0aS1y b3VuZCBwb3N0dXJlIA0KICAgZXhjaGFuZ2UgYmV0d2VlbiB0aGUgY2xpZW50IChhZ2VudCkgYW5k IHNlcnZlci4gIFRoaXMgZW5hYmxlcyB0aGUgDQogICBzZXJ2ZXIgdG8gcmVxdWVzdCBhZGRpdGlv bmFsIGluZm9ybWF0aW9uIG9yIHVwZGF0ZXMgdG8gdGhlIHBvc3R1cmUgDQogICBkYXRhIGFscmVh ZHkgcmVwb3J0ZWQuIFRoZSB1cGRhdGVzIGFsbG93IGZvciBkZXRlY3Rpb24gb2YgcmVjZW50IA0K ICAgY2hhbmdlcyBpbiB0aGUgY2xpZW50IHN0YXRlIChlLmcuIHBvc3NpYmx5IGR1ZSB0byBhIHJl bWVkaWF0aW9uLikgDQogICAgDQogICAyLiBORUEgcHJvdG9jb2xzIE1VU1QgYWxsb3cgdGhlIE5F QSBzZXJ2ZXIgdG8gaW5pdGlhdGUgcmVxdWVzdHMgZm9yIA0KICAgcG9zdHVyZSBpbmZvcm1hdGlv biBwcmlvciB0byBuZXR3b3JrIGFjY2VzcyBhbmQgYXQgYW55IHRpbWUgYWZ0ZXIgDQogICB0aGUg Y2xpZW50IGhhcyBlc3RhYmxpc2hlZCBhbiBpZGVudGl0eSBvbiB0aGUgbmV0d29yayAoZS5nLiBJ UCANCiAgIGFkZHJlc3MuKSAgVGhpcyBlbmFibGVzIHRoZSBORUEgc2VydmVyIHRvIGV2YWx1YXRl IHBvc3R1cmUgcHJpb3IgdG8gDQogICBhbGxvd2luZyBhY2Nlc3MgYW5kIHRvIHBlcmlvZGljYWxs eSByZS12YWxpZGF0ZSBzeXN0ZW1zIGFscmVhZHkgDQogICBhZG1pdHRlZCB0byB0aGUgbmV0d29y ayB0byBhc3N1cmUgdGhleSBhcmUgc3RpbGwgaW4gY29tcGxpYW5jZSB3aXRoIA0KICAgdGhlIGN1 cnJlbnQgcG9saWNpZXMuIA0KICAgIA0KICAgMy4gTkVBIHByb3RvY29scyBNVVNUIHByb3ZpZGUg YSB3YXkgZm9yIHRoZSBORUEgY2xpZW50IHRvIGluaXRpYXRlIGEgDQogICBwb3N0dXJlIHJlLWV2 YWx1YXRpb24gcmVxdWVzdCBhcyBuZWVkZWQuICBUaGlzIGFsbG93cyB0aGUgY2xpZW50IHRvIA0K DQoNCiAgDQpLaG9zcmF2aSwgZXQuIGFsLiAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDIwMDYgICAg ICAgICAgICAgICAgW1BhZ2UgNF0NCg0KDQoNCkludGVybmV0IERyYWZ0ICAgICAgICAgICAgIE5F QSBSZXF1aXJlbWVudHMgICAgICAgICAgICAgICAgIE1heSAyMDA2IA0KICAgcHJvYWN0aXZlbHkg cmVxdWVzdCBhIHBvc3R1cmUgcmUtZXZhbHVhdGlvbiBieSB0aGUgTkVBIFNlcnZlciBhZnRlciAN CiAgIGRldGVjdGlvbiBvZiBhIHBvdGVudGlhbGx5IHN1c3BpY2lvdXMgZXZlbnQuIA0KICAgICAN CiAgIDQuIE5FQSBwcm90b2NvbHMgTVVTVCBwcm92aWRlIHByb3RlY3Rpb24gYWdhaW5zdCBhY3Rp dmUgYW5kIHBhc3NpdmUgDQogICBhdHRhY2tzIGJ5IGludGVybWVkaWFyaWVzIChlLmcuIG1hbi1p bi10aGUtbWlkZGxlLikgIFN1Y2ggcHJvdGVjdGlvbiANCiAgIG1pZ2h0IGNvbWUgZnJvbSBhIHN0 cm9uZyAoZS5nLiBjcnlwdG9ncmFwaGljKSBiaW5kaW5nIGJldHdlZW4gdGhlIA0KICAgYXV0aGVu dGljYXRlZCBpZGVudGl0eSBvZiB0aGUgcmVxdWVzdGluZyBzeXN0ZW0gYW5kIHRoZSByZXBvcnRl ZCANCiAgIHBvc3R1cmUgaW5mb3JtYXRpb24uICBUaGlzIHByb3RlY3Rpb24gTVVTVCBwcmV2ZW50 IHJlcGxheSBiYXNlZCANCiAgIGF0dGFja3MgKHByZXZlbnRpbmcgYSBtYWxpY2lvdXMgbWFjaGlu ZSBmcm9tIGxhdGVyIHJlcGxheWluZyBhIA0KICAgaGVhbHRoeSBwb3N0dXJlIHJlcG9ydC4pIA0K ICAgIA0KICAgNS4gVGhlIFBBLCBQQiAmIFBWIGludGVyZmFjZXMgZGVmaW5lZCBieSBORUEgTVVT VCBiZSBhZ25vc3RpYyBvZiB0aGUgDQogICB0cmFuc3BvcnQgaS5lLiBQVCBpbnRlcmZhY2UuIEZv ciBleGFtcGxlLCB0aGUgUEIgcHJvdG9jb2wgbXVzdCANCiAgIHByb3ZpZGUgYSB0cmFuc3BvcnQg KFBUKSBpbmRlcGVuZGVudCBpbnRlcmZhY2UgYWxsb3dpbmcgdGhlIFBBIA0KICAgcHJvdG9jb2wg dG8gb3BlcmF0ZSB3aXRob3V0IGNoYW5nZSBhY3Jvc3MgYSB2YXJpZXR5IG9mIG5ldHdvcmsgDQog ICBwcm90b2NvbCBlbnZpcm9ubWVudHMgKGUuZy4gRUFQLzgwMi4xWCwgUEFOQSwgYW5kIElLRS9J UHNlYy4pICANCiAgICANCiAgIDYuIE5FQSBwcm90b2NvbHMgTVVTVCByZXVzZSBleGlzdGluZyBv cGVuIHN0YW5kYXJkcyBmb3IgaXRzIA0KICAgaW50ZXJmYWNlcyBiZWZvcmUgZGVmaW5pbmcgbmV3 IG9uZXMuIA0KICAgIA0KICAgNy4gTkVBIHByb3RvY29scyBNVVNUIGJlIGhpZ2hseSBzY2FsYWJs ZSBpbiB0ZXJtcyBvZiBhZGRpbmcgbXVsdGlwbGUgDQogICBzZXJ2ZXJzLCBjbGllbnRzLCBQb3N0 dXJlIENvbGxlY3RvcnMsIFBvc3R1cmUgVmFsaWRhdG9ycywgZXRjLiAgDQogICAgDQogICAgDQog NS5JbnRlcmZhY2UgUmVxdWlyZW1lbnRzIA0KICAgIA0KNS4xLlBvc3R1cmUgQXR0cmlidXRlIChQ QSkgaW50ZXJmYWNlIFJlcXVpcmVtZW50cyANCiAgICANCiAgIFRoZSBQQSBwcm90b2NvbCBkZWZp bmVzIHRoZSBjb250cm9sIGFuZCBkYXRhIG1vZGVsIHRvIGNhcnJ5IHBvc3R1cmUgDQogICBhbmQg dmFsaWRhdGlvbiBpbmZvcm1hdGlvbiBiZXR3ZWVuIGEgcGFydGljdWxhciBQb3N0dXJlIENvbGxl Y3RvciANCiAgIGFzc29jaWF0ZWQgd2l0aCBhIE5FQSBjbGllbnQgYW5kIGEgUG9zdHVyZSBWYWxp ZGF0b3IgYXNzb2NpYXRlZCB3aXRoIA0KICAgYSBORUEgU2VydmVyLiBUaGUgUG9zdHVyZSBBdHRy aWJ1dGUgcHJvdG9jb2wgY29uc2lzdHMgb2YgY29yZSANCiAgIGF0dHJpYnV0ZXMgYW5kIHZlbmRv ciBkZWZpbmVkIGF0dHJpYnV0ZXMuIFRoZSBQQSBwcm90b2NvbCB3aWxsIGJlIA0KICAgY2Fycmll ZCBpbnNpZGUgdGhlIFBvc3R1cmUgQnJva2VyIChQQikgcHJvdG9jb2wuIA0KICAgIA0KICAgMS4g VGhlIFBBIHByb3RvY29sIE1VU1Qgc3VwcG9ydCB0cmFuc3BvcnQgb2YgdGhlIHJlcXVpcmVkIChj b3JlKSANCiAgIGF0dHJpYnV0ZXMgZGVmaW5lZCBpbiB0aGUgZGF0YSBtb2RlbCB0byByZXBvcnQg aW5mb3JtYXRpb24gcmVjZWl2ZWQgDQogICBieSBhIFBvc3R1cmUgQ29sbGVjdG9yLiBFeGFtcGxl cyBvZiBjb3JlIGF0dHJpYnV0ZXMgaW5jbHVkZSBWZW5kb3IgDQogICBpZCwgQXBwbGljYXRpb24g dmVyc2lvbiwgYW5kIE9wZXJhdGlvbmFsIHN0YXR1cy4gDQogICAgDQogICAyLiBUaGUgUEEgcHJv dG9jb2wgTVVTVCBzdXBwb3J0IHRoZSB0cmFuc3BvcnQgb2YgdmVuZG9yIGRlZmluZWQgDQogICBh dHRyaWJ1dGVzLiANCiAgICANCiAgIDMuIFRoZSBQQSBwcm90b2NvbCBNVVNUIHN1cHBvcnQgdGhl IHRyYW5zcG9ydCBvZiBjb3JlIChyZXF1aXJlZCkgDQogICBhdHRyaWJ1dGVzIGJldHdlZW4gYSBQ b3N0dXJlIENvbGxlY3RvciBhbmQgYSBQb3N0dXJlIFZhbGlkYXRvci4gDQogICBFeGFtcGxlIG9m IHN1Y2ggY29udHJvbCBtZXNzYWdlcyBhcmUgdGltZXN0YW1wLCB0cmFuc2FjdGlvbiBpZCwgDQog ICByZXNldCwgKHJlKXN0YXJ0IGV2YWx1YXRpb24sIHZhbGlkYXRpb24gcmVzdWx0cyBhbmQgKHJl KXN0YXJ0IA0KICAgcmVtZWRpYXRpb24uIA0KICAgIA0KDQoNCiAgDQpLaG9zcmF2aSwgZXQuIGFs LiAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDIwMDYgICAgICAgICAgICAgICAgW1BhZ2UgNV0NCg0K DQoNCkludGVybmV0IERyYWZ0ICAgICAgICAgICAgIE5FQSBSZXF1aXJlbWVudHMgICAgICAgICAg ICAgICAgIE1heSAyMDA2IA0KICAgNC4gVGhlIFBBIHByb3RvY29sIE1BWSBzdXBwb3J0IGNvbnRy b2wgYXR0cmlidXRlcyB0aGF0IGdyb3VwIHN1YiANCiAgIGF0dHJpYnV0ZXMgZm9yIGEgY29sbGVj dG9yLCBmb3IgZXhhbXBsZSwgYXR0cmlidXRlcyB0aGF0IHJlcG9ydCANCiAgIGhlYWx0aCBvZiBh bGwgc3ViLWNvbXBvbmVudHMgaW5jbHVkaW5nIHZlbmRvciwgYXBwbGljYXRpb24sIHZlcnNpb24s IA0KICAgYW5kIG9wZXJhdGlvbmFsIHN0YXR1cy4gDQogICAgDQogICA1LiBUaGUgUEEgcHJvdG9j b2wgTVVTVCB1c2Ugb3BlbiBzdGFuZGFyZHMgYXMgZmFyIGFzIHBvc3NpYmxlIGZvciANCiAgIGV4 YW1wbGUsIHN0cnVjdHVyZWQgZm9ybWF0cyBzdWNoIGFzIFhNTC4gDQogICAgDQogICA2LiBUaGUg UEEgcHJvdG9jb2wgU0hPVUxEIHN1cHBvcnQgZXhwcmVzc2lvbiBvZiBjb3JlIGF0dHJpYnV0ZXMg dG8gDQogICBkZXNjcmliZSByZW1lZGlhdGlvbiBzdGF0ZSBvZiBjb21wb25lbnRzIGZvciBleGFt cGxlLCBsYXN0IHVwZGF0ZSANCiAgIHRpbWUsIHJlbWVkaWF0aW9uIHNlcnZlciB1c2VkLiBUaGVz ZSBhdHRyaWJ1dGVzIGFyZSB1c2VkIGFmdGVyIA0KICAgcmVtZWRpYXRpb24gc28gdGhhdCBhIFBv c3R1cmUgVmFsaWRhdG9yIGNhbiBzeW5jaHJvbml6ZSB3aXRoIGEgDQogICBQb3N0dXJlIENvbGxl Y3RvciBhbmQgY29udGludWUgcmVtZWRpYXRpb24uIA0KICAgIA0KICAgNy4gVGhlIFBBIHByb3Rv Y29sIFNIT1VMRCBzdXBwb3J0IHJldHVybmluZyB2YWxpZGF0aW9uIGFuZCANCiAgIHJlbWVkaWF0 aW9uIHBhcmFtZXRlcnMgZnJvbSBhIFBvc3R1cmUgVmFsaWRhdG9yIHRvIGEgUG9zdHVyZSANCiAg IENvbGxlY3RvciwgZm9yIGV4YW1wbGUsIHJlbWVkaWF0aW9uIHNlcnZlciBVUkwuICANCiAgICAN CiAgIDguIFRoZSBQQSBwcm90b2NvbCBNVVNUIHN1cHBvcnQgYXV0aGVudGljYXRpb24sIGludGVn cml0eSBhbmQgDQogICBjb25maWRlbnRpYWxpdHkgb2YgYXR0cmlidXRlcyBzZW50IGJldHdlZW4g YSBQb3N0dXJlIENvbGxlY3RvciBhbmQgDQogICBWYWxpZGF0b3IuIERlcGxveWVycyBvZiBQb3N0 dXJlIENvbGxlY3RvcnMgYW5kIFBvc3R1cmUgVmFsaWRhdG9ycyANCiAgIHNob3VsZCB1c2UgYXQg bGVhc3QgYXV0aGVudGljYXRpb24gYW5kIGludGVncml0eSBwcm90ZWN0aW9uIGZvciANCiAgIHRo ZWlyIG1lc3NhZ2VzLCBhbmQgbWF5IGFsc28gZW1wbG95IGNvbmZpZGVudGlhbGl0eSBwcm90ZWN0 aW9uIGlmIA0KICAgbmVjZXNzYXJ5IGZvciB0aGVpciBlbnZpcm9ubWVudC4gDQogICAgDQogICA5 LiBUaGUgUEEgcHJvdG9jb2wgU0hPVUxEIG9wdGltaXplIHRyYW5zcG9ydCBvZiBtZXNzYWdlcyBh bmQgDQogICBtaW5pbWl6ZSBQb3N0dXJlIEJyb2tlciBwcm90b2NvbCByb3VuZCB0cmlwcy4gVG8g YWNoaWV2ZSB0aGlzLCB0aGUgDQogICBQQSBwcm90b2NvbCBzaG91bGQgc3VwcG9ydCBjb25maWd1 cmF0aW9uL25lZ290aWF0aW9uIG9mIHRoZSBtYXhpbXVtIA0KICAgc2l6ZSBhbmQgdGltZW91dCBw ZXJpb2QgZm9yIGludGVyYWN0aW9uIG9mIGEgUG9zdHVyZSBDb2xsZWN0b3Igd2l0aCANCiAgIGEg UG9zdHVyZSBWYWxpZGF0b3IuIA0KICAgIA0KICAgICANCjUuMi5Qb3N0dXJlIEJyb2tlciAoUEIp IEludGVyZmFjZSBSZXF1aXJlbWVudHMgDQogICAgDQogICBUaGUgUEIgcHJvdG9jb2wgc3VwcG9y dHMgbXVsdGlwbGV4aW5nIG9mIFBvc3R1cmUgQXR0cmlidXRlcyAoYmFzZWQgDQogICBvbiBQQSBw cm90b2NvbCkgZnJvbSBtdWx0aXBsZSBQb3N0dXJlIENvbGxlY3RvcnMgYXNzb2NpYXRlZCB3aXRo IGEgDQogICBORUEgY2xpZW50IGFuZCBkZS1tdWx0aXBsZXhpbmcgdGhlc2UgbWVzc2FnZXMgdG8g bXVsdGlwbGUgUG9zdHVyZSANCiAgIFZhbGlkYXRvcnMgYXNzb2NpYXRlZCB3aXRoIGEgTkVBIHNl cnZlci4gVGhlIFBCIHByb3RvY29sIHN1cHBvcnRzIA0KICAgbXVsdGlwbGV4aW5nIG9mIHBvc3R1 cmUgYXNzZXNzbWVudCByZXN1bHRzIGZyb20gbXVsdGlwbGUgUG9zdHVyZSANCiAgIFZhbGlkYXRv cnMgYXNzb2NpYXRlZCB3aXRoIGEgTkVBIHNlcnZlciBhbmQgZGUtbXVsdGlwbGV4aW5nIHJlc3Vs dHMgDQogICB0byBtdWx0aXBsZSBQb3N0dXJlIENvbGxlY3RvcnMgYXNzb2NpYXRlZCB3aXRoIGEg TkVBIGNsaWVudC4gVGhlIFBCIA0KICAgcHJvdG9jb2wgYWxzbyBhZ2dyZWdhdGVzIHJlbWVkaWF0 aW9uIGF0dHJpYnV0ZXMgZnJvbSBvbmUgb3IgbW9yZSANCiAgIFBvc3R1cmUgVmFsaWRhdG9ycy4g DQogICAgDQogICAxLiBUaGUgUEIgcHJvdG9jb2wgU0hPVUxEIGFsbG93IGNhcnJ5aW5nIGRlY2lz aW9ucyBpZGVudGlmaWVkIGFzIA0KICAgZ2xvYmFsIGRlY2lzaW9ucyBmcm9tIHRoZSBORUEgc2Vy dmVyIGFsb25nIHdpdGggUG9zdHVyZSBWYWxpZGF0b3IgDQogICBzcGVjaWZpYyBpbmZvcm1hdGlv biByZXBvcnRlZCBieSBtdWx0aXBsZSBQb3N0dXJlIFZhbGlkYXRvcnMuIA0KICAgIA0KDQoNCg0K DQogIA0KS2hvc3JhdmksIGV0LiBhbC4gICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMDA2ICAgICAg ICAgICAgICAgIFtQYWdlIDZdDQoNCg0KDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICBORUEg UmVxdWlyZW1lbnRzICAgICAgICAgICAgICAgICBNYXkgMjAwNiANCiAgIDIuIFRoZSBQQiBwcm90 b2NvbCBNVVNUIGNvbnRhaW4gaW5mb3JtYXRpb24gdXNlZCBieSB0aGUgQnJva2VycyB0byANCiAg IHJvdXRlIG1lc3NhZ2VzIGJldHdlZW4gcGFydGljdWxhciB0eXBlcyBvZiBQb3N0dXJlIENvbGxl Y3RvcnMgYW5kIA0KICAgUG9zdHVyZSBWYWxpZGF0b3JzLiBTdWNoIG1lc3NhZ2Ugcm91dGluZyBp bmZvcm1hdGlvbiBzaG91bGQgc3VwcG9ydCANCiAgIGR5bmFtaWMgKGRlKXJlZ2lzdHJhdGlvbiBv ZiBQb3N0dXJlIENvbGxlY3RvcnMgYW5kIFZhbGlkYXRvcnMgDQogICByZWNlaXZlIGFwcHJvcHJp YXRlIG1lc3NhZ2VzLiAgRm9yIGV4YW1wbGUsIGEgZHluYW1pY2FsbHkgcmVnaXN0ZXJlZCANCiAg IEFudGktVmlydXMgUG9zdHVyZSBWYWxpZGF0b3Igc2hvdWxkIGJlIGFibGUgc3Vic2NyaWJlIHRv IHJlY2VpdmUgDQogICBtZXNzYWdlcyBmcm9tIGl0cyBwZWVyIEFudGktVmlydXMgUG9zdHVyZSBD b2xsZWN0b3IuIA0KICAgIA0KICAgMy4gVGhlIFBCIHByb3RvY29sIE1VU1Qgc3VwcG9ydCBzdWJz Y3JpcHRpb24gbWVzc2FnZXMgb24gdGhlIE5FQSANCiAgIHNlcnZlciBzbyB0aGF0IFBvc3R1cmUg VmFsaWRhdG9ycyBjYW4gcmVjZWl2ZSBhc3luY2hyb25vdXMgDQogICBpbmZvcm1hdGlvbiBmcm9t IFBvc3R1cmUgQ29sbGVjdG9ycywgZm9yIGV4YW1wbGUsIGV2ZW50cyBvciBwb3N0dXJlIA0KICAg YXR0cmlidXRlcy4gDQogICAgDQogICA0LiBUaGUgUEIgcHJvdG9jb2wgTVVTVCBzdXBwb3J0IHN1 YnNjcmlwdGlvbiBtZXNzYWdlcyBvbiB0aGUgTkVBIA0KICAgY2xpZW50IHNvIHRoYXQgUG9zdHVy ZSBDb2xsZWN0b3JzIGNhbiByZWNlaXZlIGFzeW5jaHJvbm91cyANCiAgIGluZm9ybWF0aW9uIGZy b20gUG9zdHVyZSBWYWxpZGF0b3JzLCBmb3IgZXhhbXBsZSwgdmFsaWRhdGlvbiANCiAgIHJlcG9y dHMuIA0KICAgIA0KICAgNS4gVGhlIFBCIHByb3RvY29sIE1VU1Qgc3VwcG9ydCBtdWx0aXBsZSBy b3VuZHMgb2YgcG9zdHVyZSANCiAgIGNvbGxlY3Rpb24gd2l0aGluIGEgdHJhbnNhY3Rpb24gYmV0 d2VlbiBhIFBvc3R1cmUgQ29sbGVjdG9yIGFuZCBhIA0KICAgUG9zdHVyZSBWYWxpZGF0b3IuIA0K ICAgIA0KICAgNi4gVGhlIFBCIHByb3RvY29sIE1VU1Qgc3VwcG9ydCBhc3luY2hyb25vdXMgcHVs bCBvZiBwb3N0dXJlIA0KICAgaW5mb3JtYXRpb24gZnJvbSBQb3N0dXJlIENvbGxlY3RvcnMgb24g YW4gZXZlbnQgZnJvbSBhIFBvc3R1cmUgDQogICBWYWxpZGF0b3JzIG9yIGEgTkVBIHNlcnZlci4g VGhlIE5FQSBzZXJ2ZXIgbWF5IG92ZXJyaWRlIHRoZSBwdWxsIA0KICAgcmVxdWVzdCBvZiBhIFBv c3R1cmUgVmFsaWRhdG9yLiANCiAgICANCiAgIDcuIFRoZSBQQiBwcm90b2NvbCBNVVNUIHN1cHBv cnQgcmFua2luZy9wcmlvcml0eSBvcmRlcmluZyBvZiBQb3N0dXJlIA0KICAgQ29sbGVjdG9yIHJl cG9ydHMgYW5kIFBvc3R1cmUgVmFsaWRhdG9yIHJlcG9ydHMgdG8gcmVzb2x2ZSBjb25mbGljdHMg DQogICBvciBkZXBlbmRlbmN5IGlzc3VlcyBhdCB0aGUgTkVBIGNsaWVudCBhbmQvb3IgTkVBIHNl cnZlci4gDQogICAgDQogICA4LiBUaGUgUEIgcHJvdG9jb2wgTVVTVCBzdXBwb3J0IHJlcG9ydGlu ZyBvZiBlcnJvciBjb2RlcyBhbmQgc3ViLQ0KICAgY29kZXMgYmFjayB0byB0aGUgTkVBIGNsaWVu dCwgZm9yIGV4YW1wbGUsIHRvIGF2b2lkIG11bHRpcGxleGluZyANCiAgIGF0dHJpYnV0ZXMgZm9y IGEgbWlzYmVoYXZpbmcgUG9zdHVyZSBDb2xsZWN0b3Igb3IgdG8gcmVwZWF0IHRoZSANCiAgIGF0 dHJpYnV0ZXMgZm9yIGEgc3BlY2lmaWMgUG9zdHVyZSBDb2xsZWN0b3Igb25seS4gIA0KICAgIA0K ICAgOS4gVGhlIFBCIHByb3RvY29sIE1VU1Qgc3VwcG9ydCBhdXRoZW50aWNhdGlvbiwgaW50ZWdy aXR5IGFuZCANCiAgIGNvbmZpZGVudGlhbGl0eSBvZiBtdWx0aXBsZXhlZCBQb3N0dXJlIGF0dHJp YnV0ZXMgYW5kIFZhbGlkYXRpb24gDQogICBhdHRyaWJ1dGVzLiBJbXBsZW1lbnRlcnMgb2YgUG9z dHVyZSBCcm9rZXJzIHNob3VsZCB1c2UgDQogICBhdXRoZW50aWNhdGlvbiBhbmQgaW50ZWdyaXR5 IG9mIG1lc3NhZ2VzLCBhbmQgbWF5IHN1cHBvcnQgDQogICBjb25maWRlbnRpYWxpdHkgb2YgbWVz c2FnZXMuIA0KICAgIA0KICAgMTAuIFRoZSBQQiBwcm90b2NvbCBTSE9VTEQgc3VwcG9ydCBncm91 cGluZyBvZiBhdHRyaWJ1dGVzIHRvIA0KICAgb3B0aW1pemUgdHJhbnNwb3J0IG9mIG1lc3NhZ2Vz IGFuZCBtaW5pbWl6ZSByb3VuZCB0cmlwcy4gVGhlIFBCIA0KICAgcHJvdG9jb2wgc2hvdWxkIHN1 cHBvcnQgY29uZmlndXJhdGlvbi9uZWdvdGlhdGlvbiBvZiB0aGUgbWF4aW11bSANCiAgIHNpemUg YW5kIHRpbWVvdXQgcGVyaW9kIGZvciBpbnRlcmFjdGlvbiBiZXR3ZWVuIGEgTkVBIHNlcnZlciBh bmQgDQogICBjbGllbnQuIA0KICAgIA0KICAgICANCg0KDQoNCiAgDQpLaG9zcmF2aSwgZXQuIGFs LiAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDIwMDYgICAgICAgICAgICAgICAgW1BhZ2UgN10NCg0K DQoNCkludGVybmV0IERyYWZ0ICAgICAgICAgICAgIE5FQSBSZXF1aXJlbWVudHMgICAgICAgICAg ICAgICAgIE1heSAyMDA2IA0KNS4zLlBvc3R1cmUgVHJhbnNwb3J0IChQVCkgSW50ZXJmYWNlIFJl cXVpcmVtZW50cyANCiAgICANCiAgIFRoZSBQVCBpcyB0aGUgdHJhbnNwb3J0IHByb3RvY29sIGJl dHdlZW4gdGhlIE5ldHdvcmsgQWNjZXNzIA0KICAgUmVxdWVzdG9yIChOQVIpIGluIHRoZSBORUEg Q2xpZW50IGFuZCB0aGUgTmV0d29yayBBY2Nlc3MgQXV0aG9yaXR5IA0KICAgKE5BQSkgd2l0aGlu IHRoZSBORUEgU2VydmVyIHByZXNlbnQgb24gdGhlIG5ldHdvcmsgb3duZXKScyANCiAgIGluZnJh c3RydWN0dXJlLiAgUFQgaXMgcmVzcG9uc2libGUgZm9yIHByb3ZpZGluZyBhIHByb3RlY3RlZCAN CiAgIHRyYW5zcG9ydCAoZnJlcXVlbnRseSB1c2luZyBhIHR1bm5lbCkgZm9yIHRoZSBQQiBwcm90 b2NvbC4gVGhlIFBUIA0KICAgcHJvdG9jb2wgbWF5IGluIHR1cm4gYmUgdHJhbnNwb3J0ZWQgYnkg YSBsb3dlciBsYXllciBwcm90b2NvbCBzdWNoIA0KICAgYXM6IDgwMi4xeCwgUkFESVVTLCBUTFMs IElLRS9JUHNlYyBvciBUQ1AsVURQL0lQLiAgVGhpcyBzZWN0aW9uIA0KICAgZGVmaW5lcyB0aGUg cmVxdWlyZW1lbnRzIHdoaWNoIGNhbmRpZGF0ZSBQVCBwcm90b2NvbHMgbXVzdCBiZSANCiAgIGNh cGFibGUgb2Ygc3VwcG9ydGluZy4gIFRoZSBkZXBsb3llcpJzIHBvbGljeSB3aWxsIGRpY3RhdGUg aG93IHRoZXNlIA0KICAgYXBwbHkgdG8gYSBwYXJ0aWN1bGFyIGVudmlyb25tZW50LiANCiAgICAN CiAgIDEuIFRoZSBQVCBwcm90b2NvbCBTSE9VTEQgdXNlIGV4aXN0aW5nIHN0YW5kYXJkIGJhc2Vk IHByb3RvY29scyANCiAgIHdoZW5ldmVyIHBvc3NpYmxlLiAgSWYgbm8gc3RhbmRhcmQgZXhpc3Rz IHRvIHN1cHBvcnQgdGhlIHRhcmdldCB1c2UgDQogICBjYXNlcywgTkVBIFdHIHdpbGwgcmVxdWVz dCBhcHByb3ByaWF0ZSBzdGFuZGFyZHMgZ3JvdXBzIGRldmVsb3AgDQogICBuZWNlc3Nhcnkgc3Rh bmRhcmQgcHJvdG9jb2xzLiANCiAgICANCiAgIDIuIFRoZSBQVCBwcm90b2NvbCBTSE9VTEQgaW5j dXIgbG93IG92ZXJoZWFkIHRvIGFjY29tbW9kYXRlIGZvciB1c2UgDQogICBvbiBsb3cgYmFuZHdp ZHRoIGxpbmtzLiANCiAgICANCiAgIDMuIFRoZSBQVCBwcm90b2NvbCBTSE9VTEQgYmUgY2FwYWJs ZSBvZiBzdXBwb3J0aW5nIGEgaGFsZiBkdXBsZXggDQogICBjb21tdW5pY2F0aW9uIGVudmlyb25t ZW50LiANCiAgICANCiAgIDQuIFRoZSBQVCBwcm90b2NvbCBNVVNUIE5PVCBhdHRlbXB0IHRvIGlu dGVycHJldCB0aGUgY29udGVudHMgb2YgdGhlIA0KICAgUEIgbWVzc2FnZXMgYmVpbmcgdHJhbnNw b3J0ZWQsIGkuZS4gdGhlIGRhdGEgaXQgaXMgY2FycnlpbmcgbXVzdCBiZSANCiAgIG9wYXF1ZSB0 byBpdC4gDQogICAgDQogICA1LiBUaGUgUFQgcHJvdG9jb2wgTVVTVCBiZSBjYXBhYmxlIG9mIHBy b3RlY3RpbmcgdGhlIGludGVncml0eSBhbmQgDQogICBjb25maWRlbnRpYWxpdHkgb2YgdGhlIFBC IG1lc3NhZ2VzIGJlaW5nIHRyYW5zcG9ydGVkIGJldHdlZW4gdGhlIE5BUiANCiAgIGFuZCBOQUEu IA0KICAgICAgDQogICA2LiBUaGUgUFQgcHJvdG9jb2wgTVVTVCBwcm92aWRlIHJlbGlhYmxlIGRl bGl2ZXJ5IG9mIFBCIG1lc3NhZ2VzLiAgDQogICBUaGlzIGluY2x1ZGVzIHRoZSBhYmlsaXR5IHRv IHBlcmZvcm0gZnJhZ21lbnRhdGlvbiwgZGV0ZWN0IA0KICAgZHVwbGljYXRlcywgYW5kIHJlb3Jk ZXIgZGF0YSwgaWYgbmVjZXNzYXJ5LiAgICANCiAgICANCiAgIDcuIFRoZSBQVCBwcm90b2NvbCBN VVNUIGJlIGNhcGFibGUgb2Ygc3VwcG9ydGluZyBtdXR1YWwgDQogICBhdXRoZW50aWNhdGlvbiBv ZiB0aGUgY29tbXVuaWNhdGluZyBwYXJ0aWVzLiAgVGhpcyBNQVkgb2NjdXIgYnkgDQogICBpbml0 aWFsbHkgYXV0aGVudGljYXRpbmcgdGhlIE5FQSBTZXJ2ZXIgYW5kIGxldmVyYWdpbmcgYnlwcm9k dWN0cyANCiAgIChlLmcuIGtleXMpIGFzc29jaWF0ZWQgd2l0aCB0aGlzIGF1dGhlbnRpY2F0aW9u IHRvIGNvbnN0cnVjdCBhIA0KICAgY29uZmlkZW50aWFsIGNoYW5uZWwgd2hlcmUgdGhlIE5FQSBD bGllbnQgY2FuIGF1dGhlbnRpY2F0ZS4gICANCiAgICANCiAgIDguIFRoZSBQVCBwcm90b2NvbCBN VVNUIGJlIGFibGUgdG8gZXN0YWJsaXNoIGEgcmVzdHJpY3RlZCBzZXNzaW9uIA0KICAgYmV0d2Vl biB0aGUgTkFSIGFuZCB0aGUgTkFBIHByaW9yIHRvIHRoZSBOQVIgZ3JhbnRpbmcgZ2VuZXJhbCAN CiAgIG5ldHdvcmsgYWNjZXNzLiANCiAgICANCiAgIDkuIFRoZSBQVCBwcm90b2NvbCBNVVNUIGFs bG93IHRoZSBOQVIgb3IgTkFBIHRvIGluaXRpYXRlIHRoZSANCiAgIGVzdGFibGlzaG1lbnQgb2Yg YSByZXN0cmljdGVkIHNlc3Npb24gZm9yIHVzZSBieSBORUEgd2hlbiBib3RoIA0KICAgcGFydGll cyBoYXZlIG5lY2Vzc2FyeSBuZXR3b3JrIGFkZHJlc3NlcyBlc3RhYmxpc2hlZC4gDQoNCg0KDQog IA0KS2hvc3JhdmksIGV0LiBhbC4gICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMDA2ICAgICAgICAg ICAgICAgIFtQYWdlIDhdDQoNCg0KDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICBORUEgUmVx dWlyZW1lbnRzICAgICAgICAgICAgICAgICBNYXkgMjAwNiANCiAgICANCiA2LlNlY3VyaXR5IEFu YWx5c2lzL1JlcXVpcmVtZW50cyANCiAgIFRoZXJlIGFyZSBzZXZlcmFsIGVudGl0aWVzIHRoYXQg Y29tcHJpc2UgdGhlIGRlc2NyaWJlZCBORUEgDQogICBjb25jZXB0dWFsIGFyY2hpdGVjdHVyZS4g RnJvbSBzZWN1cml0eSB2aWV3cG9pbnQsIHRoZWlyIHJlbGF0aW9ucyANCiAgIGFuZCBjb21tdW5p Y2F0aW9ucyBzaG91bGQgYWRoZXJlIHRvIHRoZSBmb2xsb3dpbmcgcmVxdWlyZW1lbnRzLiANCiAg ICANCiAgIEVuZC1wb2ludHMgbXVzdCBiZSBhYmxlIHRvIGF1dGhlbnRpY2F0ZSB0aGVpciBwZWVy cyAoaS5lLiBQb3N0dXJlIA0KICAgQ29sbGVjdG9yIGFuZCBQb3N0dXJlIFZhbGlkYXRvciksIGZv ciB3aXRob3V0IHRoYXQgbm8gbWVhbmluZ2Z1bCANCiAgIHBvc3R1cmUgaW5mb3JtYXRpb24gZXhj aGFuZ2UgaXMgcG9zc2libGUuIA0KICAgIA0KICAgMS4gUEEgaW50ZXJmYWNlIA0KICAgICAgIC0g UG9zdHVyZSBWYWxpZGF0b3IgTVVTVCBiZSBhYmxlIHRvIGFzY2VydGFpbiB0aGF0IHRoZSB0cmFm ZmljIA0KICAgKHBvc3R1cmUpIGl0IHJlY2VpdmVkIGlzICJmcmVzaCIuIFRoaXMgZnJlc2huZXNz IHByZXZlbnRzIGEgdGhpcmQgDQogICBwYXJ0eSBmcm9tIHJlcGxheWluZyB0aGUgcG9zdHVyZSBp bmZvcm1hdGlvbiBwcm9kdWNlZCBieSBhbiBlYXJsaWVyIA0KICAgUG9zdHVyZSBDb2xsZWN0b3Ig dXNlIHdpdGhvdXQgZGV0ZWN0aW9uLiANCiAgICAgICAtIEl0IG1heSBiZSBuZWNlc3NhcnkgKGVz cGVjaWFsbHkgaW4gY2FzZSBvZiBtdWx0aXBsZSBleGNoYW5nZXMgDQogICBiZXR3ZWVuIFBvc3R1 cmUgQ29sbGVjdG9yIGFuZCBQb3N0dXJlIFZhbGlkYXRvcikgdGhhdCBQb3N0dXJlIA0KICAgQ29s bGVjdG9yICJyZWNvZ25pemVzIiBhbmQgdHJ1c3RzIHRoZSBnaXZlbiBQb3N0dXJlIFZhbGlkYXRv ci4gVGhpcyANCiAgIGVuc3VyZXMgdGhhdCBQb3N0dXJlIENvbGxlY3RvciBpcyBkb2luZyB3b3Jr IG9uIGJlaGFsZiBvZiBhdXRoZW50aWMgDQogICBQb3N0dXJlIFZhbGlkYXRvci4gDQogICAgDQog ICAyLiBQQiBpbnRlcmZhY2UgDQogICAgICAgLSBDb21tdW5pY2F0aW9ucyBiZXR3ZWVuIENsaWVu dCBCcm9rZXIgYW5kIFNlcnZlciBCcm9rZXIgTUFZIA0KICAgbmVlZCB0byBiZSBwcm90ZWN0ZWQg YXQgbGVhc3QgZnJvbSBhY3RpdmUgYXR0YWNrZXIgKGludGVncml0eSwgDQogICBjb25maWRlbnRp YWxpdHksIHRpbWVsaW5lc3MpLiBJbnRlZ3JpdHkgYW5kIHRpbWVsaW5lc3MgYXJlIG9mIHRoZSAN CiAgIHV0bW9zdCBpbXBvcnRhbmNlLCB0byBwcmV2ZW50IHRoaXJkIHBhcnRpZXMgKGFueSBwYXJ0 aWVzIC0gaW5jbHVkaW5nIA0KICAgTmV0d29yayBFbmZvcmNlcikgZnJvbSBpbnRlcmZlcmluZyB3 aXRoIHBvc3R1cmUgdmFsaWRhdGlvbiBhbmQgDQogICBhZmZlY3RpbmcgUERQIGRlY2lzaW9ucy4g Q29uZmlkZW50aWFsaXR5IG1heSBiZSB1c2VmdWwgaGVyZSwgZm9yIA0KICAgZXhhbXBsZSB0byBw cmV2ZW50IGF0dGFja2VycyBmcm9tIGRldGVybWluaW5nIHdoaWNoIGhvc3Qgd291bGQgYmUgDQog ICB0aGUgbW9zdCB2dWxuZXJhYmxlIHRhcmdldCBiYXNlZCBvbiBpdHMgcG9zdHVyZSBpbmZvcm1h dGlvbi4gICANCiAgIEhvd2V2ZXIgdGhlcmUgaXMgcHJpdmFjeSBjb25jZXJuIHRoYXQgdGhlIGhv c3Qgc2hvdWxkIGJlIGFibGUgdG8gDQogICAic2VlIiB3aGF0IHBvdGVudGlhbGx5IHByaXZhY3kg c2Vuc2l0aXZlIGluZm9ybWF0aW9uIGFib3V0IGl0IGlzIA0KICAgYmVpbmcgc2VudCBvdXQuICBU aGlzIGNvbmNlcm4gbWF5IHByZXZlbnQgZW5jcnlwdGlvbiBmcm9tIGJlaW5nIHVzZWQgDQogICBv ciBmb3JjZSBhIHByZS1zY3JlZW5pbmcgb2YgdGhlIHBvc3R1cmUgaW5mb3JtYXRpb24gYWdhaW5z dCBhIA0KICAgcHJpdmFjeSBwb2xpY3kgYmVmb3JlIGFsbG93aW5nIGl0IHRvIGJlIHNlbnQgb3Zl ciB0aGUgbmV0d29yay4gDQogICAgDQogICAzLiBQVCBpbnRlcmZhY2UgDQogICAgICAgLSBUaGlz IGNvbW11bmljYXRpb24gY2hhbm5lbCBNVVNUIGJlIHByb3RlY3RlZDogZW5kcG9pbnQgbXV0dWFs IA0KICAgYXV0aGVudGljYXRpb24gd2l0aCBzdWJzZXF1ZW50IHNlY3VyZSBwaXBlIGVzdGFibGlz aG1lbnQuIE90aGVyd2lzZSANCiAgIHRoaXJkIHBhcnRpZXMgY291bGQgbGF1bmNoIGEgdmFyaWV0 eSBvZiBhdHRhY2tzLiANCiAgICANCiAgIDQuIFBWIGludGVyZmFjZSANCiAgICAgICAtIENvbW11 bmljYXRpb25zIGJldHdlZW4gU2VydmVyIEJyb2tlciBhbmQgUG9zdHVyZSBWYWxpZGF0b3JzIA0K ICAgU0hPVUxEIGJlIHByb3RlY3RlZCBiZWNhdXNlIHRoZSBWYWxpZGF0b3JzIGFyZSBsaWtlbHkg cnVubmluZyBvbiANCiAgIGRpZmZlcmVudCBzeXN0ZW1zIG9uIHRoZSBuZXR3b3JrLiBVbmxlc3Mg dGhlIFNlcnZlciBCcm9rZXIgaXMgYWJsZSANCiAgIHRvIHNlY3VyZWx5IGRldGVybWluZSB0aGF0 IGVhY2ggdGhlIFBvc3R1cmUgVmFsaWRhdG9yIGlzIGF1dGhlbnRpYyANCiAgIGFuZCBhdXRob3Jp dGF0aXZlLCB2YWxpZGF0aW9uIGRlY2lzaW9ucyBjb3VsZCBiZSBmb3JnZWQgYW5kIGFsbG93IA0K ICAgYnlwYXNzaW5nIHRoZSBlbnRpcmUgbmV0d29yayBhY2Nlc3MgcG9saWN5LiANCiAgICANCg0K DQoNCiAgDQpLaG9zcmF2aSwgZXQuIGFsLiAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDIwMDYgICAg ICAgICAgICAgICAgW1BhZ2UgOV0NCg0KDQoNCkludGVybmV0IERyYWZ0ICAgICAgICAgICAgIE5F QSBSZXF1aXJlbWVudHMgICAgICAgICAgICAgICAgIE1heSAyMDA2IA0KICAgNS4gSW50ZXJmYWNl cy9jb21tdW5pY2F0aW9ucyBiZXR3ZWVuIFBvc3R1cmUgQ29sbGVjdG9yKHMpIGFuZCBDbGllbnQg DQogICBCcm9rZXIgTUFZIG5lZWQgcHJvdGVjdGlvbiwgZXNwZWNpYWxseSBpZiB0aG9zZSBhcmUg ZGlmZmVyZW50IA0KICAgc29mdHdhcmUgZW50aXRpZXMuIEl0IGlzIGltcG9ydGFudCB0aGF0IGEg Q2xpZW50IEJyb2tlciBiZSBhbGxvd2VkIA0KICAgdG8gY29tbXVuaWNhdGUgd2l0aCBvbmx5IHRo ZSBhdXRob3JpemVkIFBvc3R1cmUgQ29sbGVjdG9ycyBiZWNhdXNlIA0KICAgb2YgdGhlIHRydXN0 IGlzc3VlLiBEZW5pYWwgb2YgU2VydmljZSBpcyB0aGUgbW9zdCBvYnZpb3VzIHRocmVhdCANCiAg IGhlcmUuIEZvcmdpbmcgYSBwb3N0dXJlIHNob3VsZCBub3QgYmUgZmVhc2libGUgYmVjYXVzZSBv ZiBQQSANCiAgIGludGVyZmFjZS4gDQogICAgDQogICA2LiBJbnRlcmZhY2UvY29tbXVuaWNhdGlv biBiZXR3ZWVuIENsaWVudCBCcm9rZXIgYW5kIE5ldHdvcmsgQWNjZXNzIA0KICAgUmVxdWVzdG9y IE1BWSBuZWVkIHByb3RlY3Rpb24uIA0KICAgIA0KICAgNy4gSW50ZXJmYWNlL2NvbW11bmljYXRp b24gYmV0d2VlbiBTZXJ2ZXIgQnJva2VyIGFuZCBOZXR3b3JrIEFjY2VzcyANCiAgIEF1dGhvcml0 eSBNQVkgYmUgcHJvdGVjdGVkLiANCiANCiA3Lk9wZXJhdGlvbmFsIENvbnNpZGVyYXRpb25zIA0K ICAgIA0KICAgVGhlIE5FQSB0ZWNobm9sb2d5IGludGVuZHMgdG8gYWRkcmVzcyBhIG1ham9yIGlz c3VlIGZvciBvd25lcnMgb2YgDQogICBuZXR3b3JrcyBieSBleHRlbmRpbmcgdGhlaXIgZXhpc3Rp bmcgYWJpbGl0eSB0byBsaW1pdCBhZG1pc3Npb24gdG8gDQogICB0aGUgbmV0d29yayBieSBpbnNw ZWN0aW9uIG9mIHRoZSBzZWN1cml0eSBwb3N0dXJlIG9mIHRoZSBzeXN0ZW0uICBJbiANCiAgIG9y ZGVyIHRvIG9mZmVyIGEgc29sdXRpb24gdG8gdGhpcyBpc3N1ZSwgTkVBIG5lZWRzIHRvIHByb3Zp ZGUgYSANCiAgIHNjYWxhYmxlIHNvbHV0aW9uIGFkZHJlc3NpbmcgYSB2YXN0IG1ham9yaXR5IG9m IHRoZSBzeXN0ZW1zIGRlcGxveWVkIA0KICAgd2hpbGUgcmVtYWluaW5nIG1hbmFnZWFibGUuICBU aGlzIGludHJvZHVjZXMgc2V2ZXJhbCBpc3N1ZXMgd2hpY2ggDQogICBzaG91bGQgYmUgY29uc2lk ZXJlZCBkdXJpbmcgdGhlIGRlZmluaXRpb24gb2YgdGhlIHByb3RvY29scywgDQogICBpbnRlcmZh Y2VzLCBhcmNoaXRlY3R1cmUgYW5kIHRoZWlyIHBvbGljaWVzLiANCiAgICANCiAgIDEuIFNvbWUg bmV0d29yayBkZXZpY2VzIChlLmcuIHByaW50ZXJzLCBsZWdhY3kgc3lzdGVtcykgd2lsbCBub3Qg DQogICBoYXZlIHN1cHBvcnQgZm9yIE5FQSBhZ2VudHMgcHJlc2VudC4gIEluIHRoaXMgc2l0dWF0 aW9uLCB0aGUgTkVBIA0KICAgc2VydmVyIG11c3QgYmUgYWJsZSB0byBkZXRlY3QgdGhhdCB0aGUg c3lzdGVtIHJlcXVlc3RpbmcgYWNjZXNzIGlzIA0KICAgaW5jYXBhYmxlIG9mIHJlc3BvbmRpbmcg dG8gTkVBIHByb3RvY29scyBhbmQgdGh1cyB3aWxsIG5vdCBiZSBhYmxlIA0KICAgdG8gcmVwb3J0 IGl0cyBzZWN1cml0eSBwb3N0dXJlLiAgVGhlIE5FQSBhcmNoaXRlY3R1cmUgc2hvdWxkIGFsbG93 IA0KICAgZm9yIHRoaXMgZXZlbnQgdG8gYmUgZGV0ZWN0ZWQgYW5kIHJlcG9ydGVkIHRvIG90aGVy IGNvbXBvbmVudHMgd2hpY2ggDQogICBtaWdodCBiZSBhYmxlIHRvIGV2YWx1YXRlIHJpc2sgdmlh IG90aGVyIG1lY2hhbmlzbXMgKGUuZy4gdXNpbmcgDQogICBzY2FubmluZyB0ZWNobmlxdWVzKSBh bmQgcmVwb3J0IGJhY2sgYSBzdWdnZXN0ZWQgYWN0aW9uLiANCiAgICANCiAgIDIuIEFkbWlzc2lv biBwb2xpY3kgc2hvdWxkIGJlIGNhcGFibGUgb2YgYmVpbmcgY29tYmluZWQgd2l0aCANCiAgIGF1 dGhlbnRpY2F0aW9uIHBvbGljeSBzbyBkaWZmZXJlbnRpYXRlZCBwb3N0dXJlIGV2YWx1YXRpb24g aXMgDQogICBwb3NzaWJsZSBiYXNlZCBvbiB0aGUgaWRlbnRpdHkgYW5kIG90aGVyIGZhY3RvcnMg YWJvdXQgdGhlIA0KICAgcmVxdWVzdGluZyBzeXN0ZW0uICBGb3IgZXhhbXBsZSwgaW4gbWFueSBj YXNlcyBjdXN0b21lcnMgbWF5IHdpc2ggdG8gDQogICBhbGxvdyBjZXJ0YWluIGluZGl2aWR1YWxz IChlLmcuIGV4ZWN1dGl2ZXMpIHRvIGFsd2F5cyBiZSBhbGxvd2VkIA0KICAgYWNjZXNzIHRvIHRo ZSBuZXR3b3JrIGV2ZW4gaWYgTkVBIGRldGVjdHMgYSBwcm9ibGVtLiAgU2ltaWxhcmx5LCANCiAg IGRpZmZlcmVudCBwb3N0dXJlIGNoZWNraW5nIHByb2ZpbGVzIG1pZ2h0IGJlIGFwcGxpZWQgZGVw ZW5kaW5nIG9uIA0KICAgdGhlIHJlcXVlc3Rpbmcgc3lzdGVtIG9yIHVzZXKScyBpZGVudGl0eS4g DQogICAgDQogICAzLiBEdWUgdG8gdGhlIHBvdGVudGlhbGx5IGxhcmdlIG51bWJlciBvZiBzeXN0 ZW1zIG9mZmVyaW5nIGFuZC9vciANCiAgIGV2YWx1YXRpbmcgcG9zdHVyZSBpbmZvcm1hdGlvbiBh bmQgdGhlIHF1YW50aXR5IG9mIGVuZm9yY2VtZW50IA0KICAgZGV2aWNlcywgdGhpcyBwcmVzZW50 cyBhIGRpc3RyaWJ1dGVkIHBvbGljeSBpc3N1ZSBmb3IgTkVBIGRlcGxveWVycy4gIA0KICAgVGhl IE5FQSBjb21wb25lbnRzIHNob3VsZCBiZSBtYW5hZ2VhYmxlIHVzaW5nIGRhdGEgbW9kZWwgZGVm aW5pdGlvbnMgDQogICBhc3NvY2lhdGVkIHdpdGhpbiBleGlzdGluZyBtYW5hZ2VtZW50IHByb3Rv Y29sIGVudmlyb25tZW50cyAoZS5nLiANCiAgIFNOTVAsIENJTS4pIA0KDQoNCg0KICANCktob3Ny YXZpLCBldC4gYWwuICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMjAwNiAgICAgICAgICAgICAgIFtQ YWdlIDEwXQ0KDQoNCg0KSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgTkVBIFJlcXVpcmVtZW50 cyAgICAgICAgICAgICAgICAgTWF5IDIwMDYgDQogICAgDQogICA0LiBCZWNhdXNlIHRoZSBORUEg aW5mcmFzdHJ1Y3R1cmUgaXMgaW52b2x2ZWQgaW4gbWFraW5nIGRlY2lzaW9ucyANCiAgIGFib3V0 IGV2ZXJ5IHN5c3RlbZJzIHJlcXVlc3QgdG8gam9pbiBhbmQgcmVtYWluIG9uIHRoZSBuZXR3b3Jr LCBORUEgDQogICBkZXBsb3ltZW50cyBzaG91bGQgaGF2ZSBtZWNoYW5pc21zIHRoYXQgcHJvdGVj dCBpdCBmcm9tIGRpcmVjdCANCiAgIGF0dGFjayBvciBvcGVyYXRpb25hbCBzaXR1YXRpb25zIHdo ZXJlIGl0IG1pZ2h0IGJlIHVuYXZhaWxhYmxlLiAgDQogICBIaWdobHkgYXZhaWxhYmxlLCBkaXN0 cmlidXRlZCBkZXBsb3ltZW50IGFyY2hpdGVjdHVyZXMgc2hvdWxkIGhlbHAgDQogICBtaW5pbWl6 ZSBkb3dudG93biBhbmQgYXZvaWQgc2luZ2xlIHBvaW50IG9mIGZhaWx1cmUgc2NlbmFyaW9zLiAg DQogICBIb3dldmVyIE5FQSBzb2x1dGlvbnMgbWF5IG5lZWQgdG8gb2ZmZXIgZGVwbG95ZXJzIHNv bWUgcG9saWN5LWRyaXZlbiANCiAgIGZsZXhpYmlsaXR5IGluIGhvdyB0aGUgTkVBIGNvbXBvbmVu dHMgcmVzcG9uZCB3aGVuIGZhY2VkIHdpdGggYW4gDQogICB1bmF2YWlsYWJsZSBORUEgU2VydmVy IGNvbXBvbmVudC4gDQogICAgDQogICAgDQogOC5TZWN1cml0eSBDb25zaWRlcmF0aW9ucyANCiAg ICANCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0aGUgcmVxdWlyZW1lbnRzIGZvciB0aGUgaW50 ZXJmYWNlcyANCiAgIChwcm90b2NvbHMpIGZvciBhIHNlY3VyaXR5IG1lY2hhbmlzbSBhc3Nlc3Nt ZW50IGFuZCBlbmZvcmNlbWVudCANCiAgIHNjaGVtZS4gIEFzIHN1Y2gsIGl0IGRvZXMgbm90IGRl ZmluZSBhIHNwZWNpZmljIHNvbHV0aW9uIG9yIHNldCBvZiANCiAgIHRlY2hub2xvZ2llcywgc28g dGhpcyBzZWN0aW9uIHdpbGwgaGlnaGxpZ2h0IHNlY3VyaXR5IGlzc3VlcyB0aGF0IA0KICAgbWF5 IGFwcGx5IHRvIE5FQSBpbiBnZW5lcmFsIG9yIHRvIHBhcnRpY3VsYXIgYXNwZWN0cyBvZiB0aGUg ZXZlbnR1YWwgDQogICB0ZWNobmljYWwgYXJjaGl0ZWN0dXJlLiANCiAgICANCiANCjguMS4gU2Nv cGUgYW5kIE92ZXJsYXAgDQogICAgDQogICBJbmhlcmVudCBpbiB0aGUgcmVxdWlyZW1lbnRzIGlz IGEgZGVzaXJlIGZvciBORUEgY2FuZGlkYXRlIHByb3RvY29scyANCiAgIHRocm91Z2hvdXQgdGhl IGFyY2hpdGVjdHVyZSB0byBhY2NvbW1vZGF0ZSB0aGUgdXNlIG9mIHN0cm9uZyANCiAgIHNlY3Vy aXR5IG1lY2hhbmlzbXMgYXMgZGljdGF0ZWQgYnkgdGhlIGRlcGxveWVyLiAgSW4gc29tZSBjYXNl cywgDQogICB0aGVzZSBtZWNoYW5pc21zIG1heSBhcHBlYXIgdG8gcHJvdmlkZSBvdmVybGFwcGlu ZyBwcm90ZWN0aW9ucy4gIFRoZSANCiAgIG92ZXJsYXBzIG1heSBiZSBkZXNpcmVkIGJ5IGRlcGxv eWVyIHRvIG9mZmVyIGEgZGVmZW5zZSBpbiBkZXB0aCANCiAgIGFwcHJvYWNoOyBob3dldmVyIGJl Y2F1c2Ugb2YgdGhlIGxheWVyaW5nIG9mIHRoZSBwcm90b2NvbHMgZWFjaCANCiAgIG1lY2hhbmlz bSBvZmZlcnMgc2xpZ2h0bHkgZGlmZmVyZW50IHByb3RlY3Rpb24gYmVuZWZpdHMgYW5kIGxldmVs cyANCiAgIG9mIGdyYW51bGFyaXR5LiAgDQogICAgDQogICBGb3IgZXhhbXBsZSwgYSBkZXBsb3ll ciBtYXkgd2lzaCB0byBlbmNyeXB0IHRyYWZmaWMgYXQgdGhlIFBUIGxheWVyIA0KICAgdG8gcHJv dGVjdCBhZ2FpbnN0IHNvbWUgZm9ybXMgb2YgdHJhZmZpYyBhbmFseXNpcyBvciBpbnRlcmNlcHRp b24gYnkgDQogICBhbiBlYXZlc2Ryb3BwZXIuIEFkZGl0aW9uYWxseSwgdGhlIGRlcGxveWVyIG1h eSBhbHNvIHNlbGVjdGl2ZWx5IA0KICAgZW5jcnlwdCBhIFBvc3R1cmUgQ29sbGVjdG9yJ3Mgc2V0 IG9mIHJlcG9ydGVkIGF0dHJpYnV0ZXMgYXQgdGhlIFBBIA0KICAgbGF5ZXIgdG8gYWxsb3cgdGhl IHBlZXIgUG9zdHVyZSBWZXJpZmllciB0byBhY2hpZXZlIGVuZCB0byBlbmQgDQogICBjb25maWRl bnRpYWxpdHkuICBJbiBwYXJ0aWN1bGFyLCB0aGlzIG1pZ2h0IGJlIGRlc2lyZWQgd2hlbiB0aGUg TkVBIA0KICAgU2VydmVyIHNpZGUgZGVjaXNpb24gcG9pbnQgc3BhbnMgc2V2ZXJhbCBzeXN0ZW1z IHNvIHRoZSBOQUEgaXMgb24gYSANCiAgIGRpZmZlcmVudCBzeXN0ZW0gZnJvbSB0aGUgVmVyaWZp ZXIuIA0KICAgIA0KICAgSW4gZ2VuZXJhbCwgdGhlIE5FQSBhcmNoaXRlY3R1cmUncyBwcm90b2Nv bHMgYXJlIGludGVuZGluZyB0byANCiAgIHByb3ZpZGUgdG8gdGhlIFBvc3R1cmUgQ29sbGVjdG9y IHRoZSBhYmlsaXR5IHRvIHNhZmVseSBzZW5kIGl0cyANCiAgIG1lYXN1cmVtZW50IGF0dHJpYnV0 ZXMgYWNyb3NzIGFuIHVudHJ1c3R3b3J0aHkgbmV0d29yayB0byBhIHBlZXIgDQogICBQb3N0dXJl IFZhbGlkYXRvciBhbmQgcmVjZWl2ZSBwcm90ZWN0ZWQgcmVxdWVzdHMvcmVzcG9uc2VzLiAgVGhl IA0KICAgYXJjaGl0ZWN0dXJlIGlzIG5vdCBpbnRlbmRpbmcgdG8gcHJvdmlkZSBsb2NhbCBpbnRl Z3JpdHkgcHJvdGVjdGlvbiANCiAgIGZvciB0aGUgcHJvcGVyIG9wZXJhdGlvbiBvZiB0aGUgUG9z dHVyZSBDb2xsZWN0b3IgaXRzZWxmLiAgRm9yIA0KICAgZXhhbXBsZSwgTkVBIHRlY2hub2xvZ2ll cyBkbyBub3QgY2xhaW0gdG8gcHJldmVudCBhIGNhcmVmdWxseSANCg0KDQogIA0KS2hvc3Jhdmks IGV0LiBhbC4gICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMDA2ICAgICAgICAgICAgICAgW1BhZ2Ug MTFdDQoNCg0KDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICBORUEgUmVxdWlyZW1lbnRzICAg ICAgICAgICAgICAgICBNYXkgMjAwNiANCiAgIGNyYWZ0ZWQgcGllY2Ugb2YgbWFsd2FyZSAoZS5n LiByb290a2l0KSBmcm9tIHRyaWNraW5nIHRoZSBQb3N0dXJlIA0KICAgQ29sbGVjdG9yIGludG8g aW5hY2N1cmF0ZWx5IHJlcG9ydGluZyB0aGUgc3RhdGUgb2YgdGhlIHN5c3RlbSBzbyBpdCANCiAg IGNhbiByZW1haW4gdW5kZXRlY3RlZC4gIFN1Y2ggaW50ZWdyaXR5IHByb3RlY3Rpb24gb2YgdGhl IENvbGxlY3RvciANCiAgIGFuZCBvdGhlciBhc3BlY3RzIG9mIHRoZSBzeXN0ZW0gbWlnaHQgYmUg b2ZmZXJlZCBieSBvcnRob2dvbmFsIA0KICAgc2VjdXJpdHkgbWVjaGFuaXNtcyBsZXZlcmFnaW5n IHNlY3VyaXR5IGhhcmR3YXJlIGFuZC9vciBwcm90ZWN0ZWQgDQogICB0cnVzdGVkIHNvZnR3YXJl LiANCiAgICANCiAgIERpZmZlcmVudCB1c2UgY2FzZXMgYW5kIGVudmlyb25tZW50cyBmb3IgdGhl IE5FQSB0ZWNobm9sb2dpZXMgd2lsbCANCiAgIGxpa2VseSBpbmZsdWVuY2UgdGhlIHNlbGVjdGlv biBvZiB0aGUgc3RyZW5ndGggYW5kIHNlY3VyaXR5IA0KICAgbWVjaGFuaXNtcyBlbXBsb3llZCBk dXJpbmcgYW4gYXNzZXNzbWVudC4gIFRoZSBnb2FsIG9mIHRoZSBORUEgDQogICByZXF1aXJlbWVu dHMgaXMgdG8gZW5jb3VyYWdlIHRoZSBzZWxlY3Rpb24gb2YgdGVjaG5vbG9naWVzIGFuZCANCiAg IHByb3RvY29scyB0aGF0IGFyZSBjYXBhYmxlIG9mIGVuZm9yY2luZyB0aGUgbmVjZXNzYXJ5IHBy b3RlY3Rpb25zIA0KICAgZm9yIGEgd2lkZSB2YXJpZXR5IG9mIGFzc2Vzc21lbnQgdXNlIGNhc2Vz LiANCiAgICANCjguMi4gSW50ZXJlc3RpbmcgQXR0YWNrIENsYXNzZXMgDQogICAgDQogICBBIHZh cmlldHkgb2YgYXR0YWNrcyBhcmUgcG9zc2libGUgYWdhaW5zdCBjdXJyZW50IGFzc2Vzc21lbnQg DQogICB0ZWNobm9sb2dpZXMuIFRoaXMgc2VjdGlvbiBkb2VzIG5vdCBpbmNsdWRlIGEgZnVsbCB0 aHJlYXQgYW5hbHlzaXMsIA0KICAgYnV0IHdpc2hlcyB0byBoaWdobGlnaHQgYSBmZXcgYXR0YWNr cyB3aGljaCBpbmZsdWVuY2VkIHRoZSANCiAgIHJlcXVpcmVtZW50IGRlZmluaXRpb24gYW5kIHNo b3VsZCBiZSBjb25zaWRlcmVkIGJ5IGRlcGxveWVycyANCiAgIHNlbGVjdGluZyB1c2Ugb2YgcHJv dGVjdGl2ZSBtZWNoYW5pc21zIHdpdGhpbiB0aGUgY29uY2VwdHVhbCANCiAgIGFyY2hpdGVjdHVy ZS4gDQogICAgDQogICBUaGUgZm9sbG93aW5nIHR5cGVzIG9mIGF0dGFja3MgYXJlIHBvc3NpYmxl IGFnYWluc3QgZWFjaCBvZiB0aGUgDQogICBuZXR3b3JrIHByb3RvY29scyBkZWZpbmVkIGluIHRo ZSBjb25jZXB0dWFsIGFyY2hpdGVjdHVyZSBhbmQgdGh1cyANCiAgIHNob3VsZCBiZSBjb25zaWRl cmVkIGJ5IGRlcGxveWVycy4gDQogICAgDQo4LjIuMS4gTWFuLWluLXRoZS1NaWRkbGUgKE1JVE0p IA0KICAgIA0KICAgTUlUTSBhdHRhY2tzIGFnYWluc3QgYSBuZXR3b3JrIHByb3RvY29sIGV4aXN0 IHdoZW4gYSAzcmQgcGFydHkgY2FuIA0KICAgc2l0IGJldHdlZW4gdHdvIGxlZ2l0aW1hdGUgY29t bXVuaWNhdGluZyBwYXJ0aWVzIHdpdGhvdXQgZGV0ZWN0aW9uLiAgDQogICBGb3IgZXhhbXBsZSwg YSBtYWx3YXJlIGluZmVzdGVkIG1hY2hpbmUgbWlnaHQgd2lzaCB0byBqb2luIHRoZSANCiAgIG5l dHdvcmsgdXNpbmcgbWVhc3VyZW1lbnRzIGNvbGxlY3RlZCBieSBhIGNsZWFuIHN5c3RlbSBieSBp bnNlcnRpbmcgDQogICBpdHNlbGYgaW50byBhbmQgcHJveHlpbmcgYW4gYXNzZXNzbWVudCBtZXNz YWdlIGV4Y2hhbmdlLiBUaGUgaW1wYWN0IA0KICAgb2YgdGhlIGRhbWFnZSBjYXVzZWQgYnkgdGhl IE1JVE0gY2FuIGJlIGxpbWl0ZWQgb3IgcHJldmVudGVkIGJ5IA0KICAgc2VsZWN0aW9uIG9mIGFw cHJvcHJpYXRlIHByb3RlY3RpdmUgbWVjaGFuaXNtcy4gDQogICAgDQogICBUaGUgcmVxdWlyZW1l bnQgZm9yIFBUIHRvIGJlIGNhcGFibGUgb2Ygc3VwcG9ydGluZyBiaS1kaXJlY3Rpb25hbCANCiAg IGF1dGhlbnRpY2F0aW9uIHByZXZlbnRzIHRoZSBhdHRhY2tlciBmcm9tIGluc2VydGluZyB0aGVt c2VsdmVzIGFzIGFuIA0KICAgYWN0aXZlIHBhcnRpY2lwYW50IChwcm94eSkgd2l0aGluIHRoZSBj b21tdW5pY2F0aW9ucyB3aXRob3V0IA0KICAgZGV0ZWN0aW9uIChhc3N1bWluZyBhdHRhY2tlciBs YWNrcyBjcmVkZW50aWFscyBjb252aW5jaW5nIGVpdGhlciANCiAgIHBhcnR5IGl0IGlzIGxlZ2l0 aW1hdGUuKSBSZS11c2FibGUgY3JlZGVudGlhbHMgc2hvdWxkIG5vdCBiZSBleHBvc2VkIA0KICAg b24gdGhlIG5ldHdvcmsgdG8gYXNzdXJlIHRoZSBNSVRNIGRvZXNuJ3QgaGF2ZSBhIHdheSB0byBp bXBlcnNvbmF0ZSANCiAgIGVpdGhlciBwYXJ0eS4gDQogICAgDQogICBIb3dldmVyIHRoZSBNSVRN IG1pZ2h0IHN0aWxsIGFjdCBhcyBhIG1lc3NhZ2UgcmVsYXkgYmV0d2VlbiB0aGUgDQogICBwYXJ0 aWVzIGFuZCBjaGFuZ2UsIGVhdmVzZHJvcCwgb3Igc3RlYWwgYW5kIHJlcGxheSB0aGUgDQogICBj b21tdW5pY2F0aW9ucy4gIFRoZXNlIGZvcm1zIG9mIGF0dGFjayByZXF1aXJlIGFkZGl0aW9uYWwg DQogICBwcm90ZWN0aW9ucyBkaXNjdXNzZWQgYmVsb3cuIA0KDQoNCg0KICANCktob3NyYXZpLCBl dC4gYWwuICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMjAwNiAgICAgICAgICAgICAgIFtQYWdlIDEy XQ0KDQoNCg0KSW50ZXJuZXQgRHJhZnQgICAgICAgICAgICAgTkVBIFJlcXVpcmVtZW50cyAgICAg ICAgICAgICAgICAgTWF5IDIwMDYgDQogICAgDQo4LjIuMi4gTWVzc2FnZSBNb2RpZmljYXRpb24g DQogICAgDQogICBXaXRob3V0IG1lc3NhZ2UgcHJvdGVjdGlvbiwgYW4gYXR0YWNrZXIgY2FwYWJs ZSBvZiBpbnRlcmNlcHRpb24gb2YgDQogICBhbiBhc3Nlc3NtZW50IG1lc3NhZ2Ugd291bGQgYmUg Y2FwYWJsZSBvZiBtb2RpZnlpbmcgdGhlIGNvbnRlbnRzIGFuZCANCiAgIGNhdXNpbmcgYW4gaW5j b3JyZWN0IGFjdGlvbiB0byBvY2N1ci4gIEZvciBleGFtcGxlLCB0aGUgYXR0YWNrZXIgDQogICBt aWdodCBjaGFuZ2UgdGhlIG1lYXN1cmVtZW50IGF0dHJpYnV0ZXMgdG8gYWx3YXlzIHJlZmxlY3Qg aW5jb3JyZWN0IA0KICAgdmFsdWVzIGFuZCB0aHVzIHByZXZlbnQgYSBzeXN0ZW0gZnJvbSBqb2lu aW5nIHRoZSBuZXR3b3JrLiAgVW5sZXNzIA0KICAgdGhlIE5FQSBTZXJ2ZXIgY291bGQgZGV0ZWN0 IHRoaXMgY2hhbmdlLCB0aGUgYXR0YWNrZXIgY291bGQgcHJldmVudCANCiAgIG5ldHdvcmsgYWRt aXNzaW9uIHRvIGxhcmdlIG51bWJlcnMgb2YgY2xlYW4gc3lzdGVtcy4gQ29udmVyc2VseSwgdGhl IA0KICAgYXR0YWNrZXIgY291bGQgYWxsb3cgbWFsd2FyZSBpbmZlc3RlZCBtYWNoaW5lIHRvIGJl IGFkbWl0dGVkIGJ5IA0KICAgY2hhbmdpbmcgdGhlIGF0dHJpYnV0ZXMuIA0KICAgIA0KICAgSW4g b3JkZXIgdG8gcHJvdGVjdCBhZ2FpbnN0IHN1Y2ggYXR0YWNrcywgdGhlIFBUIGluY2x1ZGVzIGEg DQogICByZXF1aXJlbWVudCBmb3Igc3Ryb25nIGludGVncml0eSBwcm90ZWN0aW9uIChlLmcuIGlu Y2x1ZGluZyBhIA0KICAgcHJvdGVjdGVkIGhhc2ggb2YgdGhlIG1lc3NhZ2UpIHNvIHRoaXMgY2hh bmdlIHdpbGwgYmUgZGV0ZWN0ZWQuICBQQSANCiAgIGluY2x1ZGVzIGEgc2ltaWxhciByZXF1aXJl bWVudCB0byBlbmFibGUgZW5kIHRvIGVuZCBpbnRlZ3JpdHkgDQogICBwcm90ZWN0aW9uIG9mIHRo ZSBtZXNzYWdlLiAgIA0KICAgIA0KICAgSXQgaXMgaW1wb3J0YW50IHRoYXQgaW50ZWdyaXR5IHBy b3RlY3Rpb24gc2NoZW1lcyBsZXZlcmFnZSBzZWNyZXQgDQogICBpbmZvcm1hdGlvbiAobm90IGtu b3duIGJ5IHRoZSBhdHRhY2tlcikgdGhhdCBhcmUgYm91bmQgdG8gdGhlIA0KICAgdHJhbnNhY3Rp b24gc3VjaCBhcyBhbiBlbmNyeXB0ZWQgbWVzc2FnZSBoYXNoIG9yIEhNQUMgW1JFRl0gbGlua2Vk IA0KICAgdG8gdGhlIGF1dGhlbnRpY2F0aW9uLiBNZXNzYWdlIGhhc2gga2V5cyBmcm9tIHByaW9y IHRyYW5zYWN0aW9ucyANCiAgIHBvc3NpYmx5IGludm9sdmluZyBvdGhlciBzeXN0ZW1zIG11c3Qg bm90IGJlIHJlLXVzYWJsZSB3aXRob3V0IA0KICAgZGV0ZWN0aW9uLiANCiAgICANCjguMi4zLiBN ZXNzYWdlIFJlcGxheSBvciBUaGVmdCANCiAgICANCiAgIEEgcGFzc2l2ZSBhdHRhY2tlciBtaWdo dCBsaXN0ZW4gdG8gdGhlIG5ldHdvcmsgcmVjb3JkaW5nIG1lc3NhZ2VzIA0KICAgZnJvbSBhIGhl YWx0aHkgY2xpZW50IGZvciBsYXRlciByZS11c2UgdG8gdGhlIHNhbWUgTkVBIFNlcnZlciBvciAN CiAgIGp1c3QgdG8gYnVpbGQgYW4gaW52ZW50b3J5IG9mIHNvZnR3YXJlIHJ1bm5pbmcgb24gb3Ro ZXIgc3lzdGVtcy4gIA0KICAgVGhlIE5FQSBTZXJ2ZXIgbmVlZHMgdG8gYmUgY2FwYWJsZSBvZiBk ZXRlY3RpbmcgdGhlIHJlcGxheSBvciB0aGUgDQogICBhcmNoaXRlY3R1cmUgbXVzdCBhc3N1cmUg dGhhdCB0aGUgZWF2ZXNkcm9wcGVyIGNhbiBub3Qgb2J0YWluIHRoZSANCiAgIGF0dHJpYnV0ZSB2 YWx1ZXMgaW4gdGhlIGZpcnN0IHBsYWNlLiANCiAgICANCiAgIFRoZSBwcm90ZWN0aW9uIG9mIHRo ZSBQVCwgUEIgb3IgUEEgbWVzc2FnZXMgdXNpbmcgZW5jcnlwdGlvbiANCiAgIHByZXZlbnRzIHRo ZSBwYXNzaXZlIGxpc3RlbmVyIGZyb20gbGVhcm5pbmcgdGhlIGV4Y2hhbmdlZCBhdHRyaWJ1dGUg DQogICB2YWx1ZXMgZm9yIHRoZWZ0IG9yIHJlcGxheS4gIEJ5IGxpbmtpbmcgdGhlIGVuY3J5cHRl ZCB0cmFuc2FjdGlvbiB0byANCiAgIHRoZSBhdXRoZW50aWNhdGlvbiBldmVudCBhbmQgbGV2ZXJh Z2luZyBhIHBlci10cmFuc2FjdGlvbiBmcmVzaG5lc3MgDQogICBleGNoYW5nZSwgdGhpcyBwcmV2 ZW50cyBhIHJlcGxheSBvZiB0aGUgZW5jcnlwdGVkIHRyYW5zYWN0aW9uLiANCiAgICANCiAgIEFz IGRpc2N1c3NlZCwgdGhlcmUgYXJlIGEgdmFyaWV0eSBvZiBwcm90ZWN0aXZlIG1lY2hhbmlzbXMg aW5jbHVkZWQgDQogICBpbiB0aGUgcmVxdWlyZW1lbnRzIGZvciBjYW5kaWRhdGUgTkVBIHByb3Rv Y29scy4gRGlmZmVyZW50IHVzZSBjYXNlcyANCiAgIGFuZCBlbnZpcm9ubWVudHMgbWF5IGNhdXNl IGRlcGxveWVycyB0byBkZWNpZGUgbm90IHRvIHVzZSBzb21lIG9mIA0KICAgdGhlc2UgbWVjaGFu aXNtczsgaG93ZXZlciB0aGlzIHNob3VsZCBiZSBkb25lIHdpdGggYW4gdW5kZXJzdGFuZGluZyAN CiAgIHRoYXQgdGhlIGFyY2hpdGVjdHVyZSBtYXkgYmVjb21lIHZ1bG5lcmFibGUgdG8gc29tZSBj bGFzc2VzIG9mIA0KICAgYXR0YWNrLiAgQXMgYWx3YXlzIGEgYmFsYW5jZSBvZiByaXNrIHZzLiBw ZXJmb3JtYW5jZSwgdXNhYmlsaXR5LCANCiAgIG1hbmFnZWFiaWxpdHkgYW5kIG90aGVyIGZhY3Rv cnMgc2hvdWxkIGJlIHRha2VuIGludG8gYWNjb3VudC4gDQogICAgDQoNCg0KDQogIA0KS2hvc3Jh dmksIGV0LiBhbC4gICAgICAgRXhwaXJlcyBOb3ZlbWJlciAyMDA2ICAgICAgICAgICAgICAgW1Bh Z2UgMTNdDQoNCg0KDQpJbnRlcm5ldCBEcmFmdCAgICAgICAgICAgICBORUEgUmVxdWlyZW1lbnRz ICAgICAgICAgICAgICAgICBNYXkgMjAwNiANCiAgICANCiA5LlJlZmVyZW5jZXMgDQo5LjEuTm9y bWF0aXZlIFJlZmVyZW5jZXMgDQogICAgDQogIDEuIFMuIEJyYWRuZXIsICJUaGUgSW50ZXJuZXQg U3RhbmRhcmRzIFByb2Nlc3MgLVJldmlzaW9uIDMiLCBSRkMgMjAyNiwgDQogICAgIE9jdG9iZXIg MTk5Ni4gIA0KIA0KICAyLiBTLiBCcmFkbmVyLCAiS2V5d29yZHMgZm9yIHVzZSBpbiBSRkNzIHRv IEluZGljYXRlIFJlcXVpcmVtZW50IA0KICAgICBMZXZlbHMiLCBSRkMyMTE5IChCQ1ApLCBJRVRG LCBNYXJjaCAxOTk3LiANCiAgICANCiAgMy4gUy4gSGFubmEsIGV0LiBhbC4sICJOZXR3b3JrIEVu ZHBvaW50IEFzc2Vzc21lbnQgKE5FQSkgUHJvYmxlbSANCiAgICAgU3RhdGVtZW50IiwgZHJhZnQt dGhvbXNvbi1uZWEtcHJvYmxlbS1zdGF0ZW1lbnQtMDEudHh0LCBNYXJjaCAyMDA2LiANCiANCiAg NC4gIEFib2JhLCAgQi4sICBCbHVuaywgIEwuLCAgVm9sbGJyZWNodCwgIEouLCAgQ2FybHNvbiwg IEouLCAgYW5kICBILiANCiAgICAgTGV2a293ZXR6LCAiRXh0ZW5zaWJsZSBBdXRoZW50aWNhdGlv biBQcm90b2NvbCAoRUFQKSIsIFJGQyAzNzQ4LCANCiAgICAgSnVuZSAyMDA0LiANCiANCiAgNS4g UmlnbmV5LCBDLiwgV2lsbGVucywgUy4sIFJ1YmVucywgQS4sIGFuZCBXLiBTaW1wc29uLCAiUmVt b3RlIA0KICAgICBBdXRoZW50aWNhdGlvbiBEaWFsIEluIFVzZXIgU2VydmljZSAoUkFESVVTKSIs IFJGQyAyODY1LCBKdW5lIDIwMDAuIA0KIA0KICA2LiBULiAgRGllcmtzLCAgRS4gIFJlc2Nvcmxh LCCRkVRoZSBUcmFuc3BvcnQgIExheWVyICBTZWN1cml0eSAgKFRMUykgDQogICAgIFByb3RvY29s IFZlcnNpb24gMS4xkpIsIFJGQyA0MzQ2LCBBcHJpbCAyMDA2LiANCiANCiAgNy4gUy4gS2VudCwg Ui4gQXRraW5zb24sIJGRU2VjdXJpdHkgQXJjaGl0ZWN0dXJlIGZvciB0aGUgSW50ZXJuZXQgDQog ICAgIFByb3RvY29skpIsIFJGQyAyNDAxLCBOb3ZlbWJlciAxOTk4LiAoSVBTZWMpIA0KIA0KICAg IA0KOS4yLkluZm9ybWF0aXZlIFJlZmVyZW5jZXMgDQogICAgDQogIDguIJGRVENHIFRydXN0ZWQg TmV0d29yayBDb25uZWN0IChUTkMpIEFyY2hpdGVjdHVyZSBmb3IgDQogICAgIEludGVyb3BlcmFi aWxpdHmSkiwgDQogICAgIGh0dHBzOi8vd3d3LnRydXN0ZWRjb21wdXRpbmdncm91cC5vcmcvc3Bl Y3MvVE5DL1ROQ19BcmNoaXRlY3R1cmVfdjENCiAgICAgXzFfcjIucGRmLCBNYXkgMjAwNi4gDQog DQogIDkuIENpc2NvIE5ldHdvcmsgQWRtaXNzaW9uIENvbnRyb2wgKE5BQyksIGh0dHA6Ly93d3cu Y2lzY28uY29tL2dvL25hYyAgDQogDQogIDEwLiAgTWljcm9zb2Z0IE5ldHdvcmsgQWNjZXNzIFBy b3RlY3Rpb24gKE5BUCksIA0KICAgICBodHRwOi8vd3d3Lm1pY3Jvc29mdC5jb20vdGVjaG5ldC9p dHNvbHV0aW9ucy9uZXR3b3JrL25hcC9kZWZhdWx0Lm1zDQogICAgIHB4ICANCiANCiAgMTEuICBJ RUVFLCAiTG9jYWwgYW5kIE1ldHJvcG9saXRhbiBBcmVhIE5ldHdvcmtzOiBQb3J0LWJhc2VkIE5l dHdvcmsgDQogICAgIEFjY2VzcyBDb250cm9sIiwgMjAwNC4gKDgwMi4xeCkgDQogDQoNCg0KDQoN CiAgDQpLaG9zcmF2aSwgZXQuIGFsLiAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDIwMDYgICAgICAg ICAgICAgICBbUGFnZSAxNF0NCg0KDQoNCkludGVybmV0IERyYWZ0ICAgICAgICAgICAgIE5FQSBS ZXF1aXJlbWVudHMgICAgICAgICAgICAgICAgIE1heSAyMDA2IA0KICAxMi4gIEZvcnNiZXJnLCBE LiwgIlByb3RvY29sIGZvciBDYXJyeWluZyBBdXRoZW50aWNhdGlvbiBmb3IgTmV0d29yayANCiAg ICAgQWNjZXNzIChQQU5BKSIsIGRyYWZ0LWlldGYtcGFuYS1wYW5hLTExICh3b3JrIGluIHByb2dy ZXNzKSwgTWFyY2ggDQogICAgIDIwMDYuIA0KIA0KICAgIA0KIEF1dGhvcnMnIEFkZHJlc3NlcyAm IEFja25vd2xlZGdtZW50cyANCiAgICANCiAgIEhvcm11emQgS2hvc3JhdmkgKGNvLWVkaXRvcikg DQogICBJbnRlbCANCiAgIDIxMTEgTkUgMjV0aCBBdmVudWUgDQogICBIaWxsc2Jvcm8sIE9SIDk3 MTI0IFVTQSANCiAgIFBob25lOiArMSA1MDMgMjY0IDAzMzQgDQogICBFbWFpbDogaG9ybXV6ZC5t Lmtob3NyYXZpQGludGVsLmNvbSANCiAgICANCiAgIFBhdWwgU2FuZ3N0ZXIgKGNvLWVkaXRvcikg DQogICBTeW1hbnRlYyBDb3Jwb3JhdGlvbiANCiAgIDY4MjUgQ2l0cmluZSBEciANCiAgIENhcmxz YmFkLCBDQSA5MjAwOSBVU0EgDQogICBFbWFpbDogcGF1bF9zYW5nc3RlckBzeW1hbnRlYy5jb20g DQogICAgDQogICBLZXZpbiBBbW9yaW4gDQogICBIYXJ2YXJkIFVuaXZlcnNpdHkgDQogICA3OSBK RksgU3QuIA0KICAgQ2FtYnJpZGdlLCBNQSAwMjEzOCANCiAgIFBob25lOiArMSA2MTctMzg0LTY2 OTkgDQogICBFbWFpbDogS2V2aW5fQW1vcmluQEhhcnZhcmQuZWR1IA0KICAgIA0KICAgRGlhbmEg QXJyb3lvICANCiAgIElCTSAgDQogICAxMTUwMSBCdXJuZXQgUm9hZCAgDQogICBBdXN0aW4sIFR4 ICA3ODc1OCAgDQogICBQaG9uZTogKzEgNTEyLTgzOC0wMDg4ICANCiAgIEVtYWlsOiBkYXJyb3lv QHVzLmlibS5jb20gDQogICAgDQogICBVcmkgQmx1bWVudGhhbCANCiAgIEludGVsIENvcnBvcmF0 aW9uIA0KICAgMTUxNSBSb3V0ZSAxMCwgDQogICBQYXJzaXBwYW55LCBOSiAwNzA1NCANCiAgIFBo b25lOiArMSA5NzMtOTY3LTY0NDYgDQogICBFbWFpbDogdXJpLmJsdW1lbnRoYWxAaW50ZWwuY29t IA0KICAgIA0KICAgU3RldmUgSGFubmEgDQogICBKdW5pcGVyIE5ldHdvcmtzLCBJbmMuIA0KICAg MzUgRm9yZXN0IFJpZGdlIFJvYWQgDQogICBDb25jb3JkLCBNQSAwMTc0MiANCiAgIFBob25lOiAr MSA5NzgtMzcxLTM5ODAgDQogICBFbWFpbDogc2hhbm5hQGp1bmlwZXIubmV0IA0KICAgIA0KICAg VGhvbWFzIEhhcmRqb25vIA0KDQoNCiAgDQpLaG9zcmF2aSwgZXQuIGFsLiAgICAgICBFeHBpcmVz IE5vdmVtYmVyIDIwMDYgICAgICAgICAgICAgICBbUGFnZSAxNV0NCg0KDQoNCkludGVybmV0IERy YWZ0ICAgICAgICAgICAgIE5FQSBSZXF1aXJlbWVudHMgICAgICAgICAgICAgICAgIE1heSAyMDA2 IA0KICAgU2lnbmFDZXJ0LCBJbmMuIA0KICAgNzA3IFNXIFdhc2hpbmd0b24gU3QuL1N1aXRlIDcw MCwgIA0KICAgUG9ydGxhbmQsIE9SIDk3MjA1IA0KICAgUGhvbmU6ICsxIDUwMy0yMjctMjIwNyAN CiAgIEVtYWlsOiB0aGFyZGpvbm9Ac2lnbmFjZXJ0LmNvbSANCiAgICANCiAgIFJhdmkgU2FoaXRh IA0KICAgSW50ZWwgQ29ycG9yYXRpb24gDQogICAyMTExIE5FIDI1dGggQXZlIA0KICAgSGlsbHNi b3JvIE9SIDk3MTI0IA0KICAgRW1haWw6IFJhdmkuc2FoaXRhQGludGVsLmNvbSANCiAgICANCiAg IE1hdXJpY2lvIFNhbmNoZXogDQogICBFbWFpbDogbWF1cmljaW8uc2FuY2hlekBocC5jb20gDQog ICAgDQogICBKZWZmIFNpeCANCiAgIEVtYWlsOiBqZWZmc2l4QHRoZW1hdHJpeC5uY3NjLm1pbCAN CiAgICANCiAgIEpvc2VwaCBUYXJkbyANCiAgIE5ldmlzIE5ldHdvcmtzIA0KICAgNTAwIE4uIEJl cm5hcmRvIEF2ZS4gDQogICBNb3VudGFpbiBWaWV3LCBDQSA5NDA0MyANCiAgIEVtYWlsOiBqb3Nl cGgudGFyZG9AbmV2aXNuZXR3b3Jrcy5jb20gDQogICAgDQogICBTdXNhbiBUaG9tc29uIA0KICAg Q2lzY28gU3lzdGVtcyANCiAgIDQ5OSBUaG9ybmFsbCBTdHJlZXQsIDh0aCBmbG9vciANCiAgIEVk aXNvbiwgTkogIDA4ODM3IA0KICAgVS5TLkEgDQogICBFbWFpbDogc2V0aG9tc29AY2lzY28uY29t IA0KICAgIA0KICAgSm9obiBWb2xsYnJlY2h0IA0KICAgOTY4MiBBbGljZSBIaWxsIERyaXZlIA0K ICAgRGV4dGVyLCBNaS4gNDgxMzAgDQogICBFbWFpbDoganJ2QG1lcml0LmVkdSANCiAgICANCiAg IEhhbyBaaG91IA0KICAgQ2lzY28gU3lzdGVtcyANCiAgIDQxMjUgSGlnaGxhbmRlciBQYXJrd2F5 IA0KICAgUmljaGZpZWxkLCBPSCAgNDQyODYgDQogICBVLlMuQS4gDQogICBFbWFpbDogaHpob3VA Y2lzY28uY29tIA0KICAgIA0KICAgQ29weXJpZ2h0IFN0YXRlbWVudCANCiAgICANCiAgIENvcHly aWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKDIwMDYpLiAgVGhpcyBkb2N1bWVudCBpcyBz dWJqZWN0IA0KICAgdG8gdGhlIHJpZ2h0cywgbGljZW5zZXMgYW5kIHJlc3RyaWN0aW9ucyBjb250 YWluZWQgaW4gQkNQIDc4LCBhbmQgDQogICBleGNlcHQgYXMgc2V0IGZvcnRoIHRoZXJlaW4sIHRo ZSBhdXRob3JzIHJldGFpbiBhbGwgdGhlaXIgcmlnaHRzLiANCiAgICANCg0KDQoNCiAgDQpLaG9z cmF2aSwgZXQuIGFsLiAgICAgICBFeHBpcmVzIE5vdmVtYmVyIDIwMDYgICAgICAgICAgICAgICBb UGFnZSAxNl0NCg0KDQoNCkludGVybmV0IERyYWZ0ICAgICAgICAgICAgIE5FQSBSZXF1aXJlbWVu dHMgICAgICAgICAgICAgICAgIE1heSAyMDA2IA0KICAgVGhpcyBkb2N1bWVudCBhbmQgdGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gYXJlIHByb3ZpZGVkIG9uIA0KICAgYW4gIkFTIElT IiBiYXNpcyBhbmQgVEhFIENPTlRSSUJVVE9SLCBUSEUgT1JHQU5JWkFUSU9OIEhFL1NIRSANCiAg IFJFUFJFU0VOVFMgT1IgSVMgU1BPTlNPUkVEIEJZIChJRiBBTlkpLCBUSEUgSU5URVJORVQgU09D SUVUWSBBTkQgVEhFIA0KICAgSU5URVJORVQgRU5HSU5FRVJJTkcgVEFTSyBGT1JDRSBESVNDTEFJ TSBBTEwgV0FSUkFOVElFUywgRVhQUkVTUyBPUiANCiAgIElNUExJRUQsIElOQ0xVRElORyBCVVQg Tk9UIExJTUlURUQgVE8gQU5ZIFdBUlJBTlRZIFRIQVQgVEhFIFVTRSBPRiANCiAgIFRIRSBJTkZP Uk1BVElPTiBIRVJFSU4gV0lMTCBOT1QgSU5GUklOR0UgQU5ZIFJJR0hUUyBPUiBBTlkgSU1QTElF RCANCiAgIFdBUlJBTlRJRVMgT0YgTUVSQ0hBTlRBQklMSVRZIE9SIEZJVE5FU1MgRk9SIEEgUEFS VElDVUxBUiBQVVJQT1NFLiANCiAgICANCiAgICANCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN Cg0KICANCktob3NyYXZpLCBldC4gYWwuICAgICAgIEV4cGlyZXMgTm92ZW1iZXIgMjAwNiAgICAg ICAgICAgICAgIFtQYWdlIDE3XQ== ------_=_NextPart_001_01C67E07.CCAF5EA6 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea ------_=_NextPart_001_01C67E07.CCAF5EA6-- From nea-bounces@ietf.org Tue May 23 21:12:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fihv2-0002hC-PZ; Tue, 23 May 2006 21:12:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fihv1-0002gq-G4 for nea@ietf.org; Tue, 23 May 2006 21:12:11 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fihuz-00070L-Bq for nea@ietf.org; Tue, 23 May 2006 21:12:11 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4O1C8Gw022972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 23 May 2006 18:12:08 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4O1C7A6004200; Tue, 23 May 2006 18:12:07 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 May 2006 18:12:06 -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] Revised draft NEA charter Date: Tue, 23 May 2006 18:12:06 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB848831BB@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Revised draft NEA charter Thread-Index: AcZ5/TK96YKZLzFqSlWmAS+rsP1glQAI0qrgAFkpUOAAmPKskA== From: "Narayanan, Vidya" To: "Stephen Hanna" , X-OriginalArrivalTime: 24 May 2006 01:12:06.0980 (UTC) FILETIME=[13104040:01C67ECF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 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, An opening disclaimer - I am not really speaking from a service provider perspective. I'm listing some general concerns I have about this work - some may be workable in the case of enterprise environments, but would be very concerning in the cellular world.=20 I have the following general comments on the NEA work:=20 1. NEA seems to have applicability in determining the health (i.e., posture) of "well-behaved (or non-compromised)" endpoints in the system. I am not yet convinced that this is broad enough of a problem that warrants the complexity of implementing this for various applications. However, looking beyond this concern, some more comments below.=20 2. The motivation for tying NEA to network access is not very clear to me. Given that we aren't talking about compromised devices, why would tying NEA operation to network access make sense? Also, the PS draft talks about potentially having to perform NEA again if the state changes or if policies requires a re-validation. If tied to network access, does this mean re-authentication? The impact of adding more operations at the time of network access could be quite undesirable.=20 3. The need to carry posture data in EAP methods concerns me. This implies that in order to perform NEA, a particular EAP method needs to be used. I realize that the goal is to specify the use of tunneled TLS-based methods (like TTLS or PEAP?), so that the actual protocol used for client authentication could still be different (e.g., CHAP). However, even that is a restriction, since it limits the use to a tunneled TLS method. The cellular world is going a different direction with EAP-AKA and I'm not sure that NEA would be a reason to switch to a tunneled TLS method. Even in the enterprise world, many wired deployments don't really use 802.1x - a Kerberos-based authentication is often viewed as being sufficient here. Also, some enterprise WLAN deployments end up using VPN-style security, rather than relying on 802.11i. So, the tie to EAP-based access does not seem to be a universal solution at all here.=20 At this point, I am refraining from getting into more detailed comments. At a minimum, I'd like the charter to clearly state the fact that this work does not deal with device compromises and the impact of that. Also, I personally think that de-coupling the NEA operation from network access is needed to make this work somewhat more useful.=20 Regards, Vidya > -----Original Message----- > From: Stephen Hanna [mailto:shanna@juniper.net]=20 > Sent: Friday, May 19, 2006 1:50 PM > To: Narayanan, Vidya; nea@ietf.org > Subject: RE: [Nea] Revised draft NEA charter >=20 > I don't think the NEA work needs to be restricted to=20 > enterprise environments. As the problem statement says,=20 > "Network assessment architectures have been targeted=20 > primarily at enterprise deployment scenarios to date." That's=20 > true of the past but I don't think it needs to be the case in=20 > the future. >=20 > Could you review the charter and documents from a=20 > non-enterprise point of view (service provider, I presume?)=20 > and point out any deficiencies? >=20 > Thanks, >=20 > Steve >=20 > > -----Original Message----- > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > Sent: Wednesday, May 17, 2006 10:14 PM > > To: Stephen Hanna; nea@ietf.org > > Subject: RE: [Nea] Revised draft NEA charter > >=20 > > A high level question - is the work solely targeting enterprise=20 > > environments? The problem statement alludes to this, but,=20 > this is not=20 > > clear from the charter. > >=20 > > Thanks, > > Vidya > >=20 > > > -----Original Message----- > > > From: Stephen Hanna [mailto:shanna@juniper.net] > > > Sent: Wednesday, May 17, 2006 3:00 PM > > > To: nea@ietf.org > > > Subject: [Nea] Revised draft NEA charter > > >=20 > > > Folks, > > >=20 > > > Susan and I have revised the draft NEA WG charter to reflect the=20 > > > consensus of the mailing list as reflected in the NEA Action Plan=20 > > > agreed to in April. > > >=20 > > > Please review this draft and send feedback ASAP. Of=20 > course, we can=20 > > > revise the charter up to Montreal but I'd like to get a solid=20 > > > version by Friday so we can submit our BOF proposal on=20 > Monday as the=20 > > > IESG has requested. > > >=20 > > > Thanks, > > >=20 > > > Steve > > >=20 > > > ------------- > > >=20 > > > Draft NEA WG Charter > > > May 17, 2006 Version > > >=20 > > > Network Endpoint Assessment (NEA) architectures have been=20 > > > implemented in the industry to assess the "posture" of endpoint=20 > > > devices for the purposes of monitoring or enforcing=20 > compliance to an=20 > > > organization's policy for access to the network. Posture=20 > refers to=20 > > > the hardware or software configuration of an endpoint as=20 > it pertains=20 > > > to an organization's security policy. Posture may include=20 > knowledge=20 > > > about the types of hardware and software installed and their=20 > > > configurations, e.g. > > > OS name and version, application patch levels, and anti-virus=20 > > > signature file version. On network access, an endpoint=20 > with an NEA=20 > > > Client can be queried for posture information which is=20 > validated on=20 > > > an NEA Server as part of network access control. > > >=20 > > > Since NEA involves many different components from=20 > different vendors,=20 > > > interoperation between NEA architectures and implementations is=20 > > > highly desirable. Given that well-established protocols already=20 > > > exist for the lowest layers in the NEA architectures (such as EAP=20 > > > and RADIUS), the priority of the NEA working group is to=20 > standardize=20 > > > protocols at the higher layers in the architectures=20 > (known as PA and=20 > > > PB and described later). When used with the existing=20 > standards for=20 > > > lower layers, these new protocols will allow interoperability=20 > > > between an NEA Client from one vendor and an NEA Server from=20 > > > another. > > >=20 > > > Since there are already several existing protocols at=20 > these higher=20 > > > layers, the NEA working group will consider these=20 > existing protocols=20 > > > as candidates for standardization. A requirements=20 > document will be=20 > > > written and used as a basis for evaluating the candidate=20 > protocols.=20 > > > The working group may decide to standardize one of the candidate=20 > > > protocols, use one of them as a basis for a new or=20 > revised protocol,=20 > > > or decide that a new protocol is needed. > > >=20 > > > The NEA Requirements document will include a problem statement,=20 > > > definition of terms, requirements for PA, PB, and an overall=20 > > > security analysis. It will also include requirements for the=20 > > > protocol transporting PA, PB (known as PTT and described below). > > >=20 > > > PA, the Posture Attribute protocol, consists of posture=20 > attributes=20 > > > that are carried between a particular Posture Collector in a NEA=20 > > > client and a particular Posture Validator in a NEA Server. The PA=20 > > > protocol is carried inside the PB protocol. Certain posture=20 > > > attributes will be standardized to ensure interoperability but=20 > > > vendor-specific attributes will also be supported. > > >=20 > > > PB, the Posture Broker protocol, aggregates posture=20 > attributes from=20 > > > one or more Posture Collectors in an NEA client and sends them to=20 > > > the NEA server for assessment by one or more Posture Validators. > > >=20 > > > PTT, the Posture Transport Tunnel protocol is a transport=20 > protocol=20 > > > suitable for carrying the PB protocol at or after network=20 > > > connection. > > >=20 > > > Milestones: > > >=20 > > > June 2006: > > > * Submit first version of NEA Requirements I-D > > >=20 > > > July 2006: > > > * Agree on charter and milestones at IETF 66 > > >=20 > > > September 2006: > > > * WG Last Call on NEA Requirements I-D > > >=20 > > > October 2006: > > > * Deadline for submission of candidate specs for PA and PB > > > * Submit first version of NEA Evaluation I-D > > >=20 > > > November 2006: > > > * Review NEA Evaluation I-D at IETF 67 > > >=20 > > > December 2006: > > > * WG Last Call on NEA Evaluation I-D > > >=20 > > > January 2007: > > > * Submit NEA Requirements I-D and Evaluation I-D to IESG=20 > as Info RFC > > > * Submit first draft of PA and PB specs for review > > >=20 > > > March 2007: > > > * Discuss unresolved issues with PA and PB specs at IETF 68 > > > * Agree on solutions to unresolved issues with PA and PB specs > > >=20 > > > April 2007: > > > * Submit revised draft of PA and PB specs > > >=20 > > > June 2007 > > > * WG Last Call on PA and PB specs > > >=20 > > > July 2007 > > > * Resolve outstanding Last Call comments on requirements=20 > I-D at IETF=20 > > > 69 > > >=20 > > > August 2007: > > > * Submit PA and PB specs to IESG for publication as Proposed > > >=20 > > > _______________________________________________ > > > Nea mailing list > > > Nea@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nea > > >=20 > >=20 >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed May 24 07:19:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FirP5-0004r6-5A; Wed, 24 May 2006 07:19:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FirP3-0004r1-C8 for nea@ietf.org; Wed, 24 May 2006 07:19:49 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FirP2-0000Pk-1k for nea@ietf.org; Wed, 24 May 2006 07:19:49 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 24 May 2006 04:19:47 -0700 X-IronPort-AV: i="4.05,165,1146466800"; d="scan'208"; a="548902856:sNHT32493908" 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] Revised draft NEA charter Date: Wed, 24 May 2006 07:19:51 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Revised draft NEA charter Thread-Index: AcZ5/TK96YKZLzFqSlWmAS+rsP1glQAI0qrgAFkpUOAAmPKskAA6myzgAAVgzCAADR928A== From: "Stephen Hanna" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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 Thanks for your questions and comments on the NEA charter. I'm glad to have your participation and feedback. I will address your comments inline. > 1. NEA seems to have applicability in determining the health (i.e., > posture) of "well-behaved (or non-compromised)" endpoints in=20 > the system. > I am not yet convinced that this is broad enough of a problem that > warrants the complexity of implementing this for various applications. > However, looking beyond this concern, some more comments below. Many customers find NEA systems worthwhile as a way of increasing the health of their endpoints. Also, when combined with trusted hardware and other techniques, NEA can be effective in detecting compromised endpoints. As with all security, nothing is perfect. But in many cases, NEA is a good layer of protection. > 2. The motivation for tying NEA to network access is not very clear to > me. Given that we aren't talking about compromised devices, why would > tying NEA operation to network access make sense? Also, the PS draft > talks about potentially having to perform NEA again if the=20 > state changes > or if policies requires a re-validation. If tied to network=20 > access, does > this mean re-authentication? The impact of adding more=20 > operations at the > time of network access could be quite undesirable.=20 NEA can be done at or after network access. That's why the latest version of the charter says: PT, the Posture Transport protocol, is a protocol (or stack of protocols) suitable for carrying the PB protocol at or after network connection. Notice the "or after" part. Also, the requirements document says: 2. NEA protocols MUST allow the NEA server to initiate requests for=20 posture information prior to network access and at any time after=20 the client has established an identity on the network (e.g. IP=20 address.) This enables the NEA server to evaluate posture prior to=20 allowing access and to periodically re-validate systems already=20 admitted to the network to assure they are still in compliance with=20 the current policies. Re-validation after an IP address has been assigned would typically (but not necessarily) be done via a layer 3 protocol, thus avoiding the need to disrupt network access during the re-validation. > 3. The need to carry posture data in EAP methods concerns me. This > implies that in order to perform NEA, a particular EAP method needs to > be used. I realize that the goal is to specify the use of tunneled > TLS-based methods (like TTLS or PEAP?), so that the actual=20 > protocol used > for client authentication could still be different (e.g., CHAP). > However, even that is a restriction, since it limits the use to a > tunneled TLS method. The cellular world is going a different direction > with EAP-AKA and I'm not sure that NEA would be a reason to=20 > switch to a > tunneled TLS method. Even in the enterprise world, many wired > deployments don't really use 802.1x - a Kerberos-based=20 > authentication is > often viewed as being sufficient here. Also, some enterprise WLAN > deployments end up using VPN-style security, rather than relying on > 802.11i. So, the tie to EAP-based access does not seem to be=20 > a universal > solution at all here. NEA is not restricted to EAP and certainly not just to 802.1x. That's why it's important for PA and PB to be transport independent. There are many ways to do NEA. EAP and 802.1x is just one. > At this point, I am refraining from getting into more=20 > detailed comments. > At a minimum, I'd like the charter to clearly state the fact that this > work does not deal with device compromises and the impact of=20 > that. Also, > I personally think that de-coupling the NEA operation from network > access is needed to make this work somewhat more useful.=20 The requirements document includes a discussion of device compromise in its security considerations section (8.1). Maybe we will need to include something about this in the charter. What do others think? As for de-coupling NEA from network access, that's already part of the plan (as described above). Maybe we need to make the charter clearer on this point. Thanks again for your comments. I'm glad we're getting a service provider perspective on this. Take care, Steve _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed May 24 13:13:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiwvA-0005xP-H4; Wed, 24 May 2006 13:13:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fiwv9-0005wY-8y for nea@ietf.org; Wed, 24 May 2006 13:13:19 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fiwv7-00020J-UE for nea@ietf.org; Wed, 24 May 2006 13:13:19 -0400 Received: from [10.20.30.249] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k4OHDErK016791 for ; Wed, 24 May 2006 10:13:14 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 24 May 2006 10:13:08 -0700 To: nea@ietf.org From: Paul Hoffman Subject: RE: [Nea] Revised draft NEA charter Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 7:19 AM -0400 5/24/06, Stephen Hanna wrote: > > At a minimum, I'd like the charter to clearly state the fact that this >> work does not deal with device compromises and the impact of >> that. Also, >> I personally think that de-coupling the NEA operation from network >> access is needed to make this work somewhat more useful. > >The requirements document includes a discussion of device >compromise in its security considerations section (8.1). >Maybe we will need to include something about this in the >charter. What do others think? Yes, we need that in the charter. It was generally agreed to at the BoF, and it is somewhat unexpected for many NAC users. >As for de-coupling NEA from network access, that's already >part of the plan (as described above). Maybe we need to >make the charter clearer on this point. Yup. Again, many NAC users would expect that an IETF group would expect that they would be coupled. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed May 24 23:41:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj6jV-0000J9-K0; Wed, 24 May 2006 23:41:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj6jT-0000J1-VH for nea@ietf.org; Wed, 24 May 2006 23:41:55 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fj6jR-0008B7-4h for nea@ietf.org; Wed, 24 May 2006 23:41:55 -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 k4P3flwW007736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 24 May 2006 20:41:47 -0700 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4P3fktL026379; Wed, 24 May 2006 20:41:47 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 May 2006 20:41:46 -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] Revised draft NEA charter Date: Wed, 24 May 2006 20:41:45 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB8490B180@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Revised draft NEA charter Thread-Index: AcZ5/TK96YKZLzFqSlWmAS+rsP1glQAI0qrgAFkpUOAAmPKskAA6myzgAAVgzCAADR928AAhvgxg From: "Narayanan, Vidya" To: "Stephen Hanna" X-OriginalArrivalTime: 25 May 2006 03:41:46.0699 (UTC) FILETIME=[25CE61B0:01C67FAD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 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 Please see comments inline. =20 >=20 > Thanks for your questions and comments on the NEA charter. > I'm glad to have your participation and feedback. I will=20 > address your comments inline. >=20 > > 1. NEA seems to have applicability in determining the health (i.e., > > posture) of "well-behaved (or non-compromised)" endpoints in the=20 > > system. > > I am not yet convinced that this is broad enough of a problem that=20 > > warrants the complexity of implementing this for various=20 > applications. > > However, looking beyond this concern, some more comments below. >=20 > Many customers find NEA systems worthwhile as a way of=20 > increasing the health of their endpoints. Also, when combined=20 > with trusted hardware and other techniques, NEA can be=20 > effective in detecting compromised endpoints. As with all=20 > security, nothing is perfect. > But in many cases, NEA is a good layer of protection. I don't see how NEA can detect compromised endpoints even with trusted hardware - with trusted hardware storing the attributes, it just means that a compromised device may not be able to tweak the attributes (I'm not even totally convinced of this at the moment, but let's say that). =20 > > 2. The motivation for tying NEA to network access is not=20 > very clear to=20 > > me. Given that we aren't talking about compromised devices,=20 > why would=20 > > tying NEA operation to network access make sense? Also, the=20 > PS draft=20 > > talks about potentially having to perform NEA again if the state=20 > > changes or if policies requires a re-validation. If tied to network=20 > > access, does this mean re-authentication? The impact of adding more=20 > > operations at the time of network access could be quite undesirable. >=20 > NEA can be done at or after network access. That's why the=20 > latest version of the charter says: >=20 > PT, the Posture Transport protocol, is a protocol (or stack of > protocols) suitable for carrying the PB protocol at or after > network connection. >=20 > Notice the "or after" part. Also, the requirements document says: >=20 > 2. NEA protocols MUST allow the NEA server to initiate=20 > requests for=20 > posture information prior to network access and at any time after=20 > the client has established an identity on the network (e.g. IP=20 > address.) This enables the NEA server to evaluate posture=20 > prior to=20 > allowing access and to periodically re-validate systems already=20 > admitted to the network to assure they are still in=20 > compliance with=20 > the current policies. >=20 > Re-validation after an IP address has been assigned would=20 > typically (but not necessarily) be done via a layer 3=20 > protocol, thus avoiding the need to disrupt network access=20 > during the re-validation. >=20 Having said this, what is the result of posture validation? The analogy I am able to make in my mind is something like a virus or application patch update/notification process - is that what is being standardized?=20 > > 3. The need to carry posture data in EAP methods concerns me. This=20 > > implies that in order to perform NEA, a particular EAP=20 > method needs to=20 > > be used. I realize that the goal is to specify the use of tunneled=20 > > TLS-based methods (like TTLS or PEAP?), so that the actual protocol=20 > > used for client authentication could still be different=20 > (e.g., CHAP). > > However, even that is a restriction, since it limits the use to a=20 > > tunneled TLS method. The cellular world is going a=20 > different direction=20 > > with EAP-AKA and I'm not sure that NEA would be a reason to=20 > switch to=20 > > a tunneled TLS method. Even in the enterprise world, many wired=20 > > deployments don't really use 802.1x - a Kerberos-based=20 > authentication=20 > > is often viewed as being sufficient here. Also, some=20 > enterprise WLAN=20 > > deployments end up using VPN-style security, rather than relying on=20 > > 802.11i. So, the tie to EAP-based access does not seem to be a=20 > > universal solution at all here. >=20 > NEA is not restricted to EAP and certainly not just to 802.1x. > That's why it's important for PA and PB to be transport independent. > There are many ways to do NEA. EAP and 802.1x is just one. >=20 The charter says "It will also include requirements for the protocol transporting PA, PB: the Posture Transport protocol (PT). Specific requirements for an EAP instantiation of PT will be identified." - this seems to imply that the primary protocol intended to carry PA and PB is an EAP method. Or, am I missing something?=20 > > At this point, I am refraining from getting into more detailed=20 > > comments. > > At a minimum, I'd like the charter to clearly state the=20 > fact that this=20 > > work does not deal with device compromises and the impact of that.=20 > > Also, I personally think that de-coupling the NEA operation from=20 > > network access is needed to make this work somewhat more useful. >=20 > The requirements document includes a discussion of device=20 > compromise in its security considerations section (8.1). > Maybe we will need to include something about this in the=20 > charter. What do others think? >=20 I believe the charter should clarify this.=20 > As for de-coupling NEA from network access, that's already=20 > part of the plan (as described above). Maybe we need to make=20 > the charter clearer on this point. >=20 Aside from the confusions mentioned above, when it is de-coupled from network access, it is not clear to me as to where the transport protocol is going to be specified.=20 > Thanks again for your comments. I'm glad we're getting a=20 > service provider perspective on this. >=20 Perhaps you missed my disclaimer that explicitly said this is not a service provider perspective? :) I don't work for an SP and never have. In fact, I worked for years in the government enterprise space and have been in the cellular world for only a few months - so, anything I've said is an individual opinion keeping both of those use cases in mind.=20 Regards, Vidya > Take care, >=20 > Steve >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu May 25 01:02:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj7zF-00025M-9C; Thu, 25 May 2006 01:02:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fj7zE-0001za-Qp for nea@ietf.org; Thu, 25 May 2006 01:02:16 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fj7Jv-0002fP-19 for nea@ietf.org; Thu, 25 May 2006 00:19:35 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fj78G-0003B5-Rx for nea@ietf.org; Thu, 25 May 2006 00:07:35 -0400 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k4P47OS27235; Thu, 25 May 2006 00:07:25 -0400 (EDT) Received: from [47.248.126.240] ([47.248.126.240] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 25 May 2006 00:07:05 -0400 Message-ID: <44752D70.4080602@nortel.com> Date: Thu, 25 May 2006 00:07:12 -0400 From: "Marcus Leech" User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: "Narayanan, Vidya" Subject: Re: [Nea] Revised draft NEA charter References: <2EBB8025B6D1BA41B567DB32C1D8DB8490B180@NAEX06.na.qualcomm.com> In-Reply-To: <2EBB8025B6D1BA41B567DB32C1D8DB8490B180@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 May 2006 04:07:05.0192 (UTC) FILETIME=[AEE60680:01C67FB0] X-Spam-Score: -2.6 (--) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac 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 Narayanan, Vidya wrote: > I don't see how NEA can detect compromised endpoints even with trusted > hardware - with trusted hardware storing the attributes, it just means > that a compromised device may not be able to tweak the attributes (I'm > not even totally convinced of this at the moment, but let's say that). Indeed. The "trusted hardware" in this case acts as a kind of notary function. It attests to things that it can't effectively test the essential truth of. A compromised machine can hand the "trusted hardware" any arbitrary nonsense that is otherwise "believable" by the trusted hardware, and it will duly notarize it. Even if the so-called "trusted" hardware encompassed the entire machine, trusting anything it had to say about its state would involve believing that all software is perfect. It also involves removing any kind of "turing completeness" from the endpoint. Which might be useful perhaps for cellphones, but certainly not general purpose computing platforms. Here's a simplified example. I assert that I'm Marcus Leech, of Nortel Networks. My e-mail system, in some very loose sense, attests to that "fact". But you have no way of independently verifying the essential "truth" of my assertion, at least not from the position of somebody reading this e-mail. You could, of course, move on to query our HR department, locate my peers inside Nortel, and query *them* about who they think I am. You'd get close to being able to believe in my assertion about myself. Now, we move on to a Turing-Complete computing environment, in which we ask for a believable assertion about the state of its sanity. If the environment was, in fact, insane (compromised), and we ask it "are you sane?", there's no way we can trust the answer. If, on the other hand, the environment *isn't* insane (not compromised), then the value of the answer you get back is of questionable utility. The TPM can't fix this. While it may hold the signing keys, etc, very close to its chest, it is ultimately at the mercy of the machine and software environment that is its host. For any general-purpose computing environment, the TPM can't really trust anything it's being told, and it will blindly notarize any damned-foolish thing it's handed by the host. There's the whole "TPM-mediated secure boot sequence" kool-aid, which is supposed to allow you to have the machine be in a predictable state after boot. What that says about the state of the machine at time bootime+N, is another (unsolvable) matter entirely. Does any of this stuff actually help against machine compromise? It certainly makes the writing of malware somewhat harder. But it only takes 1 clever hacker to build a "generic TPM-circumvention engine", and every piece of malware on the planet will have that engine within weeks. The question, then, is *how long will it take*, and is that time sufficiently long that the investment in TCG/NEA/NAC/NAP/TCPA will all have been worth it? There are lots of folks who believe that that time *will* be sufficiently long. I rather have my personal doubts. But in the general spirit of throwing down thumb-tacks, and oil-slicks to prevent the bad guy from gaining on you, I'm willing to see what happens... _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu May 25 10:28:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjGp3-0005TL-9E; Thu, 25 May 2006 10:28:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjGp2-0005TG-Ua for nea@ietf.org; Thu, 25 May 2006 10:28:20 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjGp1-0005a1-KY for nea@ietf.org; Thu, 25 May 2006 10:28:20 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 25 May 2006 07:28:19 -0700 X-IronPort-AV: i="4.05,173,1146466800"; d="scan'208"; a="549196961:sNHT34197948" 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] Revised draft NEA charter Date: Thu, 25 May 2006 10:28:24 -0400 Message-ID: In-Reply-To: <2EBB8025B6D1BA41B567DB32C1D8DB8490B180@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Revised draft NEA charter Thread-Index: AcZ5/TK96YKZLzFqSlWmAS+rsP1glQAI0qrgAFkpUOAAmPKskAA6myzgAAVgzCAADR928AAhvgxgABQPjXA= From: "Stephen Hanna" To: "Narayanan, Vidya" X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 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 Vidya, Sorry I mischaracterized your comments as coming from a service provider perspective. Whatever the perspective, I appreciate them. > I don't see how NEA can detect compromised endpoints even with trusted > hardware - with trusted hardware storing the attributes, it just means > that a compromised device may not be able to tweak the attributes (I'm > not even totally convinced of this at the moment, but let's=20 > say that). This is a big discussion. I'll start a separate thread for it. > > Re-validation after an IP address has been assigned would=20 > > typically (but not necessarily) be done via a layer 3=20 > > protocol, thus avoiding the need to disrupt network access=20 > > during the re-validation. > >=20 >=20 > Having said this, what is the result of posture validation?=20 > The analogy > I am able to make in my mind is something like a virus or application > patch update/notification process - is that what is being=20 > standardized?=20 The results of posture validation can include remediation or restrictions on network access. For validation some time after network access has already been granted, restricting network access may use RADIUS CoA message, for example. Remediation is the process of fixing problems with the endpoint, manually or automatically. It can include installing patches or updates to the operating system, applications, or virus definitions. That's common. It can also include changes to configuration settings on the endpoint (like enabling the firewall) and other things like doing a virus scan. The current NEA charter does not propose to standardize what happens after posture validation. It's focused on the protocols for posture validation itself. > The charter says "It will also include requirements for the protocol > transporting PA, PB: the Posture Transport protocol (PT). Specific > requirements for an EAP instantiation of PT will be=20 > identified." - this > seems to imply that the primary protocol intended to carry PA=20 > and PB is > an EAP method. Or, am I missing something?=20 That darn sentence has been causing all sorts of trouble! ;-) The NEA charter is supposed to be transport independent. But people are definitely interested in EAP. It's a very popular transport, supported by all the major NAC architectures but in incompatible ways. So it was suggested that we should include specific requirements for EAP so that the EMU group or someone else could work on a standard transport for NEA if they want to at some later time. Maybe the sentence should be changed to something like this: Specific requirements for an EAP instantiation of PT will be identified in case standardization in that area is desired. However, standardization of an EAP instantiation is not in scope for the NEA working group. > > The requirements document includes a discussion of device=20 > > compromise in its security considerations section (8.1). > > Maybe we will need to include something about this in the=20 > > charter. What do others think? >=20 > I believe the charter should clarify this.=20 We seem to have consensus on this. Let's add a paragraph on this topic to the charter once we agree on what it should say. ;-) > > As for de-coupling NEA from network access, that's already=20 > > part of the plan (as described above). Maybe we need to make=20 > > the charter clearer on this point. > >=20 >=20 > Aside from the confusions mentioned above, when it is de-coupled from > network access, it is not clear to me as to where the=20 > transport protocol > is going to be specified.=20 There are other working groups better suited for such work. For instance, an EAP method should probably go through the EAP or EMU working groups. I don't think our charter should call out work for other working groups. That got us into trouble last time. I hope the text on this that I proposed above will help clarify it. Thanks, Steve _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu May 25 12:21:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjIau-00073n-QV; Thu, 25 May 2006 12:21:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjIat-00073h-Vi for nea@ietf.org; Thu, 25 May 2006 12:21:51 -0400 Received: from mail.signacert.com ([207.162.214.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjIar-0006lf-H9 for nea@ietf.org; Thu, 25 May 2006 12:21:51 -0400 Received: from SLEDGEHAMMER.signacert.com (sledgehammer.signacert.com [70.103.105.28]) by mail.signacert.com (Postfix) with ESMTP id CEE9718EC42B; Thu, 25 May 2006 09:21:44 -0700 (PDT) Content-class: urn:content-classes:message Subject: Background Book on Trusted Computing -- RE: [Nea] Revised draft NEA charter MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 May 2006 09:21:42 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Message-ID: <6874726B1AE3D441A3B4635B527E09B106A379@sledgehammer.signacert.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Background Book on Trusted Computing -- RE: [Nea] Revised draft NEA charter Thread-Index: AcZ5/TK96YKZLzFqSlWmAS+rsP1glQAI0qrgAFkpUOAAmPKskAA6myzgAAVgzCAADR928AAhvgxgABQPjXAACHBQIA== From: "Thomas Hardjono" To: "Stephen Hanna" , "Narayanan, Vidya" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 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 Vidya,=20 After the NEA BOF in Dallas I received similar questions (including from Marcus) about the TPM, trusted hardware roles, and Trusted Computing. Trusted Computing is a reasonably new field and still work-in-progress. Trying to explain the TPM hardware, functions, its uses in platforms etc is a very involved process. (ps. The best presentation I have seen was 6-hour long:) I would like to recommend the book by the HP folks on trusted computing as background reading: Trusted Computing Platforms: TCPA Technology in Context (Hardcover) by Siani Pearson et al. http://www.amazon.com/gp/product/0130092207/sr=3D8-1/qid=3D1148573971/ref= =3Dpd _bbs_1/102-1837598-2810552?%5Fencoding=3DUTF8 Regards. /thomas/ -----Original Message----- From: Stephen Hanna [mailto:shanna@juniper.net]=20 Sent: Thursday, May 25, 2006 7:28 AM To: Narayanan, Vidya Cc: nea@ietf.org Subject: RE: [Nea] Revised draft NEA charter Vidya, Sorry I mischaracterized your comments as coming from a service provider perspective. Whatever the perspective, I appreciate them. > I don't see how NEA can detect compromised endpoints even with trusted > hardware - with trusted hardware storing the attributes, it just means > that a compromised device may not be able to tweak the attributes (I'm > not even totally convinced of this at the moment, but let's say that). This is a big discussion. I'll start a separate thread for it. > > Re-validation after an IP address has been assigned would typically=20 > > (but not necessarily) be done via a layer 3 protocol, thus avoiding=20 > > the need to disrupt network access during the re-validation. > >=20 >=20 > Having said this, what is the result of posture validation?=20 > The analogy > I am able to make in my mind is something like a virus or application=20 > patch update/notification process - is that what is being=20 > standardized? The results of posture validation can include remediation or restrictions on network access. For validation some time after network access has already been granted, restricting network access may use RADIUS CoA message, for example. Remediation is the process of fixing problems with the endpoint, manually or automatically. It can include installing patches or updates to the operating system, applications, or virus definitions. That's common. It can also include changes to configuration settings on the endpoint (like enabling the firewall) and other things like doing a virus scan. The current NEA charter does not propose to standardize what happens after posture validation. It's focused on the protocols for posture validation itself. > The charter says "It will also include requirements for the protocol=20 > transporting PA, PB: the Posture Transport protocol (PT). Specific=20 > requirements for an EAP instantiation of PT will be identified." -=20 > this seems to imply that the primary protocol intended to carry PA and > PB is an EAP method. Or, am I missing something? That darn sentence has been causing all sorts of trouble! ;-) The NEA charter is supposed to be transport independent. But people are definitely interested in EAP. It's a very popular transport, supported by all the major NAC architectures but in incompatible ways. So it was suggested that we should include specific requirements for EAP so that the EMU group or someone else could work on a standard transport for NEA if they want to at some later time. Maybe the sentence should be changed to something like this: Specific requirements for an EAP instantiation of PT will be identified in case standardization in that area is desired. However, standardization of an EAP instantiation is not in scope for the NEA working group. > > The requirements document includes a discussion of device compromise > > in its security considerations section (8.1). > > Maybe we will need to include something about this in the charter.=20 > > What do others think? >=20 > I believe the charter should clarify this.=20 We seem to have consensus on this. Let's add a paragraph on this topic to the charter once we agree on what it should say. ;-) > > As for de-coupling NEA from network access, that's already part of=20 > > the plan (as described above). Maybe we need to make the charter=20 > > clearer on this point. > >=20 >=20 > Aside from the confusions mentioned above, when it is de-coupled from=20 > network access, it is not clear to me as to where the transport=20 > protocol is going to be specified. There are other working groups better suited for such work. For instance, an EAP method should probably go through the EAP or EMU working groups. I don't think our charter should call out work for other working groups. That got us into trouble last time. I hope the text on this that I proposed above will help clarify it. Thanks, 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 Thu May 25 12:35:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjInk-0007Hh-87; Thu, 25 May 2006 12:35:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjInj-0007HX-2W for nea@ietf.org; Thu, 25 May 2006 12:35:07 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjH4N-0007Th-EA for nea@ietf.org; Thu, 25 May 2006 10:44:11 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FjGzK-0000u6-JM for nea@ietf.org; Thu, 25 May 2006 10:38:59 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 25 May 2006 07:38:57 -0700 X-IronPort-AV: i="4.05,173,1146466800"; d="scan'208"; a="549199133:sNHT28287548" 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, 25 May 2006 10:39:03 -0400 Message-ID: In-Reply-To: <44752D70.4080602@nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Detecting Compromised Endpoints Thread-Index: AcZ/sMuGK/cSGJrvQ7KTj7CiAbPGHQAQ+ocQ From: "Stephen Hanna" To: X-Spam-Score: -2.6 (--) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [Nea] Detecting Compromised Endpoints 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 Let's start a new thread on detecting compromised endpoints. Can trusted hardware help? Other ideas? This is really a separate topic worthy of a full discussion. Also, it keeps coming up. Let's thrash this thing out thoroughly and then we can ask people who raise this issue to start by reading this thread (or a summary of it). I think we should probably start the discussion by agreeing that we're not going to standardize any of this stuff in IETF. However, it is sort of within scope for NEA since we're supposed to do a security analysis of the whole problem and this issue ALWAYS comes up (for good reason). I call this the "lying endpoint problem". What good is an NEA system if a compromised endpoint can just lie about its health? In my view, there are two answers: 1) Even if NEA only works for healthy endpoints, it's a good thing because it will make them keep their defenses up: get patches, turn on the firewall, etc. You can think of it as a public health campaign for the endpoints. 2) With trusted hardware (and maybe some systems with a tiny trusted hypervisor or such), endpoint compromise can be reliably detected. I think the main area of debate is the item 2). Does it actually work? So I'll send a separate email on that, responding to this email. But I'd like to invite anyone with more general comments to respond to this email directly. I hope we can keep all the emails on this topic under this thread so they will be easy to find 2-3 years from now. Thanks, Steve _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu May 25 13:03:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjJFO-00083u-I7; Thu, 25 May 2006 13:03:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjJFN-00083p-6R for nea@ietf.org; Thu, 25 May 2006 13:03:41 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjJFL-0002jB-Ny for nea@ietf.org; Thu, 25 May 2006 13:03:41 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 25 May 2006 10:03:39 -0700 X-IronPort-AV: i="4.05,173,1146466800"; d="scan'208"; a="553519826:sNHT33332952" 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, 25 May 2006 13:03:44 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Detecting Compromised Endpoints Thread-Index: AcZ/sMuGK/cSGJrvQ7KTj7CiAbPGHQAQ+ocQAAUSLvA= From: "Stephen Hanna" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Subject: [Nea] RE: Detecting Compromised Endpoints 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 OK. Let's tackle that nasty question. Can trusted hardware actually detect endpoint compromise? I'll give my answer about the TPM here, trying to strip things down to the essentials. I'm sure others from TCG will correct any errors or add any important nuances. TPM stands for Trusted Platform Module. A TPM is a trusted security component, usually implemented in hardware. It can do several things and has several applications but the main one we're concerned with here is Trusted Boot. If you have a TPM on your machine and Trusted Boot is implemented and enabled, then the TPM is involved in the boot sequence. Before any piece of trusted code is run, it is first measured by the TPM. Measuring means that the TPM takes a hash of the code and combines that hash with all the previous hashes made in the boot sequence, storing the result in a Platform Configuration Register (PCR). The TPM doesn't make any decision about whether each piece of code in the boot sequence is good. It just includes it in the hash. When your machine starts an NEA handshake, a Posture Collector on your machine gathers the PCR value from the TPM and sends it securely (more later) to a Posture Validator on the server. The Posture Validator compares the PCR value against a list of PCR values that would come from known good configurations. If the PCR value from the endpoint matches one of the known good values, the machine is fine. If not, it is probably compromised. It should be quarantined and examined carefully. That's the essence of the answer to how a TPM can detect endpoint compromise. But there are a lot of things I need to clarify. 1) What needs to be measured? All the trusted code on the endpoint needs to be measured. That includes all the software and firmware in the Trusted Computing Base, any code whose compromise would potentially cause the system to violate its security policies. This includes the BIOS, the boot loader, the OS kernel, the kernel drivers, etc. If the operating system is well written, it should not include application code since that code cannot cause the system to violate its security policies. 2) How does the Posture Collector send the PCR securely to the Posture Validator? The Posture Validator sends a nonce. The TPM signs the nonce and the PCR with a private key stored only on the TPM. The Posture Collector sends the signed nonce and PCR back to the Posture Validator along with certificates that vouch for the TPM's public key. The nonce prevents replay. 3) How does the Posture Validator get that list of PCR values for known good configurations? Typically from a subscription service that maintains a list of PCR values for various versions of software from all the major vendors. The decision about which software versions are "good" is a policy decision generally left to the network owner. 4) Won't this prevent me from using my favorite OS? That depends on your network's policy. If you don't like their policy, you're free to shop around. Remember that the TPM is an optional component and comes disabled. You can just leave it disabled. Or you can run your favorite OS within an untrusted application. Or you can have an untrusted application forward packets from your favorite OS. Anyway, those subscription services aren't cheap. Trusted boot will probably be mainly deployed in high-security environments. 5) How does this let the server detect endpoint compromise? If a trusted software component on the endpoint has been compromised, that will show up as a PCR with an unrecognized value. Because the TPM hashes the software before it's run and won't let the software zero the PCR (and because the hash is preimage resistant), the compromised software can't get the TPM to report a valid PCR value. And it can't replay an old PCR value because of the nonce. 6) Aren't there ways to attack this system? Yes. You can break the system if you can successfully attack any one of these: the TPM (with physical attacks or by finding flaws in it), the CAs that signed the TPM's certificates (or their operators), the trusted software that's listed in the known good configs, the cryptographic algorithms and protocols involved, or the Network Enforcer or the NEA server or their operators. There's also a clever attack described in Appendix A of the TNC IF-T document. Countermeasures for that attack are given in that document. I have omitted some attacks for which countermeasures are available. If you have other attacks you're interested in, please raise them and I'd be glad to address them. 7) Won't there inevitably be vulnerabilities in the trusted software? Yes. That's true today. It will probably always be true. The best way to handle it is to reduce the number of vulnerabilities by making the trusted software as small and secure as possible. Beyond that, identify vulnerabilities as soon as possible (preferably before exploits are available), prepare fixes, and then remove the old buggy software from the list of known good configurations (or move it to a list of configurations that require quarantine and mandatory remediation). Thanks, Steve _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu May 25 13:54:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjK27-0001Ie-1a; Thu, 25 May 2006 13:54:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjK25-0001IY-Cp for nea@ietf.org; Thu, 25 May 2006 13:54:01 -0400 Received: from silver.veritas.com ([143.127.12.111]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjK21-0007ES-OC for nea@ietf.org; Thu, 25 May 2006 13:54:01 -0400 Received: from sxchcon2-int.veritas.com (HELO SVLXCHCON2.enterprise.veritas.com) ([10.137.18.172]) by silver.veritas.com with ESMTP; 25 May 2006 10:53:51 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,173,1146466800"; d="scan'208"; a="38520476:sNHT26280420" Received: from SVL1XCHEVSPIN01.enterprise.veritas.com ([166.98.169.10]) by SVLXCHCON2.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 25 May 2006 10:53:50 -0700 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] RE: Detecting Compromised Endpoints Date: Thu, 25 May 2006 10:53:48 -0700 Message-ID: <5A58F967CBEBBB4A82DF126CF8A9596AF0A1F7@SVL1XCHCLUPIN01.enterprise.veritas.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] RE: Detecting Compromised Endpoints Thread-Index: AcZ/sMuGK/cSGJrvQ7KTj7CiAbPGHQAQ+ocQAAUSLvAABilLQA== From: "Paul Sangster" To: "Stephen Hanna" , X-OriginalArrivalTime: 25 May 2006 17:53:50.0250 (UTC) FILETIME=[2DD130A0:01C68024] X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 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 Nice summary. There are longer answers to how a number of the mechanisms you describe below work safely, but this is a great e-mail to kick off the thread. One other question for the FAQ below would be about the bootstrapping problem which is interesting to discuss.=20 8) If the TPM is passive and software is performing the measurements, who measures the 1st measurer? The TCG architecture includes a hardware/firmware component called the CRTM (Core Root of Trust for Measurement.) This component is utilized during the IPL of the system to measure (e.g. SHA-1 hash) the initial piece of software to be loaded into memory and run on the CPU such as a more capable loader which is also instrumented to measure subsequent components establishing the chain of trust. The chain of trust is maintained in the running PCR values (as discuss below) and is documented in a verifiable measurement integrity log. Clearly integrity protection of the CRTM is very important so its mutability must be tightly controlled (must be more controlled then normal software on the disk.) How this component is bound to the platform and protected gets into implementation specifics.=20 As security people we all know the bootstrapping problem is very difficult to pragmatically address but we try to raise the bar on exploits as much as is possible. Paul > -----Original Message----- > From: Stephen Hanna [mailto:shanna@juniper.net]=20 > Sent: Thursday, May 25, 2006 10:04 AM > To: nea@ietf.org > Subject: [Nea] RE: Detecting Compromised Endpoints >=20 > OK. Let's tackle that nasty question. Can trusted hardware=20 > actually detect endpoint compromise? >=20 > I'll give my answer about the TPM here, trying to strip=20 > things down to the essentials. I'm sure others from TCG will=20 > correct any errors or add any important nuances. >=20 > TPM stands for Trusted Platform Module. A TPM is a trusted=20 > security component, usually implemented in hardware. It can=20 > do several things and has several applications but the main=20 > one we're concerned with here is Trusted Boot. >=20 > If you have a TPM on your machine and Trusted Boot is=20 > implemented and enabled, then the TPM is involved in the boot=20 > sequence. Before any piece of trusted code is run, it is=20 > first measured by the TPM. Measuring means that the TPM takes=20 > a hash of the code and combines that hash with all the=20 > previous hashes made in the boot sequence, storing the result=20 > in a Platform Configuration Register (PCR). The TPM doesn't=20 > make any decision about whether each piece of code in the=20 > boot sequence is good. It just includes it in the hash. >=20 > When your machine starts an NEA handshake, a Posture=20 > Collector on your machine gathers the PCR value from the TPM=20 > and sends it securely (more later) to a Posture Validator on=20 > the server. The Posture Validator compares the PCR value=20 > against a list of PCR values that would come from known good=20 > configurations. If the PCR value from the endpoint matches=20 > one of the known good values, the machine is fine. If not, it=20 > is probably compromised. > It should be quarantined and examined carefully. >=20 > That's the essence of the answer to how a TPM can detect=20 > endpoint compromise. But there are a lot of things I need to clarify. >=20 > 1) What needs to be measured? >=20 > All the trusted code on the endpoint needs to be measured. > That includes all the software and firmware in the Trusted > Computing Base, any code whose compromise would potentially > cause the system to violate its security policies. This > includes the BIOS, the boot loader, the OS kernel, the > kernel drivers, etc. If the operating system is well written, > it should not include application code since that code > cannot cause the system to violate its security policies. >=20 > 2) How does the Posture Collector send the PCR securely > to the Posture Validator? >=20 > The Posture Validator sends a nonce. The TPM signs the > nonce and the PCR with a private key stored only on the > TPM. The Posture Collector sends the signed nonce and > PCR back to the Posture Validator along with certificates > that vouch for the TPM's public key. The nonce prevents > replay. >=20 > 3) How does the Posture Validator get that list of PCR values > for known good configurations? >=20 > Typically from a subscription service that maintains a > list of PCR values for various versions of software from > all the major vendors. The decision about which software > versions are "good" is a policy decision generally left > to the network owner. >=20 > 4) Won't this prevent me from using my favorite OS? >=20 > That depends on your network's policy. If you don't like > their policy, you're free to shop around. Remember that > the TPM is an optional component and comes disabled. You > can just leave it disabled. Or you can run your favorite > OS within an untrusted application. Or you can have an > untrusted application forward packets from your favorite OS. > Anyway, those subscription services aren't cheap. Trusted > boot will probably be mainly deployed in high-security > environments. >=20 > 5) How does this let the server detect endpoint compromise? >=20 > If a trusted software component on the endpoint has been > compromised, that will show up as a PCR with an unrecognized > value. Because the TPM hashes the software before it's run > and won't let the software zero the PCR (and because the > hash is preimage resistant), the compromised software can't > get the TPM to report a valid PCR value. And it can't > replay an old PCR value because of the nonce. >=20 > 6) Aren't there ways to attack this system? >=20 > Yes. You can break the system if you can successfully attack > any one of these: the TPM (with physical attacks or by finding > flaws in it), the CAs that signed the TPM's certificates (or > their operators), the trusted software that's listed in the > known good configs, the cryptographic algorithms and protocols > involved, or the Network Enforcer or the NEA server or their > operators. There's also a clever attack described in Appendix A > of the TNC IF-T document. Countermeasures for that attack are > given in that document. >=20 > I have omitted some attacks for which countermeasures are > available. If you have other attacks you're interested in, > please raise them and I'd be glad to address them. >=20 > 7) Won't there inevitably be vulnerabilities in the trusted software? >=20 > Yes. That's true today. It will probably always be true.=20 > The best way > to handle it is to reduce the number of vulnerabilities by making > the trusted software as small and secure as possible. Beyond that, > identify vulnerabilities as soon as possible (preferably before > exploits are available), prepare fixes, and then remove=20 > the old buggy > software from the list of known good configurations (or=20 > move it to a > list of configurations that require quarantine and mandatory > remediation). >=20 > Thanks, >=20 > Steve >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu May 25 14:20:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjKRi-0007S7-GG; Thu, 25 May 2006 14:20:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjKRh-0007S2-Oq for nea@ietf.org; Thu, 25 May 2006 14:20:29 -0400 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjKRg-0000Q5-Cr for nea@ietf.org; Thu, 25 May 2006 14:20:29 -0400 Received: from zcarhxm2.corp.nortel.com (zcarhxm2.corp.nortel.com [47.129.230.99]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k4PIKPS12610; Thu, 25 May 2006 14:20:25 -0400 (EDT) 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] RE: Detecting Compromised Endpoints Date: Thu, 25 May 2006 14:20:25 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] RE: Detecting Compromised Endpoints Thread-Index: AcZ/sMuGK/cSGJrvQ7KTj7CiAbPGHQAQ+ocQAAUSLvAABuOoEA== From: "Marcus Leech" To: "Stephen Hanna" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 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 1) What needs to be measured? All the trusted code on the endpoint needs to be measured. That includes all the software and firmware in the Trusted Computing Base, any code whose compromise would potentially cause the system to violate its security policies. This includes the BIOS, the boot loader, the OS kernel, the kernel drivers, etc. If the operating system is well written, it should not include application code since that code cannot cause the system to violate its security policies. The essential problem is that for any *practical* operating system for purposes of general-purpose computing, there *is* application code, the compromise of which, can cause the system to violate its security policies. The only thing the hash does is to assert that the code is free from any *known* vulnerabilities. Once the system is compromised, it can continue to provide an idyllic view to the TPM/PCR machinery. 3) How does the Posture Validator get that list of PCR values for known good configurations? Typically from a subscription service that maintains a list of PCR values for various versions of software from all the major vendors. The decision about which software versions are "good" is a policy decision generally left to the network owner. You have to assume that a compromised system would be able to maintain a consistently-idyllic view using some similar type of "subscription service". Essentially, a compromised system can continue to update the view of the world it wishes to present to the TCG subsystems. The *reality*, however, will be quite different. =20 4) Won't this prevent me from using my favorite OS? That depends on your network's policy. If you don't like their policy, you're free to shop around. Remember that the TPM is an optional component and comes disabled. You can just leave it disabled. Or you can run your favorite OS within an untrusted application. Or you can have an untrusted application forward packets from your favorite OS. Anyway, those subscription services aren't cheap. Trusted boot will probably be mainly deployed in high-security environments. There's also the scenario of a NAT-like device in a TCG/TPM/NAP/NAC/whatever world. You have a "policy-compliant" system act as a proxy for a pool of non-compliant nodes. "Fixing" that kind of scenario tends to produce a system that is unusable for ordinary use. Perfectly secure, and utterly unusable. 5) How does this let the server detect endpoint compromise? If a trusted software component on the endpoint has been compromised, that will show up as a PCR with an unrecognized value. Because the TPM hashes the software before it's run and won't let the software zero the PCR (and because the hash is preimage resistant), the compromised software can't get the TPM to report a valid PCR value. And it can't replay an old PCR value because of the nonce. That only applies to "compromised on disk". The state of said software at some time T after it has begun executing *cannot* be attested-to by anything. If that were possible, then it would imply having a general solution to the halting problem. In fact, even the known-good PCR values are only attesting to the fact that the software is known to be resistant to all the vulnerabilities we *know about* in the software. With the emergence of zero-day exploits of vulnerabilities, I wonder how useful this will actually be. =20 6) Aren't there ways to attack this system? Yes. You can break the system if you can successfully attack any one of these: the TPM (with physical attacks or by finding flaws in it), the CAs that signed the TPM's certificates (or their operators), the trusted software that's listed in the known good configs, the cryptographic algorithms and protocols involved, or the Network Enforcer or the NEA server or their operators. There's also a clever attack described in Appendix A of the TNC IF-T document. Countermeasures for that attack are given in that document. I have omitted some attacks for which countermeasures are available. If you have other attacks you're interested in, please raise them and I'd be glad to address them. 7) Won't there inevitably be vulnerabilities in the trusted software? Yes. That's true today. It will probably always be true. The best way to handle it is to reduce the number of vulnerabilities by making the trusted software as small and secure as possible. Beyond that, identify vulnerabilities as soon as possible (preferably before exploits are available), prepare fixes, and then remove the old buggy software from the list of known good configurations (or move it to a list of configurations that require quarantine and mandatory remediation). The problem is that *real* generally-useful computing environments are still going to have very large components that have to be trusted to behave correctly at all times. If you have an operating system that has all those desirable properties, then you don't need any of this TPM/TNC/NEA/TCG goop. The raison d'etre for this stuff is precisely because operating systems today are vulnerable due to a large number of factors, including broken architectures, programming language design, human frailty, etc, etc. And it is precisely because of that that this stuff can't be made to work, for any sufficiently-rigorous definition of the word "work". The bad guys are getting cleverer, and a large fraction of the "good guys" haven't actually done any detailed analysis of all this TCG/TNC/TPM/NEA stuff yet. I fully expect that there will be gaping holes found within two years. I'd be perfectly delighted to be proven wrong. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu May 25 19:57:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjPhV-0006yJ-Rs; Thu, 25 May 2006 19:57:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjPhU-0006y4-Lf for nea@ietf.org; Thu, 25 May 2006 19:57:08 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjP1R-0003cO-0d for nea@ietf.org; Thu, 25 May 2006 19:13:41 -0400 Received: from gold.veritas.com ([143.127.12.110]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FjOTv-0007IC-Ii for nea@ietf.org; Thu, 25 May 2006 18:39:06 -0400 Received: from sxchcon2-int.veritas.com (HELO SVLXCHCON2.enterprise.veritas.com) ([10.137.18.172]) by gold.veritas.com with ESMTP; 25 May 2006 15:39:03 -0700 X-IronPort-AV: i="4.05,173,1146466800"; d="scan'208"; a="59887600:sNHT35963304" Received: from SVL1XCHEVSPIN01.enterprise.veritas.com ([166.98.169.10]) by SVLXCHCON2.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 25 May 2006 15:39:02 -0700 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] RE: Detecting Compromised Endpoints Date: Thu, 25 May 2006 15:39:02 -0700 Message-ID: <5A58F967CBEBBB4A82DF126CF8A9596AF0A511@SVL1XCHCLUPIN01.enterprise.veritas.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] RE: Detecting Compromised Endpoints Thread-Index: AcZ/sMuGK/cSGJrvQ7KTj7CiAbPGHQAQ+ocQAAUSLvAABuOoEAAGYz3A From: "Paul Sangster" To: "Marcus Leech" , "Stephen Hanna" , X-OriginalArrivalTime: 25 May 2006 22:39:02.0692 (UTC) FILETIME=[05A09E40:01C6804C] X-Spam-Score: -2.6 (--) X-Scan-Signature: f5932bfc8385127f631fc458a872feb1 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 Discussions like these make me wonder what the automotive safety engineers must have discussed when the idea of the: seat belt, air bag, crumple zones ... were being considered :). How many lives do we need to save to make it useful ... Hopefully we wouldn't pass on doing NEA because its not a panacea for security (its not.) NEA itself doesn't try to solve the problems of this thread, we're merely discussing if they might be orthogonal mechanisms to help prevent the collector from mis-reporting the situation. Putting a spotlight on the desire to report configuration should help bring focus to protecting the collection/reporting mechanisms. So with that said, let go into the interesting dialog. Clearly you've raised very interesting and challenging issues that most (all?) of our other standards couldn't live up to (fortunately, there are threat models to save the day by scoping them out :)) > -----Original Message----- > From: Marcus Leech [mailto:mleech@nortel.com]=20 > Sent: Thursday, May 25, 2006 11:20 AM > To: Stephen Hanna; nea@ietf.org > Subject: RE: [Nea] RE: Detecting Compromised Endpoints >=20 >=20 >=20 > 1) What needs to be measured? >=20 > All the trusted code on the endpoint needs to be measured. > That includes all the software and firmware in the Trusted > Computing Base, any code whose compromise would potentially > cause the system to violate its security policies. This > includes the BIOS, the boot loader, the OS kernel, the > kernel drivers, etc. If the operating system is well written, > it should not include application code since that code > cannot cause the system to violate its security policies. >=20 > The essential problem is that for any *practical* operating system for > purposes of general-purpose computing, there *is* application code, > the compromise of which, can cause the system to violate=20 > its security > policies. Sure, privileged code also runs in applications so the kernel doesn't need to contain everything. Ideally OSes would limit privileges (ability to bypass some security check) more granularly (e.g. Solaris 10's privilege model) but many do not or the granularity isn't used so point taken. I think one of the areas of discussion around the use of TCG verification is how to enable product vendors (or 3rd party "integrity" oriented vendors) to define trust dependency trees so that verifiers can determine what set of component measurements it needs to verify to feel safe trusting the requesting system for a particular purpose. For many use cases, only portions of the machine need to be checked (e.g when your just trusting a browser session so need to check the kernel, privileged apps and things relied upon by the brower. I don't think this is an unsolvable problem, just a hard one. We need an ongoing dialog to understand what is running on the requesting system that needs to be trusted and traverse its trust dependency tree. For NEA this might be the kernel plus the set of privileged apps and some security configuration information or it might involve checking a special security partition + hypervisor (depending on the system architecture.) >=20 > The only thing the hash does is to assert that the code is=20 > free from any > *known* vulnerabilities. Once the system is compromised,=20 > it can continue > to provide an idyllic view to the TPM/PCR machinery. The hash just records that a particular image of code was run on the system (so it could later or immediately be verified [*]) in a way that can't be hidden. The TPM only allows "extends" to the PCR so trusted apps can effectively add to the values but not remove prior entries. The meta-data about each extend is stored in a measurement log and is used for verification. A rootkit might be able to alter the measurement log but to hide its existance but it wouldn't be able to change the PCRs to erase its measurement. The way the TPM is used it has the capability of signing the PCRs with a private key for a particular attestation to a verifier. The verifier needs an equivalent measurement log (history of the PCR) to verify that it correctly recomputes the aggregate current value stored in the PCR(s) and can verify the meta-data makes sense and is considered valid by policy. I'm not sure how malware that was measured into a PCR could hide its presence without resetting the PCR back to a desired value. [*] - Background: the model allows for a local verifier that checks code measurements against a set of known valid measurements before allowing it to run. This effective prevents code with known vulnerabilities from running and establishes a trustworthy base to build upon as long as you can trust the verifier (done via chain of trust.) As Marcus correctly points out this doesn't catch unknown vulnerabilities. The TCG technology that I know of doesn't do behavioral checking although such technologies do exist and watch for zero-day attacks as we speak. You could imagine that these could be integrated and will evolve over time. >=20 >=20 > 3) How does the Posture Validator get that list of PCR values > for known good configurations? >=20 > Typically from a subscription service that maintains a > list of PCR values for various versions of software from > all the major vendors. The decision about which software > versions are "good" is a policy decision generally left > to the network owner. >=20 > You have to assume that a compromised system would be able to maintain > a consistently-idyllic view using some similar type of=20 > "subscription service". > Essentially, a compromised system can continue to update=20 > the view of the > world it wishes to present to the TCG subsystems. The=20 > *reality*, however, > will be quite different. Same comment as above. How does the malware reset the PCRs back to the idyllic values so future attestations comes up clean? Most of the PCRs do not allow "set" type of operations, so this means the malware couldn't use the TPM signed set of PCR values to spoof the verifier (nor could it use the TPM's cert since it lacks access to the private key to quote (sign) the incorrect pseudo-PCRs.) > =20 >=20 > 4) Won't this prevent me from using my favorite OS? >=20 > That depends on your network's policy. If you don't like > their policy, you're free to shop around. Remember that > the TPM is an optional component and comes disabled. You > can just leave it disabled. Or you can run your favorite > OS within an untrusted application. Or you can have an > untrusted application forward packets from your favorite OS. > Anyway, those subscription services aren't cheap. Trusted > boot will probably be mainly deployed in high-security > environments. >=20 > There's also the scenario of a NAT-like device in a=20 > TCG/TPM/NAP/NAC/whatever > world. You have a "policy-compliant" system act as a proxy=20 > for a pool > of non-compliant nodes. "Fixing" that kind of scenario=20 > tends to produce > a system that is unusable for ordinary use. Perfectly=20 > secure, and utterly > unusable. Not sure I follow. Are you referring to the tunneling attack discussed in the TNC's IF-T specification or a true proxy? In the true proxy case, the proxies should show up in the list of measurements required by the verifier and the verifier's policy DB shouldn't allow this configuration. For the nested tunnel attack, there are already suggested countermeasures and work is underway for more (not unsolvable.) Was your comment about "fixing" the proxy case meaning that systems need to be able to run such software or else they aren't useful? Maybe you could explain more about your thinking? >=20 > 5) How does this let the server detect endpoint compromise? >=20 > If a trusted software component on the endpoint has been > compromised, that will show up as a PCR with an unrecognized > value. Because the TPM hashes the software before it's run > and won't let the software zero the PCR (and because the > hash is preimage resistant), the compromised software can't > get the TPM to report a valid PCR value. And it can't > replay an old PCR value because of the nonce. >=20 > That only applies to "compromised on disk". The state of=20 > said software > at some time T after it has begun executing *cannot* be attested-to > by anything. If that were possible, then it would imply having a > general solution to the halting problem. In fact, even the=20 > known-good > PCR values are only attesting to the fact that the software=20 > is known to > be resistant to all the vulnerabilities we *know about* in=20 > the software. > With the emergence of zero-day exploits of vulnerabilities, I wonder > how useful this will actually be. Without trying to solve the halting problem you can introduce mechanisms to help raise the security level of the system. Is this useless to try unless they are foolproof? There are an endless list of security mechanisms which can't address this issue (bug in an IKE implementation leaks phase 2 keys, buffer overflow of a privileged daemon and now we can change TLS trust anchors, timing attack against processor caches and you can learn OpenSSL private keys ...) I agree it's a hard problem but hope we don't let it stop progress. People are working (and shipping) technologies to try to catch zero-day exploits and these could be integrated with other system integrity protection features to raise the bar as best we can without waking Mr Turing :). If a system measured all software as its loaded and check it was clean against known vulnerabilities, recorded the measurement in a TPM (or tamperproof environment) and created a measurement log, used AV and behavioral techniques to watch for viruses in running code, ... and was able to produce an attestation of all of this and the configurations/databases it used in a non-spoofable way, this seems to be better then we have today. Add in support for separate protection domains to isolate security mechanisms (and logs) and we seem to be raising the bar. Of course this isn't TNC, but its something orthogonal that people in the industry are working on and seems to fit in with what is being planned. Such integrity mechanisms could offer a Posture Collector/Verifier pair to fit into the NEA model. > =20 > 6) Aren't there ways to attack this system? >=20 > Yes. You can break the system if you can successfully attack > any one of these: the TPM (with physical attacks or by finding > flaws in it), the CAs that signed the TPM's certificates (or > their operators), the trusted software that's listed in the > known good configs, the cryptographic algorithms and protocols > involved, or the Network Enforcer or the NEA server or their > operators. There's also a clever attack described in Appendix A > of the TNC IF-T document. Countermeasures for that attack are > given in that document. >=20 > I have omitted some attacks for which countermeasures are > available. If you have other attacks you're interested in, > please raise them and I'd be glad to address them. >=20 > 7) Won't there inevitably be vulnerabilities in the trusted software? >=20 > Yes. That's true today. It will probably always be true.=20 > The best way > to handle it is to reduce the number of vulnerabilities by making > the trusted software as small and secure as possible. Beyond that, > identify vulnerabilities as soon as possible (preferably before > exploits are available), prepare fixes, and then remove=20 > the old buggy > software from the list of known good configurations (or=20 > move it to a > list of configurations that require quarantine and mandatory > remediation). >=20 > The problem is that *real* generally-useful computing=20 > environments are still > going to have very large components that have to be trusted=20 > to behave > correctly at all times. If you have an operating system=20 > that has all > those > desirable properties, then you don't need any of this=20 > TPM/TNC/NEA/TCG goop. Ah, but this means that we do need TPM/TNC/NEA/TCG goop :). Clearly big, complex software will have security bugs that will get fixed and patches released. Hopefully NEA will help get the lack of those patches recognized and distributed more quickly (being more centrally controlled) but will need new measurement policies provisioned quickly.=20 >=20 > The raison d'etre for this stuff is precisely because=20 > operating systems today > are vulnerable due to a large number of factors, including=20 > broken architectures, > programming language design, human frailty, etc, etc. And=20 > it is precisely because > of that that this stuff can't be made to work, for any=20 > sufficiently-rigorous > definition of the word "work". >=20 > The bad guys are getting cleverer, and a large fraction of=20 > the "good guys" haven't > actually done any detailed analysis of all this=20 > TCG/TNC/TPM/NEA stuff yet. Having an NEA WG just helps bring exposure to this area so more detailed analysis can be performed and we can improve the situation. The TCG/TNC/TPM specs are public so can be reviewed. Their have been a number of good cryptographers and security people who have reviewed the TCG stuff but it's a work in progress so hopefully this momentum will continue. > I fully expect that there will be gaping holes found within=20 > two years. That's why we have version 2 :). History is certainly on your side (SSHv1, SSLv1, Kerberos v4, ...) have all needed updates to improve based on holes, I'm sure this will be the same. >=20 > I'd be perfectly delighted to be proven wrong. Sorry but you'll still have a job for a few more years :). >=20 >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu May 25 20:56:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjQdE-0003qN-1t; Thu, 25 May 2006 20:56:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjQdC-0003qI-I6 for nea@ietf.org; Thu, 25 May 2006 20:56:46 -0400 Received: from e32.co.us.ibm.com ([32.97.110.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjQdB-0003yx-8G for nea@ietf.org; Thu, 25 May 2006 20:56:46 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k4Q0uiBa026302 for ; Thu, 25 May 2006 20:56:44 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k4Q0uiCM165946 for ; Thu, 25 May 2006 18:56:44 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k4Q0uirb003901 for ; Thu, 25 May 2006 18:56:44 -0600 Received: from d03nm129.boulder.ibm.com (d03nm129.boulder.ibm.com [9.17.195.155]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k4Q0uipV003896; Thu, 25 May 2006 18:56:44 -0600 In-Reply-To: <5A58F967CBEBBB4A82DF126CF8A9596AF0A511@SVL1XCHCLUPIN01.enterprise.veritas.com> Subject: RE: [Nea] RE: Detecting Compromised Endpoints To: "Paul Sangster" X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 Message-ID: From: Frank Yeh Jr Date: Thu, 25 May 2006 17:56:35 -0700 X-MIMETrack: Serialize by Router on D03NM129/03/M/IBM(Release 7.0.1HF123 | April 14, 2006) at 05/25/2006 18:59:54 MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: b446c230caab880282be239780d76153 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: , Content-Type: multipart/mixed; boundary="===============0688899630==" Errors-To: nea-bounces@ietf.org --===============0688899630== Content-type: multipart/alternative; Boundary="0__=07BBFBE9DF90807D8f9e8a93df938690918c07BBFBE9DF90807D" Content-Disposition: inline --0__=07BBFBE9DF90807D8f9e8a93df938690918c07BBFBE9DF90807D Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Greetings, I am a little confused by this thread as it seems to me to be out= of scope with the NEA work. Perhaps I added to the confusion by mentioning= in a previous post that NEA could leverage trusted hardware. For that, I a= m sorry (well, sort of). So my impression of the NEA charter is that the procotol will be about format, aggregation, and transport of Posture information. There = does not seem to be anything related to establishing trust of the various components that use the procotol. However, it would be valid to use the= NEA protocols to enable a single collector/validator pair that would attest= to the integrity of all other components. I do not see why this should be = part of the NEA protocols themselves. This thread probably has to do with the many TCG-aware people participating in NEA, but I think that is confusing the issue. However,= since I said TCG, I would point out that the TNC specs and the PTS spec= are separate. Why then are we talking about combining these functions in NE= A? Regards, Frank Yeh Corporate Security Strategy Team IBM Tivoli Software "Paul Sangster" wrote on 05/25/2006 03:39:= 02 PM: > > Discussions like these make me wonder what the automotive safety > engineers must have discussed when the idea of the: seat belt, air ba= g, > crumple zones ... were being considered :). How many lives do we nee= d > to save to make it useful ... > > Hopefully we wouldn't pass on doing NEA because its not a panacea for= > security (its not.) NEA itself doesn't try to solve the problems of > this thread, we're merely discussing if they might be orthogonal > mechanisms to help prevent the collector from mis-reporting the > situation. Putting a spotlight on the desire to report configuratio= n > should help bring focus to protecting the collection/reporting > mechanisms. > > So with that said, let go into the interesting dialog. Clearly you'v= e > raised very interesting and challenging issues that most (all?) of ou= r > other standards couldn't live up to (fortunately, there are threat > models to save the day by scoping them out :)) > > > -----Original Message----- > > From: Marcus Leech [mailto:mleech@nortel.com] > > Sent: Thursday, May 25, 2006 11:20 AM > > To: Stephen Hanna; nea@ietf.org > > Subject: RE: [Nea] RE: Detecting Compromised Endpoints > > > > > > > > 1) What needs to be measured? > > > > All the trusted code on the endpoint needs to be measured. > > That includes all the software and firmware in the Trusted > > Computing Base, any code whose compromise would potentially > > cause the system to violate its security policies. This > > includes the BIOS, the boot loader, the OS kernel, the > > kernel drivers, etc. If the operating system is well written, > > it should not include application code since that code > > cannot cause the system to violate its security policies. > > > > The essential problem is that for any *practical* operating system = for > > purposes of general-purpose computing, there *is* application cod= e, > > the compromise of which, can cause the system to violate > > its security > > policies. > > Sure, privileged code also runs in applications so the kernel doesn't= > need to contain everything. Ideally OSes would limit privileges > (ability to bypass some security check) more granularly (e.g. Solaris= > 10's privilege model) but many do not or the granularity isn't used s= o > point taken. > > I think one of the areas of discussion around the use of TCG > verification is how to enable product vendors (or 3rd party "integrit= y" > oriented vendors) to define trust dependency trees so that verifiers = can > determine what set of component measurements it needs to verify to fe= el > safe trusting the requesting system for a particular purpose. For ma= ny > use cases, only portions of the machine need to be checked (e.g when > your just trusting a browser session so need to check the kernel, > privileged apps and things relied upon by the brower. > > I don't think this is an unsolvable problem, just a hard one. We nee= d > an ongoing dialog to understand what is running on the requesting sys= tem > that needs to be trusted and traverse its trust dependency tree. For= > NEA this might be the kernel plus the set of privileged apps and some= > security configuration information or it might involve checking a > special security partition + hypervisor (depending on the system > architecture.) > > > > > The only thing the hash does is to assert that the code is > > free from any > > *known* vulnerabilities. Once the system is compromised, > > it can continue > > to provide an idyllic view to the TPM/PCR machinery. > > The hash just records that a particular image of code was run on the > system (so it could later or immediately be verified [*]) in a way th= at > can't be hidden. The TPM only allows "extends" to the PCR so trusted= > apps can effectively add to the values but not remove prior entries. > The meta-data about each extend is stored in a measurement log and is= > used for verification. A rootkit might be able to alter the measurem= ent > log but to hide its existance but it wouldn't be able to change the P= CRs > to erase its measurement. > > The way the TPM is used it has the capability of signing the PCRs wit= h a > private key for a particular attestation to a verifier. The verifier= > needs an equivalent measurement log (history of the PCR) to verify th= at > it correctly recomputes the aggregate current value stored in the PCR= (s) > and can verify the meta-data makes sense and is considered valid by > policy. I'm not sure how malware that was measured into a PCR could > hide its presence without resetting the PCR back to a desired value. > > [*] - Background: the model allows for a local verifier that checks c= ode > measurements against a set of known valid measurements before allowin= g > it to run. This effective prevents code with known vulnerabilities fr= om > running and establishes a trustworthy base to build upon as long as y= ou > can trust the verifier (done via chain of trust.) As Marcus correctl= y > points out this doesn't catch unknown vulnerabilities. The TCG > technology that I know of doesn't do behavioral checking although suc= h > technologies do exist and watch for zero-day attacks as we speak. Yo= u > could imagine that these could be integrated and will evolve over tim= e. > > > > > > > 3) How does the Posture Validator get that list of PCR values > > for known good configurations? > > > > Typically from a subscription service that maintains a > > list of PCR values for various versions of software from > > all the major vendors. The decision about which software > > versions are "good" is a policy decision generally left > > to the network owner. > > > > You have to assume that a compromised system would be able to maint= ain > > a consistently-idyllic view using some similar type of > > "subscription service". > > Essentially, a compromised system can continue to update > > the view of the > > world it wishes to present to the TCG subsystems. The > > *reality*, however, > > will be quite different. > > Same comment as above. How does the malware reset the PCRs back to t= he > idyllic values so future attestations comes up clean? Most of the PC= Rs > do not allow "set" type of operations, so this means the malware > couldn't use the TPM signed set of PCR values to spoof the verifier (= nor > could it use the TPM's cert since it lacks access to the private key = to > quote (sign) the incorrect pseudo-PCRs.) > > > > > > > 4) Won't this prevent me from using my favorite OS? > > > > That depends on your network's policy. If you don't like > > their policy, you're free to shop around. Remember that > > the TPM is an optional component and comes disabled. You > > can just leave it disabled. Or you can run your favorite > > OS within an untrusted application. Or you can have an > > untrusted application forward packets from your favorite OS. > > Anyway, those subscription services aren't cheap. Trusted > > boot will probably be mainly deployed in high-security > > environments. > > > > There's also the scenario of a NAT-like device in a > > TCG/TPM/NAP/NAC/whatever > > world. You have a "policy-compliant" system act as a proxy > > for a pool > > of non-compliant nodes. "Fixing" that kind of scenario > > tends to produce > > a system that is unusable for ordinary use. Perfectly > > secure, and utterly > > unusable. > > Not sure I follow. Are you referring to the tunneling attack discuss= ed > in the TNC's IF-T specification or a true proxy? In the true proxy > case, the proxies should show up in the list of measurements required= by > the verifier and the verifier's policy DB shouldn't allow this > configuration. For the nested tunnel attack, there are already > suggested countermeasures and work is underway for more (not > unsolvable.) > > Was your comment about "fixing" the proxy case meaning that systems n= eed > to be able to run such software or else they aren't useful? Maybe yo= u > could explain more about your thinking? > > > > > 5) How does this let the server detect endpoint compromise? > > > > If a trusted software component on the endpoint has been > > compromised, that will show up as a PCR with an unrecognized > > value. Because the TPM hashes the software before it's run > > and won't let the software zero the PCR (and because the > > hash is preimage resistant), the compromised software can't > > get the TPM to report a valid PCR value. And it can't > > replay an old PCR value because of the nonce. > > > > That only applies to "compromised on disk". The state of > > said software > > at some time T after it has begun executing *cannot* be attested-= to > > by anything. If that were possible, then it would imply having a= > > general solution to the halting problem. In fact, even the > > known-good > > PCR values are only attesting to the fact that the software > > is known to > > be resistant to all the vulnerabilities we *know about* in > > the software. > > With the emergence of zero-day exploits of vulnerabilities, I won= der > > how useful this will actually be. > > Without trying to solve the halting problem you can introduce mechani= sms > to help raise the security level of the system. Is this useless to t= ry > unless they are foolproof? There are an endless list of security > mechanisms which can't address this issue (bug in an IKE implementati= on > leaks phase 2 keys, buffer overflow of a privileged daemon and now we= > can change TLS trust anchors, timing attack against processor caches = and > you can learn OpenSSL private keys ...) I agree it's a hard problem = but > hope we don't let it stop progress. People are working (and shipping= ) > technologies to try to catch zero-day exploits and these could be > integrated with other system integrity protection features to raise t= he > bar as best we can without waking Mr Turing :). > > If a system measured all software as its loaded and check it was clea= n > against known vulnerabilities, recorded the measurement in a TPM (or > tamperproof environment) and created a measurement log, used AV and > behavioral techniques to watch for viruses in running code, ... and w= as > able to produce an attestation of all of this and the > configurations/databases it used in a non-spoofable way, this seems t= o > be better then we have today. Add in support for separate protection= > domains to isolate security mechanisms (and logs) and we seem to be > raising the bar. > > Of course this isn't TNC, but its something orthogonal that people in= > the industry are working on and seems to fit in with what is being > planned. Such integrity mechanisms could offer a Posture > Collector/Verifier pair to fit into the NEA model. > > > > > 6) Aren't there ways to attack this system? > > > > Yes. You can break the system if you can successfully attack > > any one of these: the TPM (with physical attacks or by finding > > flaws in it), the CAs that signed the TPM's certificates (or > > their operators), the trusted software that's listed in the > > known good configs, the cryptographic algorithms and protocols > > involved, or the Network Enforcer or the NEA server or their > > operators. There's also a clever attack described in Appendix A > > of the TNC IF-T document. Countermeasures for that attack are > > given in that document. > > > > I have omitted some attacks for which countermeasures are > > available. If you have other attacks you're interested in, > > please raise them and I'd be glad to address them. > > > > 7) Won't there inevitably be vulnerabilities in the trusted softwar= e? > > > > Yes. That's true today. It will probably always be true. > > The best way > > to handle it is to reduce the number of vulnerabilities by makin= g > > the trusted software as small and secure as possible. Beyond tha= t, > > identify vulnerabilities as soon as possible (preferably before > > exploits are available), prepare fixes, and then remove > > the old buggy > > software from the list of known good configurations (or > > move it to a > > list of configurations that require quarantine and mandatory > > remediation). > > > > The problem is that *real* generally-useful computing > > environments are still > > going to have very large components that have to be trusted > > to behave > > correctly at all times. If you have an operating system > > that has all > > those > > desirable properties, then you don't need any of this > > TPM/TNC/NEA/TCG goop. > > Ah, but this means that we do need TPM/TNC/NEA/TCG goop :). Clearly > big, complex software will have security bugs that will get fixed and= > patches released. Hopefully NEA will help get the lack of those patc= hes > recognized and distributed more quickly (being more centrally > controlled) but will need new measurement policies provisioned quickl= y. > > > > > The raison d'etre for this stuff is precisely because > > operating systems today > > are vulnerable due to a large number of factors, including > > broken architectures, > > programming language design, human frailty, etc, etc. And > > it is precisely because > > of that that this stuff can't be made to work, for any > > sufficiently-rigorous > > definition of the word "work". > > > > The bad guys are getting cleverer, and a large fraction of > > the "good guys" haven't > > actually done any detailed analysis of all this > > TCG/TNC/TPM/NEA stuff yet. > > Having an NEA WG just helps bring exposure to this area so more detai= led > analysis can be performed and we can improve the situation. The > TCG/TNC/TPM specs are public so can be reviewed. Their have been a > number of good cryptographers and security people who have reviewed t= he > TCG stuff but it's a work in progress so hopefully this momentum will= > continue. > > > I fully expect that there will be gaping holes found within > > two years. > > That's why we have version 2 :). History is certainly on your side > (SSHv1, SSLv1, Kerberos v4, ...) have all needed updates to improve > based on holes, I'm sure this will be the same. > > > > > I'd be perfectly delighted to be proven wrong. > > Sorry but you'll still have a job for a few more years :). > > > > > > > _______________________________________________ > > 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= --0__=07BBFBE9DF90807D8f9e8a93df938690918c07BBFBE9DF90807D Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Greetings,

I am a little confused by this thread as it seems to me to be out of s= cope with the NEA work. Perhaps I added to the confusion by mentioning = in a previous post that NEA could leverage trusted hardware. For that, = I am sorry (well, sort of).

So my impression of the NEA charter is that the procotol will be about= format, aggregation, and transport of Posture information. There does = not seem to be anything related to establishing trust of the various co= mponents that use the procotol. However, it would be valid to use the N= EA protocols to enable a single collector/validator pair that would att= est to the integrity of all other components. I do not see why this sho= uld be part of the NEA protocols themselves.

This thread probably has to do with the many TCG-aware people particip= ating in NEA, but I think that is confusing the issue. However, since I= said TCG, I would point out that the TNC specs and the PTS spec are se= parate. Why then are we talking about combining these functions in NEA?=

Regards,
Frank Yeh
Corporate Security Strategy Team
IBM
Tivoli Software


"Paul Sangster" <Paul_Sangster@symantec.com> wrote = on 05/25/2006 03:39:02 PM:

>
> Discussions like these make me wonder what the automotive safety > engineers must have discussed when the idea of the: seat belt, air= bag,
> crumple zones ... were being considered :).  How many lives d= o we need
> to save to make it useful ...
>
> Hopefully we wouldn't pass on doing NEA because its not a panacea = for
> security (its not.)  NEA itself doesn't try to solve the prob= lems of
> this thread, we're merely discussing if they might be orthogonal > mechanisms to help prevent the collector from mis-reporting the > situation.   Putting a spotlight on the desire to report conf= iguration
> should help bring focus to protecting the collection/reporting
= > mechanisms.
>
> So with that said, let go into the interesting dialog.  Clear= ly you've
> raised very interesting and challenging issues that most (all?) of= our
> other standards couldn't live up to (fortunately, there are threat=
> models to save the day by scoping them out :))
>
> > -----Original Message-----
> > From: Marcus Leech [mail= to:mleech@nortel.com]
> > Sent: Thursday, May 25, 2006 11:20 AM
> > To: Stephen Hanna; nea@ietf.org
> > Subject: RE: [Nea] RE: Detecting Compromised Endpoints
> >
> >
> >
> > 1) What needs to be measured?
> >
> >    All the trusted code on the endpoint needs to be= measured.
> >    That includes all the software and firmware in t= he Trusted
> >    Computing Base, any code whose compromise would = potentially
> >    cause the system to violate its security policie= s. This
> >    includes the BIOS, the boot loader, the OS kerne= l, the
> >    kernel drivers, etc. If the operating system is = well written,
> >    it should not include application code since tha= t code
> >    cannot cause the system to violate its security = policies.
> >
> > The essential problem is that for any *practical* operating s= ystem for
> >   purposes of general-purpose computing, there *is* appl= ication code,
> >   the compromise of which, can cause the system to viola= te
> > its security
> >   policies.
>
> Sure, privileged code also runs in applications so the kernel does= n't
> need to contain everything.  Ideally OSes would limit privile= ges
> (ability to bypass some security check) more granularly (e.g. Sola= ris
> 10's privilege model) but many do not or the granularity isn't use= d so
> point taken.
>
> I think one of the areas of discussion around the use of TCG
> verification is how to enable product vendors (or 3rd party "= integrity"
> oriented vendors) to define trust dependency trees so that verifie= rs can
> determine what set of component measurements it needs to verify to= feel
> safe trusting the requesting system for a particular purpose. &nbs= p;For many
> use cases, only portions of the machine need to be checked (e.g wh= en
> your just trusting a browser session so need to check the kernel,<= br> > privileged apps and things relied upon by the brower.
>
> I don't think this is an unsolvable problem, just a hard one. &nbs= p;We need
> an ongoing dialog to understand what is running on the requesting = system
> that needs to be trusted and traverse its trust dependency tree. &= nbsp;For
> NEA this might be the kernel plus the set of privileged apps and s= ome
> security configuration information or it might involve checking a<= br> > special security partition + hypervisor (depending on the system > architecture.)
>
> >
> > The only thing the hash does is to assert that the code is > > free from any
> >   *known* vulnerabilities.  Once the system is comp= romised,
> > it can continue
> >   to provide an idyllic view to the TPM/PCR machinery. >
> The hash just records that a particular image of code was run on t= he
> system (so it could later or immediately be verified [*]) in a way= that
> can't be hidden.  The TPM only allows "extends" to = the PCR so trusted
> apps can effectively add to the values but not remove prior entrie= s.
> The meta-data about each extend is stored in a measurement log and= is
> used for verification.  A rootkit might be able to alter the = measurement
> log but to hide its existance but it wouldn't be able to change th= e PCRs
> to erase its measurement.
>
> The way the TPM is used it has the capability of signing the PCRs = with a
> private key for a particular attestation to a verifier.  The = verifier
> needs an equivalent measurement log (history of the PCR) to verify= that
> it correctly recomputes the aggregate current value stored in the = PCR(s)
> and can verify the meta-data makes sense and is considered valid b= y
> policy.  I'm not sure how malware that was measured into a PC= R could
> hide its presence without resetting the PCR back to a desired valu= e.
>
> [*] - Background: the model allows for a local verifier that check= s code
> measurements against a set of known valid measurements before allo= wing
> it to run. This effective prevents code with known vulnerabilities= from
> running and establishes a trustworthy base to build upon as long a= s you
> can trust the verifier (done via chain of trust.)  As Marcus = correctly
> points out this doesn't catch unknown vulnerabilities.  The T= CG
> technology that I know of doesn't do behavioral checking although = such
> technologies do exist and watch for zero-day attacks as we speak. =  You
> could imagine that these could be integrated and will evolve over = time.
>
> >
> >
> > 3) How does the Posture Validator get that list of PCR values=
> >    for known good configurations?
> >
> >    Typically from a subscription service that maint= ains a
> >    list of PCR values for various versions of softw= are from
> >    all the major vendors. The decision about which = software
> >    versions are "good" is a policy decisi= on generally left
> >    to the network owner.
> >
> > You have to assume that a compromised system would be able to= maintain
> >   a consistently-idyllic view using some similar type of=
> > "subscription service".
> >   Essentially, a compromised system can continue to upda= te
> > the view of the
> >   world it wishes to present to the TCG subsystems. &nbs= p;The
> > *reality*, however,
> >   will be quite different.
>
> Same comment as above.  How does the malware reset the PCRs b= ack to the
> idyllic values so future attestations comes up clean?  Most o= f the PCRs
> do not allow "set" type of operations, so this means the= malware
> couldn't use the TPM signed set of PCR values to spoof the verifie= r (nor
> could it use the TPM's cert since it lacks access to the private k= ey to
> quote (sign) the incorrect pseudo-PCRs.)
>
> >  
> >
> > 4) Won't this prevent me from using my favorite OS?
> >
> >    That depends on your network's policy. If you do= n't like
> >    their policy, you're free to shop around. Rememb= er that
> >    the TPM is an optional component and comes disab= led. You
> >    can just leave it disabled. Or you can run your = favorite
> >    OS within an untrusted application. Or you can h= ave an
> >    untrusted application forward packets from your = favorite OS.
> >    Anyway, those subscription services aren't cheap= . Trusted
> >    boot will probably be mainly deployed in high-se= curity
> >    environments.
> >
> > There's also the scenario of a NAT-like device in a
> > TCG/TPM/NAP/NAC/whatever
> >   world.  You have a "policy-compliant" s= ystem act as a proxy
> > for a pool
> >   of non-compliant nodes.  "Fixing" that = kind of scenario
> > tends to produce
> >   a system that is unusable for ordinary use.  Perf= ectly
> > secure, and utterly
> >   unusable.
>
> Not sure I follow.  Are you referring to the tunneling attack= discussed
> in the TNC's IF-T specification or a true proxy?  In the true= proxy
> case, the proxies should show up in the list of measurements requi= red by
> the verifier and the verifier's policy DB shouldn't allow this
= > configuration.  For the nested tunnel attack, there are alrea= dy
> suggested countermeasures and work is underway for more (not
> unsolvable.)
>
> Was your comment about "fixing" the proxy case meaning t= hat systems need
> to be able to run such software or else they aren't useful?  = Maybe you
> could explain more about your thinking?
>
> >
> > 5) How does this let the server detect endpoint compromise? > >
> >    If a trusted software component on the endpoint = has been
> >    compromised, that will show up as a PCR with an = unrecognized
> >    value. Because the TPM hashes the software befor= e it's run
> >    and won't let the software zero the PCR (and bec= ause the
> >    hash is preimage resistant), the compromised sof= tware can't
> >    get the TPM to report a valid PCR value. And it = can't
> >    replay an old PCR value because of the nonce. > >
> > That only applies to "compromised on disk".  T= he state of
> > said software
> >   at some time T after it has begun executing *cannot* b= e attested-to
> >   by anything.  If that were possible, then it woul= d imply having a
> >   general solution to the halting problem.  In fact= , even the
> > known-good
> >   PCR values are only attesting to the fact that the sof= tware
> > is known to
> >   be resistant to all the vulnerabilities we *know about= * in
> > the software.
> >   With the emergence of zero-day exploits of vulnerabili= ties, I wonder
> >   how useful this will actually be.
>
> Without trying to solve the halting problem you can introduce mech= anisms
> to help raise the security level of the system.  Is this usel= ess to try
> unless they are foolproof?  There are an endless list of secu= rity
> mechanisms which can't address this issue (bug in an IKE implement= ation
> leaks phase 2 keys, buffer overflow of a privileged daemon and now= we
> can change TLS trust anchors, timing attack against processor cach= es and
> you can learn OpenSSL private keys ...)  I agree it's a hard = problem but
> hope we don't let it stop progress.  People are working (and = shipping)
> technologies to try to catch zero-day exploits and these could be<= br> > integrated with other system integrity protection features to rais= e the
> bar as best we can without waking Mr Turing :).
>
> If a system measured all software as its loaded and check it was c= lean
> against known vulnerabilities, recorded the measurement in a TPM (= or
> tamperproof environment) and created a measurement log, used AV an= d
> behavioral techniques to watch for viruses in running code, ... an= d was
> able to produce an attestation of all of this and the
> configurations/databases it used in a non-spoofable way, this seem= s to
> be better then we have today.  Add in support for separate pr= otection
> domains to isolate security mechanisms (and logs) and we seem to b= e
> raising the bar.
>
> Of course this isn't TNC, but its something orthogonal that people= in
> the industry are working on and seems to fit in with what is being=
> planned.  Such integrity mechanisms could offer a Posture
= > Collector/Verifier pair to fit into the NEA model.
>
> >    
> > 6) Aren't there ways to attack this system?
> >
> >    Yes. You can break the system if you can success= fully attack
> >    any one of these: the TPM (with physical attacks= or by finding
> >    flaws in it), the CAs that signed the TPM's cert= ificates (or
> >    their operators), the trusted software that's li= sted in the
> >    known good configs, the cryptographic algorithms= and protocols
> >    involved, or the Network Enforcer or the NEA ser= ver or their
> >    operators. There's also a clever attack describe= d in Appendix A
> >    of the TNC IF-T document. Countermeasures for th= at attack are
> >    given in that document.
> >
> >    I have omitted some attacks for which countermea= sures are
> >    available. If you have other attacks you're inte= rested in,
> >    please raise them and I'd be glad to address the= m.
> >
> > 7) Won't there inevitably be vulnerabilities in the trusted s= oftware?
> >
> >    Yes. That's true today. It will probably always = be true.
> > The best way
> >    to handle it is to reduce the number of vulnerab= ilities by making
> >    the trusted software as small and secure as poss= ible. Beyond that,
> >    identify vulnerabilities as soon as possible (pr= eferably before
> >    exploits are available), prepare fixes, and then= remove
> > the old buggy
> >    software from the list of known good configurati= ons (or
> > move it to a
> >    list of configurations that require quarantine a= nd mandatory
> >    remediation).
> >
> > The problem is that *real* generally-useful computing
> > environments are still
> >   going to have very large components that have to be tr= usted
> > to behave
> >   correctly at all times.   If you have an operatin= g system
> > that has all
> > those
> >   desirable properties, then you don't need any of this =
> > TPM/TNC/NEA/TCG goop.
>
> Ah, but this means that we do need TPM/TNC/NEA/TCG goop :).  = Clearly
> big, complex software will have security bugs that will get fixed = and
> patches released.  Hopefully NEA will help get the lack of th= ose patches
> recognized and distributed more quickly (being more centrally
> controlled) but will need new measurement policies provisioned qui= ckly.
>
> >
> > The raison d'etre for this stuff is precisely because
> > operating systems today
> >   are vulnerable due to a large number of factors, inclu= ding
> > broken architectures,
> >   programming language design, human frailty, etc, etc. =  And
> > it is precisely because
> >   of that that this stuff can't be made to work, for any=
> > sufficiently-rigorous
> >   definition of the word "work".
> >
> > The bad guys are getting cleverer, and a large fraction of > > the "good guys" haven't
> >   actually done any detailed analysis of all this
> > TCG/TNC/TPM/NEA stuff yet.
>
> Having an NEA WG just helps bring exposure to this area so more de= tailed
> analysis can be performed and we can improve the situation.  = The
> TCG/TNC/TPM specs are public so can be reviewed.  Their have = been a
> number of good cryptographers and security people who have reviewe= d the
> TCG stuff but it's a work in progress so hopefully this momentum w= ill
> continue.
>
> >   I fully expect that there will be gaping holes found w= ithin
> > two years.
>
> That's why we have version 2 :).  History is certainly on you= r side
> (SSHv1, SSLv1, Kerberos v4, ...) have all needed updates to improv= e
> based on holes, I'm sure this will be the same.
>
> >
> > I'd be perfectly delighted to be proven wrong.
>
> Sorry but you'll still have a job for a few more years :).
>
> >
> >
> > _______________________________________________
> > Nea mailing list
> > Nea@ietf.org
> > https:= //www1.ietf.org/mailman/listinfo/nea
> >
>
> _______________________________________________
> Nea mailing list
> Nea@ietf.org
> https://www= 1.ietf.org/mailman/listinfo/nea
= --0__=07BBFBE9DF90807D8f9e8a93df938690918c07BBFBE9DF90807D-- --===============0688899630== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea --===============0688899630==-- From nea-bounces@ietf.org Thu May 25 21:28:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjR7X-0006p0-24; Thu, 25 May 2006 21:28:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjR7V-0006mv-Oh for nea@ietf.org; Thu, 25 May 2006 21:28:05 -0400 Received: from silver.veritas.com ([143.127.12.111]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjR7U-0006pj-7D for nea@ietf.org; Thu, 25 May 2006 21:28:05 -0400 Received: from sxchcon1-int.veritas.com (HELO SVLXCHCON1.enterprise.veritas.com) ([10.137.18.171]) by silver.veritas.com with ESMTP; 25 May 2006 18:27:58 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.05,174,1146466800"; d="scan'208,217"; a="38534723:sNHT56880924" Received: from SVL1XCHEVSPIN01.enterprise.veritas.com ([166.98.169.10]) by SVLXCHCON1.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 25 May 2006 18:27:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Nea] RE: Detecting Compromised Endpoints Date: Thu, 25 May 2006 18:27:56 -0700 Message-ID: <5A58F967CBEBBB4A82DF126CF8A9596AF0A608@SVL1XCHCLUPIN01.enterprise.veritas.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] RE: Detecting Compromised Endpoints Thread-Index: AcaAX0TrL99GPPxqS+CVCeGA8HtbkQAAtAiQ From: "Paul Sangster" To: "Frank Yeh Jr" X-OriginalArrivalTime: 26 May 2006 01:27:57.0879 (UTC) FILETIME=[9EAB6C70:01C68063] X-Spam-Score: 0.5 (/) X-Scan-Signature: e233469409eae36784776b094a259e13 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: , Content-Type: multipart/mixed; boundary="===============0717849877==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============0717849877== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C68063.9E65F53C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C68063.9E65F53C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Comments below with [PS] prefix... ________________________________ From: Frank Yeh Jr [mailto:fyeh@us.ibm.com]=20 Sent: Thursday, May 25, 2006 5:57 PM To: Paul Sangster Cc: Marcus Leech; nea@ietf.org; Stephen Hanna Subject: RE: [Nea] RE: Detecting Compromised Endpoints =09 =09 Greetings, =09 I am a little confused by this thread as it seems to me to be out of scope with the NEA work. Perhaps I added to the confusion by mentioning in a previous post that NEA could leverage trusted hardware. For that, I am sorry (well, sort of). [PS] Yes we blame you :).=20 =09 So my impression of the NEA charter is that the procotol will be about format, aggregation, and transport of Posture information. There does not seem to be anything related to establishing trust of the various components that use the procotol. However, it would be valid to use the NEA protocols to enable a single collector/validator pair that would attest to the integrity of all other components. I do not see why this should be part of the NEA protocols themselves. [PS] Correct, NEA is initially about the higher level protocols (PA, PB) and requirements on the transport (PT.) I believe this thread arose by people questioning the usefulness of NEA considering it could be circumvented by malware if a catastrophic system breach occurred on the NEA Client. It was posed that orthogonal integrity protection might be on the system to protect the NEA components. =09 This thread probably has to do with the many TCG-aware people participating in NEA, but I think that is confusing the issue. However, since I said TCG, I would point out that the TNC specs and the PTS spec are separate. Why then are we talking about combining these functions in NEA? [PS] We're not talking about combining them (note PTS spec isn't public yet), their was just an interest in discussing how the NEA mechanisms could be protected from malware tricking them into mis-reporting the platform state (or a NEA component just lying.) The TCG mechanisms might be completely orthogonal to NEA or might report using the NEA protocols showing NEA is useful for a number of contexts. =09 Regards, Frank Yeh Corporate Security Strategy Team IBM Tivoli Software =09 =09 "Paul Sangster" wrote on 05/25/2006 03:39:02 PM: =09 >=20 > Discussions like these make me wonder what the automotive safety > engineers must have discussed when the idea of the: seat belt, air bag, > crumple zones ... were being considered :). How many lives do we need > to save to make it useful ... >=20 > Hopefully we wouldn't pass on doing NEA because its not a panacea for > security (its not.) NEA itself doesn't try to solve the problems of > this thread, we're merely discussing if they might be orthogonal > mechanisms to help prevent the collector from mis-reporting the > situation. Putting a spotlight on the desire to report configuration > should help bring focus to protecting the collection/reporting > mechanisms. >=20 > So with that said, let go into the interesting dialog. Clearly you've > raised very interesting and challenging issues that most (all?) of our > other standards couldn't live up to (fortunately, there are threat > models to save the day by scoping them out :)) >=20 > > -----Original Message----- > > From: Marcus Leech [mailto:mleech@nortel.com]=20 > > Sent: Thursday, May 25, 2006 11:20 AM > > To: Stephen Hanna; nea@ietf.org > > Subject: RE: [Nea] RE: Detecting Compromised Endpoints > >=20 > >=20 > >=20 > > 1) What needs to be measured? > >=20 > > All the trusted code on the endpoint needs to be measured. > > That includes all the software and firmware in the Trusted > > Computing Base, any code whose compromise would potentially > > cause the system to violate its security policies. This > > includes the BIOS, the boot loader, the OS kernel, the > > kernel drivers, etc. If the operating system is well written, > > it should not include application code since that code > > cannot cause the system to violate its security policies. > >=20 > > The essential problem is that for any *practical* operating system for > > purposes of general-purpose computing, there *is* application code, > > the compromise of which, can cause the system to violate=20 > > its security > > policies. >=20 > Sure, privileged code also runs in applications so the kernel doesn't > need to contain everything. Ideally OSes would limit privileges > (ability to bypass some security check) more granularly (e.g. Solaris > 10's privilege model) but many do not or the granularity isn't used so > point taken. >=20 > I think one of the areas of discussion around the use of TCG > verification is how to enable product vendors (or 3rd party "integrity" > oriented vendors) to define trust dependency trees so that verifiers can > determine what set of component measurements it needs to verify to feel > safe trusting the requesting system for a particular purpose. For many > use cases, only portions of the machine need to be checked (e.g when > your just trusting a browser session so need to check the kernel, > privileged apps and things relied upon by the brower. >=20 > I don't think this is an unsolvable problem, just a hard one. We need > an ongoing dialog to understand what is running on the requesting system > that needs to be trusted and traverse its trust dependency tree. For > NEA this might be the kernel plus the set of privileged apps and some > security configuration information or it might involve checking a > special security partition + hypervisor (depending on the system > architecture.) >=20 > >=20 > > The only thing the hash does is to assert that the code is=20 > > free from any > > *known* vulnerabilities. Once the system is compromised,=20 > > it can continue > > to provide an idyllic view to the TPM/PCR machinery. >=20 > The hash just records that a particular image of code was run on the > system (so it could later or immediately be verified [*]) in a way that > can't be hidden. The TPM only allows "extends" to the PCR so trusted > apps can effectively add to the values but not remove prior entries. > The meta-data about each extend is stored in a measurement log and is > used for verification. A rootkit might be able to alter the measurement > log but to hide its existance but it wouldn't be able to change the PCRs > to erase its measurement. >=20 > The way the TPM is used it has the capability of signing the PCRs with a > private key for a particular attestation to a verifier. The verifier > needs an equivalent measurement log (history of the PCR) to verify that > it correctly recomputes the aggregate current value stored in the PCR(s) > and can verify the meta-data makes sense and is considered valid by > policy. I'm not sure how malware that was measured into a PCR could > hide its presence without resetting the PCR back to a desired value. >=20 > [*] - Background: the model allows for a local verifier that checks code > measurements against a set of known valid measurements before allowing > it to run. This effective prevents code with known vulnerabilities from > running and establishes a trustworthy base to build upon as long as you > can trust the verifier (done via chain of trust.) As Marcus correctly > points out this doesn't catch unknown vulnerabilities. The TCG > technology that I know of doesn't do behavioral checking although such > technologies do exist and watch for zero-day attacks as we speak. You > could imagine that these could be integrated and will evolve over time. >=20 > >=20 > >=20 > > 3) How does the Posture Validator get that list of PCR values > > for known good configurations? > >=20 > > Typically from a subscription service that maintains a > > list of PCR values for various versions of software from > > all the major vendors. The decision about which software > > versions are "good" is a policy decision generally left > > to the network owner. > >=20 > > You have to assume that a compromised system would be able to maintain > > a consistently-idyllic view using some similar type of=20 > > "subscription service". > > Essentially, a compromised system can continue to update=20 > > the view of the > > world it wishes to present to the TCG subsystems. The=20 > > *reality*, however, > > will be quite different. >=20 > Same comment as above. How does the malware reset the PCRs back to the > idyllic values so future attestations comes up clean? Most of the PCRs > do not allow "set" type of operations, so this means the malware > couldn't use the TPM signed set of PCR values to spoof the verifier (nor > could it use the TPM's cert since it lacks access to the private key to > quote (sign) the incorrect pseudo-PCRs.) >=20 > > =20 > >=20 > > 4) Won't this prevent me from using my favorite OS? > >=20 > > That depends on your network's policy. If you don't like > > their policy, you're free to shop around. Remember that > > the TPM is an optional component and comes disabled. You > > can just leave it disabled. Or you can run your favorite > > OS within an untrusted application. Or you can have an > > untrusted application forward packets from your favorite OS. > > Anyway, those subscription services aren't cheap. Trusted > > boot will probably be mainly deployed in high-security > > environments. > >=20 > > There's also the scenario of a NAT-like device in a=20 > > TCG/TPM/NAP/NAC/whatever > > world. You have a "policy-compliant" system act as a proxy=20 > > for a pool > > of non-compliant nodes. "Fixing" that kind of scenario=20 > > tends to produce > > a system that is unusable for ordinary use. Perfectly=20 > > secure, and utterly > > unusable. >=20 > Not sure I follow. Are you referring to the tunneling attack discussed > in the TNC's IF-T specification or a true proxy? In the true proxy > case, the proxies should show up in the list of measurements required by > the verifier and the verifier's policy DB shouldn't allow this > configuration. For the nested tunnel attack, there are already > suggested countermeasures and work is underway for more (not > unsolvable.) >=20 > Was your comment about "fixing" the proxy case meaning that systems need > to be able to run such software or else they aren't useful? Maybe you > could explain more about your thinking? >=20 > >=20 > > 5) How does this let the server detect endpoint compromise? > >=20 > > If a trusted software component on the endpoint has been > > compromised, that will show up as a PCR with an unrecognized > > value. Because the TPM hashes the software before it's run > > and won't let the software zero the PCR (and because the > > hash is preimage resistant), the compromised software can't > > get the TPM to report a valid PCR value. And it can't > > replay an old PCR value because of the nonce. > >=20 > > That only applies to "compromised on disk". The state of=20 > > said software > > at some time T after it has begun executing *cannot* be attested-to > > by anything. If that were possible, then it would imply having a > > general solution to the halting problem. In fact, even the=20 > > known-good > > PCR values are only attesting to the fact that the software=20 > > is known to > > be resistant to all the vulnerabilities we *know about* in > > the software. > > With the emergence of zero-day exploits of vulnerabilities, I wonder > > how useful this will actually be. >=20 > Without trying to solve the halting problem you can introduce mechanisms > to help raise the security level of the system. Is this useless to try > unless they are foolproof? There are an endless list of security > mechanisms which can't address this issue (bug in an IKE implementation > leaks phase 2 keys, buffer overflow of a privileged daemon and now we > can change TLS trust anchors, timing attack against processor caches and > you can learn OpenSSL private keys ...) I agree it's a hard problem but > hope we don't let it stop progress. People are working (and shipping) > technologies to try to catch zero-day exploits and these could be > integrated with other system integrity protection features to raise the > bar as best we can without waking Mr Turing :). >=20 > If a system measured all software as its loaded and check it was clean > against known vulnerabilities, recorded the measurement in a TPM (or > tamperproof environment) and created a measurement log, used AV and > behavioral techniques to watch for viruses in running code, ... and was > able to produce an attestation of all of this and the > configurations/databases it used in a non-spoofable way, this seems to > be better then we have today. Add in support for separate protection > domains to isolate security mechanisms (and logs) and we seem to be > raising the bar. >=20 > Of course this isn't TNC, but its something orthogonal that people in > the industry are working on and seems to fit in with what is being > planned. Such integrity mechanisms could offer a Posture > Collector/Verifier pair to fit into the NEA model. >=20 > > =20 > > 6) Aren't there ways to attack this system? > >=20 > > Yes. You can break the system if you can successfully attack > > any one of these: the TPM (with physical attacks or by finding > > flaws in it), the CAs that signed the TPM's certificates (or > > their operators), the trusted software that's listed in the > > known good configs, the cryptographic algorithms and protocols > > involved, or the Network Enforcer or the NEA server or their > > operators. There's also a clever attack described in Appendix A > > of the TNC IF-T document. Countermeasures for that attack are > > given in that document. > >=20 > > I have omitted some attacks for which countermeasures are > > available. If you have other attacks you're interested in, > > please raise them and I'd be glad to address them. > >=20 > > 7) Won't there inevitably be vulnerabilities in the trusted software? > >=20 > > Yes. That's true today. It will probably always be true.=20 > > The best way > > to handle it is to reduce the number of vulnerabilities by making > > the trusted software as small and secure as possible. Beyond that, > > identify vulnerabilities as soon as possible (preferably before > > exploits are available), prepare fixes, and then remove=20 > > the old buggy > > software from the list of known good configurations (or=20 > > move it to a > > list of configurations that require quarantine and mandatory > > remediation). > >=20 > > The problem is that *real* generally-useful computing=20 > > environments are still > > going to have very large components that have to be trusted=20 > > to behave > > correctly at all times. If you have an operating system=20 > > that has all > > those > > desirable properties, then you don't need any of this=20 > > TPM/TNC/NEA/TCG goop. >=20 > Ah, but this means that we do need TPM/TNC/NEA/TCG goop :). Clearly > big, complex software will have security bugs that will get fixed and > patches released. Hopefully NEA will help get the lack of those patches > recognized and distributed more quickly (being more centrally > controlled) but will need new measurement policies provisioned quickly.=20 >=20 > >=20 > > The raison d'etre for this stuff is precisely because=20 > > operating systems today > > are vulnerable due to a large number of factors, including > > broken architectures, > > programming language design, human frailty, etc, etc. And > > it is precisely because > > of that that this stuff can't be made to work, for any=20 > > sufficiently-rigorous > > definition of the word "work". > >=20 > > The bad guys are getting cleverer, and a large fraction of=20 > > the "good guys" haven't > > actually done any detailed analysis of all this=20 > > TCG/TNC/TPM/NEA stuff yet. >=20 > Having an NEA WG just helps bring exposure to this area so more detailed > analysis can be performed and we can improve the situation. The > TCG/TNC/TPM specs are public so can be reviewed. Their have been a > number of good cryptographers and security people who have reviewed the > TCG stuff but it's a work in progress so hopefully this momentum will > continue. >=20 > > I fully expect that there will be gaping holes found within=20 > > two years. >=20 > That's why we have version 2 :). History is certainly on your side > (SSHv1, SSLv1, Kerberos v4, ...) have all needed updates to improve > based on holes, I'm sure this will be the same. >=20 > >=20 > > I'd be perfectly delighted to be proven wrong. >=20 > Sorry but you'll still have a job for a few more years :). >=20 > >=20 > >=20 > > _______________________________________________ > > Nea mailing list > > Nea@ietf.org > > https://www1.ietf.org/mailman/listinfo/nea > >=20 >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea =09 ------_=_NextPart_001_01C68063.9E65F53C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Comments below with [PS]=20 prefix...

From: Frank Yeh Jr = [mailto:fyeh@us.ibm.com]=20
Sent: Thursday, May 25, 2006 5:57 PM
To: Paul=20 Sangster
Cc: Marcus Leech; nea@ietf.org; Stephen=20 Hanna
Subject: RE: [Nea] RE: Detecting Compromised=20 Endpoints

Greetings,

I am a little confused by this thread as it seems = to me=20 to be out of scope with the NEA work. Perhaps I added to the confusion = by=20 mentioning in a previous post that NEA could leverage trusted = hardware. For=20 that, I am sorry (well, sort of).
[PS] Yes we blame you=20 :). 

So my impression of the NEA charter is = that the=20 procotol will be about format, aggregation, and transport of Posture=20 information. There does not seem to be anything related to = establishing trust=20 of the various components that use the procotol. However, it would be = valid to=20 use the NEA protocols to enable a single collector/validator pair that = would=20 attest to the integrity of all other components. I do not see why this = should=20 be part of the NEA protocols themselves.
[PS] Correct, NEA is initially about the higher = level=20 protocols (PA, PB) and requirements on the transport (PT.)  I=20 believe this thread arose by people questioning the usefulness of = NEA=20 considering it could be circumvented by malware if a catastrophic = system=20 breach occurred on the NEA Client.  It was posed that orthogonal=20 integrity protection might be on the system to protect the NEA=20 components.

This thread probably has to do with = the many=20 TCG-aware people participating in NEA, but I think that is confusing = the=20 issue. However, since I said TCG, I would point out that the TNC specs = and the=20 PTS spec are separate. Why then are we talking about combining these = functions=20 in NEA?
[PS] We're not talking about combining them (note PTS=20 spec isn't public yet), their was just an interest in discussing = how the=20 NEA mechanisms could be protected from malware tricking them into=20 mis-reporting the platform state (or a NEA component just = lying.)  The=20 TCG mechanisms might be completely orthogonal to NEA or might report = using the=20 NEA protocols showing NEA is useful for a number of=20 contexts.

Regards,
Frank Yeh
Corporate = Security=20 Strategy Team
IBM
Tivoli Software


"Paul Sangster" = <Paul_Sangster@symantec.com> wrote on 05/25/2006 03:39:02=20 PM:

>
> Discussions like these make me wonder what = the=20 automotive safety
> engineers must have discussed when the idea = of the:=20 seat belt, air bag,
> crumple zones ... were being considered = :).=20  How many lives do we need
> to save to make it useful = ...
>=20
> Hopefully we wouldn't pass on doing NEA because its not a = panacea=20 for
> security (its not.)  NEA itself doesn't try to solve = the=20 problems of
> this thread, we're merely discussing if they might = be=20 orthogonal
> mechanisms to help prevent the collector from = mis-reporting=20 the
> situation.   Putting a spotlight on the desire to = report=20 configuration
> should help bring focus to protecting the=20 collection/reporting
> mechanisms.
>
> So with that = said,=20 let go into the interesting dialog.  Clearly you've
> = raised very=20 interesting and challenging issues that most (all?) of our
> = other=20 standards couldn't live up to (fortunately, there are threat
> = models to=20 save the day by scoping them out :))
>
> > = -----Original=20 Message-----
> > From: Marcus Leech [mailto:mleech@nortel.com] =
> >=20 Sent: Thursday, May 25, 2006 11:20 AM
> > To: Stephen Hanna;=20 nea@ietf.org
> > Subject: RE: [Nea] RE: Detecting Compromised = Endpoints
> >
> >
> >
> > 1) = What needs=20 to be measured?
> >
> >    All the = trusted code=20 on the endpoint needs to be measured.
> >    That = includes=20 all the software and firmware in the Trusted
> >  =20  Computing Base, any code whose compromise would = potentially
> >=20    cause the system to violate its security policies. = This
>=20 >    includes the BIOS, the boot loader, the OS kernel,=20 the
> >    kernel drivers, etc. If the operating = system is=20 well written,
> >    it should not include = application code=20 since that code
> >    cannot cause the system to = violate=20 its security policies.
> >
> > The essential = problem is=20 that for any *practical* operating system for
> >   = purposes of=20 general-purpose computing, there *is* application code,
> > =  =20 the compromise of which, can cause the system to violate
> > = its=20 security
> >   policies.
>
> Sure, = privileged code=20 also runs in applications so the kernel doesn't
> need to = contain=20 everything.  Ideally OSes would limit privileges
> (ability = to=20 bypass some security check) more granularly (e.g. Solaris
> 10's = privilege model) but many do not or the granularity isn't used = so
>=20 point taken.
>
> I think one of the areas of discussion = around=20 the use of TCG
> verification is how to enable product vendors = (or 3rd=20 party "integrity"
> oriented vendors) to define trust dependency = trees=20 so that verifiers can
> determine what set of component = measurements it=20 needs to verify to feel
> safe trusting the requesting system = for a=20 particular purpose.  For many
> use cases, only portions of = the=20 machine need to be checked (e.g when
> your just trusting a = browser=20 session so need to check the kernel,
> privileged apps and = things relied=20 upon by the brower.
>
> I don't think this is an = unsolvable=20 problem, just a hard one.  We need
> an ongoing dialog to=20 understand what is running on the requesting system
> that needs = to be=20 trusted and traverse its trust dependency tree.  For
> NEA = this=20 might be the kernel plus the set of privileged apps and some
> = security=20 configuration information or it might involve checking a
> = special=20 security partition + hypervisor (depending on the system
>=20 architecture.)
>
> >
> > The only thing the = hash=20 does is to assert that the code is
> > free from any
> = >=20   *known* vulnerabilities.  Once the system is compromised, =
>=20 > it can continue
> >   to provide an idyllic view to = the=20 TPM/PCR machinery.
>
> The hash just records that a = particular=20 image of code was run on the
> system (so it could later or = immediately=20 be verified [*]) in a way that
> can't be hidden.  The TPM = only=20 allows "extends" to the PCR so trusted
> apps can effectively = add to the=20 values but not remove prior entries.
> The meta-data about each = extend=20 is stored in a measurement log and is
> used for verification. =  A=20 rootkit might be able to alter the measurement
> log but to hide = its=20 existance but it wouldn't be able to change the PCRs
> to erase = its=20 measurement.
>
> The way the TPM is used it has the = capability of=20 signing the PCRs with a
> private key for a particular = attestation to a=20 verifier.  The verifier
> needs an equivalent measurement = log=20 (history of the PCR) to verify that
> it correctly recomputes = the=20 aggregate current value stored in the PCR(s)
> and can verify = the=20 meta-data makes sense and is considered valid by
> policy. =  I'm not=20 sure how malware that was measured into a PCR could
> hide its = presence=20 without resetting the PCR back to a desired value.
>
> = [*] -=20 Background: the model allows for a local verifier that checks = code
>=20 measurements against a set of known valid measurements before = allowing
>=20 it to run. This effective prevents code with known vulnerabilities=20 from
> running and establishes a trustworthy base to build upon = as long=20 as you
> can trust the verifier (done via chain of trust.) =  As=20 Marcus correctly
> points out this doesn't catch unknown=20 vulnerabilities.  The TCG
> technology that I know of = doesn't do=20 behavioral checking although such
> technologies do exist and = watch for=20 zero-day attacks as we speak.  You
> could imagine that = these could=20 be integrated and will evolve over time.
>
> > =
> >=20
> > 3) How does the Posture Validator get that list of PCR=20 values
> >    for known good = configurations?
> >=20
> >    Typically from a subscription service that=20 maintains a
> >    list of PCR values for various = versions=20 of software from
> >    all the major vendors. The = decision=20 about which software
> >    versions are "good" is = a policy=20 decision generally left
> >    to the network=20 owner.
> >
> > You have to assume that a = compromised system=20 would be able to maintain
> >   a consistently-idyllic = view=20 using some similar type of
> > "subscription = service".
> >=20   Essentially, a compromised system can continue to update =
> >=20 the view of the
> >   world it wishes to present to the = TCG=20 subsystems.  The
> > *reality*, however,
> > =  =20 will be quite different.
>
> Same comment as above. =  How=20 does the malware reset the PCRs back to the
> idyllic values so = future=20 attestations comes up clean?  Most of the PCRs
> do not = allow "set"=20 type of operations, so this means the malware
> couldn't use the = TPM=20 signed set of PCR values to spoof the verifier (nor
> could it = use the=20 TPM's cert since it lacks access to the private key to
> quote = (sign)=20 the incorrect pseudo-PCRs.)
>
> >  
> > =
>=20 > 4) Won't this prevent me from using my favorite OS?
> > =
>=20 >    That depends on your network's policy. If you don't=20 like
> >    their policy, you're free to shop = around.=20 Remember that
> >    the TPM is an optional = component and=20 comes disabled. You
> >    can just leave it = disabled. Or=20 you can run your favorite
> >    OS within an = untrusted=20 application. Or you can have an
> >    untrusted=20 application forward packets from your favorite OS.
> >   =  Anyway, those subscription services aren't cheap. = Trusted
> >=20    boot will probably be mainly deployed in = high-security
>=20 >    environments.
> >
> > There's = also the=20 scenario of a NAT-like device in a
> >=20 TCG/TPM/NAP/NAC/whatever
> >   world.  You have a=20 "policy-compliant" system act as a proxy
> > for a = pool
> >=20   of non-compliant nodes.  "Fixing" that kind of scenario =
>=20 > tends to produce
> >   a system that is unusable = for=20 ordinary use.  Perfectly
> > secure, and = utterly
> >=20   unusable.
>
> Not sure I follow.  Are you = referring=20 to the tunneling attack discussed
> in the TNC's IF-T = specification or a=20 true proxy?  In the true proxy
> case, the proxies should = show up=20 in the list of measurements required by
> the verifier and the=20 verifier's policy DB shouldn't allow this
> configuration. =  For the=20 nested tunnel attack, there are already
> suggested = countermeasures and=20 work is underway for more (not
> unsolvable.)
>
> = Was your=20 comment about "fixing" the proxy case meaning that systems = need
> to be=20 able to run such software or else they aren't useful?  Maybe = you
>=20 could explain more about your thinking?
>
> >
> = > 5)=20 How does this let the server detect endpoint compromise?
> > =
>=20 >    If a trusted software component on the endpoint has=20 been
> >    compromised, that will show up as a PCR = with an=20 unrecognized
> >    value. Because the TPM hashes = the=20 software before it's run
> >    and won't let the = software=20 zero the PCR (and because the
> >    hash is = preimage=20 resistant), the compromised software can't
> >   =  get the=20 TPM to report a valid PCR value. And it can't
> >   =  replay=20 an old PCR value because of the nonce.
> >
> > That = only=20 applies to "compromised on disk".  The state of
> > = said=20 software
> >   at some time T after it has begun = executing=20 *cannot* be attested-to
> >   by anything.  If that = were=20 possible, then it would imply having a
> >   general = solution to=20 the halting problem.  In fact, even the
> > = known-good
>=20 >   PCR values are only attesting to the fact that the = software=20
> > is known to
> >   be resistant to all the=20 vulnerabilities we *know about* in
> > the software.
> = >=20   With the emergence of zero-day exploits of vulnerabilities, I=20 wonder
> >   how useful this will actually be.
> =
>=20 Without trying to solve the halting problem you can introduce=20 mechanisms
> to help raise the security level of the system. =  Is=20 this useless to try
> unless they are foolproof?  There are = an=20 endless list of security
> mechanisms which can't address this = issue=20 (bug in an IKE implementation
> leaks phase 2 keys, buffer = overflow of a=20 privileged daemon and now we
> can change TLS trust anchors, = timing=20 attack against processor caches and
> you can learn OpenSSL = private keys=20 ...)  I agree it's a hard problem but
> hope we don't let = it stop=20 progress.  People are working (and shipping)
> technologies = to try=20 to catch zero-day exploits and these could be
> integrated with = other=20 system integrity protection features to raise the
> bar as best = we can=20 without waking Mr Turing :).
>
> If a system measured all = software as its loaded and check it was clean
> against known=20 vulnerabilities, recorded the measurement in a TPM (or
> = tamperproof=20 environment) and created a measurement log, used AV and
> = behavioral=20 techniques to watch for viruses in running code, ... and was
> = able to=20 produce an attestation of all of this and the
> = configurations/databases=20 it used in a non-spoofable way, this seems to
> be better then = we have=20 today.  Add in support for separate protection
> domains to = isolate=20 security mechanisms (and logs) and we seem to be
> raising the=20 bar.
>
> Of course this isn't TNC, but its something = orthogonal=20 that people in
> the industry are working on and seems to fit in = with=20 what is being
> planned.  Such integrity mechanisms could = offer a=20 Posture
> Collector/Verifier pair to fit into the NEA = model.
>=20
> >    
> > 6) Aren't there ways to = attack this=20 system?
> >
> >    Yes. You can break the = system=20 if you can successfully attack
> >    any one of = these: the=20 TPM (with physical attacks or by finding
> >   =  flaws in=20 it), the CAs that signed the TPM's certificates (or
> > =  =20  their operators), the trusted software that's listed in = the
> >=20    known good configs, the cryptographic algorithms and=20 protocols
> >    involved, or the Network Enforcer = or the=20 NEA server or their
> >    operators. There's also = a clever=20 attack described in Appendix A
> >    of the TNC = IF-T=20 document. Countermeasures for that attack are
> >   =  given=20 in that document.
> >
> >    I have = omitted some=20 attacks for which countermeasures are
> >   =  available. If=20 you have other attacks you're interested in,
> >   =  please=20 raise them and I'd be glad to address them.
> >
> > = 7)=20 Won't there inevitably be vulnerabilities in the trusted = software?
>=20 >
> >    Yes. That's true today. It will = probably=20 always be true.
> > The best way
> >   =  to handle=20 it is to reduce the number of vulnerabilities by making
> > =  =20  the trusted software as small and secure as possible. Beyond=20 that,
> >    identify vulnerabilities as soon as = possible=20 (preferably before
> >    exploits are available), = prepare=20 fixes, and then remove
> > the old buggy
> >   =  software from the list of known good configurations (or
> = >=20 move it to a
> >    list of configurations that = require=20 quarantine and mandatory
> >   =  remediation).
> >=20
> > The problem is that *real* generally-useful computing =
>=20 > environments are still
> >   going to have very = large=20 components that have to be trusted
> > to behave
> = >  =20 correctly at all times.   If you have an operating system =
> >=20 that has all
> > those
> >   desirable = properties, then=20 you don't need any of this
> > TPM/TNC/NEA/TCG goop.
> =
> Ah, but this means that we do need TPM/TNC/NEA/TCG goop :).=20  Clearly
> big, complex software will have security bugs = that will=20 get fixed and
> patches released.  Hopefully NEA will help = get the=20 lack of those patches
> recognized and distributed more quickly = (being=20 more centrally
> controlled) but will need new measurement = policies=20 provisioned quickly.
>
> >
> > The raison = d'etre=20 for this stuff is precisely because
> > operating systems=20 today
> >   are vulnerable due to a large number of = factors,=20 including
> > broken architectures,
> >   = programming=20 language design, human frailty, etc, etc.  And
> > it = is=20 precisely because
> >   of that that this stuff can't be = made to=20 work, for any
> > sufficiently-rigorous
> >  =20 definition of the word "work".
> >
> > The bad guys = are=20 getting cleverer, and a large fraction of
> > the "good = guys"=20 haven't
> >   actually done any detailed analysis of all = this=20
> > TCG/TNC/TPM/NEA stuff yet.
>
> Having an = NEA WG=20 just helps bring exposure to this area so more detailed
> = analysis can=20 be performed and we can improve the situation.  The
> = TCG/TNC/TPM=20 specs are public so can be reviewed.  Their have been a
> = number of=20 good cryptographers and security people who have reviewed the
> = TCG=20 stuff but it's a work in progress so hopefully this momentum = will
>=20 continue.
>
> >   I fully expect that there will = be=20 gaping holes found within
> > two years.
>
> = That's why=20 we have version 2 :).  History is certainly on your side
> = (SSHv1,=20 SSLv1, Kerberos v4, ...) have all needed updates to improve
> = based on=20 holes, I'm sure this will be the same.
>
> >
> = > I'd=20 be perfectly delighted to be proven wrong.
>
> Sorry but = you'll=20 still have a job for a few more years :).
>
> > =
> >=20
> > _______________________________________________
> = > Nea=20 mailing list
> > Nea@ietf.org
> > https://www1.ietf.org= /mailman/listinfo/nea
>=20 >
>
> = _______________________________________________
>=20 Nea mailing list
> Nea@ietf.org
> https://www1.ietf.org= /mailman/listinfo/nea

------_=_NextPart_001_01C68063.9E65F53C-- --===============0717849877== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea --===============0717849877==-- From nea-bounces@ietf.org Fri May 26 00:14:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjTid-0004Yu-Rw; Fri, 26 May 2006 00:14:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjTic-0004Ym-Mi for nea@ietf.org; Fri, 26 May 2006 00:14:34 -0400 Received: from mail.signacert.org ([207.162.214.7] helo=mail.signacert.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjTiZ-0005U4-2l for nea@ietf.org; Fri, 26 May 2006 00:14:34 -0400 Received: from SLEDGEHAMMER.signacert.com (sledgehammer.signacert.com [70.103.105.28]) by mail.signacert.com (Postfix) with ESMTP id 4EC5918EC433; Thu, 25 May 2006 21:14:27 -0700 (PDT) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: RE: [Nea] RE: Detecting Compromised Endpoints MIME-Version: 1.0 Date: Thu, 25 May 2006 21:14:26 -0700 Message-ID: <6874726B1AE3D441A3B4635B527E09B106A3F1@sledgehammer.signacert.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] RE: Detecting Compromised Endpoints Thread-Index: AcaAX1Ji3fYfDP9PR5GPGmUGbPCT/gAGYleg From: "Thomas Hardjono" To: , "Frank Yeh Jr" X-Spam-Score: 0.6 (/) X-Scan-Signature: df82e91619cd4cb8e8215e3592fa9e0b 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: , Content-Type: multipart/mixed; boundary="===============1723593200==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============1723593200== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6807A.E0C9C0CA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6807A.E0C9C0CA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks Frank - yes, you are spot on. =20 My understanding as to how the discussion drifted to trusted hardware arose from some questions in the IETF. =20 Basically, some folks at the IETF were suggesting that we don't bother with NEA because (a) any posture agent on the client can be modified by malware (to then forge posture reports); and (b) They don't believe in trusted hardware or even the possibility of secure systems. =20 The funny thing is that virtually all protocols invented in the IETF is subject to changes by malware in (a). This includes IPsec VPN clients, routing code, NAT boxes, and even the entire IP stack. =20 Perhaps we should just give-up on the Internet :) =20 cheers, =20 /thomas/ =20 =20 ________________________________ From: Frank Yeh Jr [mailto:fyeh@us.ibm.com]=20 Sent: Thursday, May 25, 2006 5:57 PM To: Paul Sangster Cc: nea@ietf.org Subject: RE: [Nea] RE: Detecting Compromised Endpoints Greetings, I am a little confused by this thread as it seems to me to be out of scope with the NEA work. Perhaps I added to the confusion by mentioning in a previous post that NEA could leverage trusted hardware. For that, I am sorry (well, sort of). So my impression of the NEA charter is that the procotol will be about format, aggregation, and transport of Posture information. There does not seem to be anything related to establishing trust of the various components that use the procotol. However, it would be valid to use the NEA protocols to enable a single collector/validator pair that would attest to the integrity of all other components. I do not see why this should be part of the NEA protocols themselves. This thread probably has to do with the many TCG-aware people participating in NEA, but I think that is confusing the issue. However, since I said TCG, I would point out that the TNC specs and the PTS spec are separate. Why then are we talking about combining these functions in NEA? Regards, Frank Yeh Corporate Security Strategy Team IBM Tivoli Software "Paul Sangster" wrote on 05/25/2006 03:39:02 PM: >=20 > Discussions like these make me wonder what the automotive safety > engineers must have discussed when the idea of the: seat belt, air bag, > crumple zones ... were being considered :). How many lives do we need > to save to make it useful ... >=20 > Hopefully we wouldn't pass on doing NEA because its not a panacea for > security (its not.) NEA itself doesn't try to solve the problems of > this thread, we're merely discussing if they might be orthogonal > mechanisms to help prevent the collector from mis-reporting the > situation. Putting a spotlight on the desire to report configuration > should help bring focus to protecting the collection/reporting > mechanisms. >=20 > So with that said, let go into the interesting dialog. Clearly you've > raised very interesting and challenging issues that most (all?) of our > other standards couldn't live up to (fortunately, there are threat > models to save the day by scoping them out :)) >=20 > > -----Original Message----- > > From: Marcus Leech [mailto:mleech@nortel.com]=20 > > Sent: Thursday, May 25, 2006 11:20 AM > > To: Stephen Hanna; nea@ietf.org > > Subject: RE: [Nea] RE: Detecting Compromised Endpoints > >=20 > >=20 > >=20 > > 1) What needs to be measured? > >=20 > > All the trusted code on the endpoint needs to be measured. > > That includes all the software and firmware in the Trusted > > Computing Base, any code whose compromise would potentially > > cause the system to violate its security policies. This > > includes the BIOS, the boot loader, the OS kernel, the > > kernel drivers, etc. If the operating system is well written, > > it should not include application code since that code > > cannot cause the system to violate its security policies. > >=20 > > The essential problem is that for any *practical* operating system for > > purposes of general-purpose computing, there *is* application code, > > the compromise of which, can cause the system to violate=20 > > its security > > policies. >=20 > Sure, privileged code also runs in applications so the kernel doesn't > need to contain everything. Ideally OSes would limit privileges > (ability to bypass some security check) more granularly (e.g. Solaris > 10's privilege model) but many do not or the granularity isn't used so > point taken. >=20 > I think one of the areas of discussion around the use of TCG > verification is how to enable product vendors (or 3rd party "integrity" > oriented vendors) to define trust dependency trees so that verifiers can > determine what set of component measurements it needs to verify to feel > safe trusting the requesting system for a particular purpose. For many > use cases, only portions of the machine need to be checked (e.g when > your just trusting a browser session so need to check the kernel, > privileged apps and things relied upon by the brower. >=20 > I don't think this is an unsolvable problem, just a hard one. We need > an ongoing dialog to understand what is running on the requesting system > that needs to be trusted and traverse its trust dependency tree. For > NEA this might be the kernel plus the set of privileged apps and some > security configuration information or it might involve checking a > special security partition + hypervisor (depending on the system > architecture.) >=20 > >=20 > > The only thing the hash does is to assert that the code is=20 > > free from any > > *known* vulnerabilities. Once the system is compromised,=20 > > it can continue > > to provide an idyllic view to the TPM/PCR machinery. >=20 > The hash just records that a particular image of code was run on the > system (so it could later or immediately be verified [*]) in a way that > can't be hidden. The TPM only allows "extends" to the PCR so trusted > apps can effectively add to the values but not remove prior entries. > The meta-data about each extend is stored in a measurement log and is > used for verification. A rootkit might be able to alter the measurement > log but to hide its existance but it wouldn't be able to change the PCRs > to erase its measurement. >=20 > The way the TPM is used it has the capability of signing the PCRs with a > private key for a particular attestation to a verifier. The verifier > needs an equivalent measurement log (history of the PCR) to verify that > it correctly recomputes the aggregate current value stored in the PCR(s) > and can verify the meta-data makes sense and is considered valid by > policy. I'm not sure how malware that was measured into a PCR could > hide its presence without resetting the PCR back to a desired value. >=20 > [*] - Background: the model allows for a local verifier that checks code > measurements against a set of known valid measurements before allowing > it to run. This effective prevents code with known vulnerabilities from > running and establishes a trustworthy base to build upon as long as you > can trust the verifier (done via chain of trust.) As Marcus correctly > points out this doesn't catch unknown vulnerabilities. The TCG > technology that I know of doesn't do behavioral checking although such > technologies do exist and watch for zero-day attacks as we speak. You > could imagine that these could be integrated and will evolve over time. >=20 > >=20 > >=20 > > 3) How does the Posture Validator get that list of PCR values > > for known good configurations? > >=20 > > Typically from a subscription service that maintains a > > list of PCR values for various versions of software from > > all the major vendors. The decision about which software > > versions are "good" is a policy decision generally left > > to the network owner. > >=20 > > You have to assume that a compromised system would be able to maintain > > a consistently-idyllic view using some similar type of=20 > > "subscription service". > > Essentially, a compromised system can continue to update=20 > > the view of the > > world it wishes to present to the TCG subsystems. The=20 > > *reality*, however, > > will be quite different. >=20 > Same comment as above. How does the malware reset the PCRs back to the > idyllic values so future attestations comes up clean? Most of the PCRs > do not allow "set" type of operations, so this means the malware > couldn't use the TPM signed set of PCR values to spoof the verifier (nor > could it use the TPM's cert since it lacks access to the private key to > quote (sign) the incorrect pseudo-PCRs.) >=20 > > =20 > >=20 > > 4) Won't this prevent me from using my favorite OS? > >=20 > > That depends on your network's policy. If you don't like > > their policy, you're free to shop around. Remember that > > the TPM is an optional component and comes disabled. You > > can just leave it disabled. Or you can run your favorite > > OS within an untrusted application. Or you can have an > > untrusted application forward packets from your favorite OS. > > Anyway, those subscription services aren't cheap. Trusted > > boot will probably be mainly deployed in high-security > > environments. > >=20 > > There's also the scenario of a NAT-like device in a=20 > > TCG/TPM/NAP/NAC/whatever > > world. You have a "policy-compliant" system act as a proxy=20 > > for a pool > > of non-compliant nodes. "Fixing" that kind of scenario=20 > > tends to produce > > a system that is unusable for ordinary use. Perfectly=20 > > secure, and utterly > > unusable. >=20 > Not sure I follow. Are you referring to the tunneling attack discussed > in the TNC's IF-T specification or a true proxy? In the true proxy > case, the proxies should show up in the list of measurements required by > the verifier and the verifier's policy DB shouldn't allow this > configuration. For the nested tunnel attack, there are already > suggested countermeasures and work is underway for more (not > unsolvable.) >=20 > Was your comment about "fixing" the proxy case meaning that systems need > to be able to run such software or else they aren't useful? Maybe you > could explain more about your thinking? >=20 > >=20 > > 5) How does this let the server detect endpoint compromise? > >=20 > > If a trusted software component on the endpoint has been > > compromised, that will show up as a PCR with an unrecognized > > value. Because the TPM hashes the software before it's run > > and won't let the software zero the PCR (and because the > > hash is preimage resistant), the compromised software can't > > get the TPM to report a valid PCR value. And it can't > > replay an old PCR value because of the nonce. > >=20 > > That only applies to "compromised on disk". The state of=20 > > said software > > at some time T after it has begun executing *cannot* be attested-to > > by anything. If that were possible, then it would imply having a > > general solution to the halting problem. In fact, even the=20 > > known-good > > PCR values are only attesting to the fact that the software=20 > > is known to > > be resistant to all the vulnerabilities we *know about* in=20 > > the software. > > With the emergence of zero-day exploits of vulnerabilities, I wonder > > how useful this will actually be. >=20 > Without trying to solve the halting problem you can introduce mechanisms > to help raise the security level of the system. Is this useless to try > unless they are foolproof? There are an endless list of security > mechanisms which can't address this issue (bug in an IKE implementation > leaks phase 2 keys, buffer overflow of a privileged daemon and now we > can change TLS trust anchors, timing attack against processor caches and > you can learn OpenSSL private keys ...) I agree it's a hard problem but > hope we don't let it stop progress. People are working (and shipping) > technologies to try to catch zero-day exploits and these could be > integrated with other system integrity protection features to raise the > bar as best we can without waking Mr Turing :). >=20 > If a system measured all software as its loaded and check it was clean > against known vulnerabilities, recorded the measurement in a TPM (or > tamperproof environment) and created a measurement log, used AV and > behavioral techniques to watch for viruses in running code, ... and was > able to produce an attestation of all of this and the > configurations/databases it used in a non-spoofable way, this seems to > be better then we have today. Add in support for separate protection > domains to isolate security mechanisms (and logs) and we seem to be > raising the bar. >=20 > Of course this isn't TNC, but its something orthogonal that people in > the industry are working on and seems to fit in with what is being > planned. Such integrity mechanisms could offer a Posture > Collector/Verifier pair to fit into the NEA model. >=20 > > =20 > > 6) Aren't there ways to attack this system? > >=20 > > Yes. You can break the system if you can successfully attack > > any one of these: the TPM (with physical attacks or by finding > > flaws in it), the CAs that signed the TPM's certificates (or > > their operators), the trusted software that's listed in the > > known good configs, the cryptographic algorithms and protocols > > involved, or the Network Enforcer or the NEA server or their > > operators. There's also a clever attack described in Appendix A > > of the TNC IF-T document. Countermeasures for that attack are > > given in that document. > >=20 > > I have omitted some attacks for which countermeasures are > > available. If you have other attacks you're interested in, > > please raise them and I'd be glad to address them. > >=20 > > 7) Won't there inevitably be vulnerabilities in the trusted software? > >=20 > > Yes. That's true today. It will probably always be true.=20 > > The best way > > to handle it is to reduce the number of vulnerabilities by making > > the trusted software as small and secure as possible. Beyond that, > > identify vulnerabilities as soon as possible (preferably before > > exploits are available), prepare fixes, and then remove=20 > > the old buggy > > software from the list of known good configurations (or=20 > > move it to a > > list of configurations that require quarantine and mandatory > > remediation). > >=20 > > The problem is that *real* generally-useful computing=20 > > environments are still > > going to have very large components that have to be trusted=20 > > to behave > > correctly at all times. If you have an operating system=20 > > that has all > > those > > desirable properties, then you don't need any of this=20 > > TPM/TNC/NEA/TCG goop. >=20 > Ah, but this means that we do need TPM/TNC/NEA/TCG goop :). Clearly > big, complex software will have security bugs that will get fixed and > patches released. Hopefully NEA will help get the lack of those patches > recognized and distributed more quickly (being more centrally > controlled) but will need new measurement policies provisioned quickly.=20 >=20 > >=20 > > The raison d'etre for this stuff is precisely because=20 > > operating systems today > > are vulnerable due to a large number of factors, including=20 > > broken architectures, > > programming language design, human frailty, etc, etc. And=20 > > it is precisely because > > of that that this stuff can't be made to work, for any=20 > > sufficiently-rigorous > > definition of the word "work". > >=20 > > The bad guys are getting cleverer, and a large fraction of=20 > > the "good guys" haven't > > actually done any detailed analysis of all this=20 > > TCG/TNC/TPM/NEA stuff yet. >=20 > Having an NEA WG just helps bring exposure to this area so more detailed > analysis can be performed and we can improve the situation. The > TCG/TNC/TPM specs are public so can be reviewed. Their have been a > number of good cryptographers and security people who have reviewed the > TCG stuff but it's a work in progress so hopefully this momentum will > continue. >=20 > > I fully expect that there will be gaping holes found within=20 > > two years. >=20 > That's why we have version 2 :). History is certainly on your side > (SSHv1, SSLv1, Kerberos v4, ...) have all needed updates to improve > based on holes, I'm sure this will be the same. >=20 > >=20 > > I'd be perfectly delighted to be proven wrong. >=20 > Sorry but you'll still have a job for a few more years :). >=20 > >=20 > >=20 > > _______________________________________________ > > Nea mailing list > > Nea@ietf.org > > https://www1.ietf.org/mailman/listinfo/nea > >=20 >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea ------_=_NextPart_001_01C6807A.E0C9C0CA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thanks Frank - yes, you are spot = on.
 
My understanding as to how the discussion = drifted to=20 trusted hardware arose from some questions in the = IETF.
 
Basically, some folks at the IETF were = suggesting that we=20 don't bother with NEA because (a) any posture agent on the client can be = modified by malware (to then forge posture reports); and (b) They = don't=20 believe in trusted hardware or even the possibility of secure=20 systems.
 
The funny thing is that virtually all protocols = invented in=20 the IETF is subject to changes by malware in (a).  This includes = IPsec VPN=20 clients, routing code, NAT boxes, and even the entire IP=20 stack.
 
Perhaps we should just give-up on the Internet=20 :)
 
cheers,
 
/thomas/
 

 
From: Frank Yeh Jr = [mailto:fyeh@us.ibm.com]=20
Sent: Thursday, May 25, 2006 5:57 PM
To: Paul=20 Sangster
Cc: nea@ietf.org
Subject: RE: [Nea] RE: = Detecting=20 Compromised Endpoints

Greetings,

I am a little confused by this thread as it seems = to me to=20 be out of scope with the NEA work. Perhaps I added to the confusion by=20 mentioning in a previous post that NEA could leverage trusted hardware. = For=20 that, I am sorry (well, sort of).

So my impression of the NEA = charter is=20 that the procotol will be about format, aggregation, and transport of = Posture=20 information. There does not seem to be anything related to establishing = trust of=20 the various components that use the procotol. However, it would be valid = to use=20 the NEA protocols to enable a single collector/validator pair that would = attest=20 to the integrity of all other components. I do not see why this should = be part=20 of the NEA protocols themselves.

This thread probably has to do = with the=20 many TCG-aware people participating in NEA, but I think that is = confusing the=20 issue. However, since I said TCG, I would point out that the TNC specs = and the=20 PTS spec are separate. Why then are we talking about combining these = functions=20 in NEA?

Regards,
Frank Yeh
Corporate Security Strategy=20 Team
IBM
Tivoli Software


"Paul Sangster"=20 <Paul_Sangster@symantec.com> wrote on 05/25/2006 03:39:02 = PM:

>=20
> Discussions like these make me wonder what the automotive=20 safety
> engineers must have discussed when the idea of the: seat = belt,=20 air bag,
> crumple zones ... were being considered :).  How = many=20 lives do we need
> to save to make it useful ...
>
>=20 Hopefully we wouldn't pass on doing NEA because its not a panacea = for
>=20 security (its not.)  NEA itself doesn't try to solve the problems=20 of
> this thread, we're merely discussing if they might be=20 orthogonal
> mechanisms to help prevent the collector from = mis-reporting=20 the
> situation.   Putting a spotlight on the desire to = report=20 configuration
> should help bring focus to protecting the=20 collection/reporting
> mechanisms.
>
> So with that = said, let=20 go into the interesting dialog.  Clearly you've
> raised very = interesting and challenging issues that most (all?) of our
> other = standards couldn't live up to (fortunately, there are threat
> = models to=20 save the day by scoping them out :))
>
> > -----Original = Message-----
> > From: Marcus Leech [mailto:mleech@nortel.com]
> = >=20 Sent: Thursday, May 25, 2006 11:20 AM
> > To: Stephen Hanna;=20 nea@ietf.org
> > Subject: RE: [Nea] RE: Detecting Compromised=20 Endpoints
> >
> >
> >
> > 1) What = needs=20 to be measured?
> >
> >    All the trusted = code on=20 the endpoint needs to be measured.
> >    That = includes all=20 the software and firmware in the Trusted
> >   =  Computing=20 Base, any code whose compromise would potentially
> >  =20  cause the system to violate its security policies. This
> = >=20    includes the BIOS, the boot loader, the OS kernel, = the
> >=20    kernel drivers, etc. If the operating system is well=20 written,
> >    it should not include application = code since=20 that code
> >    cannot cause the system to violate = its=20 security policies.
> >
> > The essential problem is = that for=20 any *practical* operating system for
> >   purposes of=20 general-purpose computing, there *is* application code,
> > =   the=20 compromise of which, can cause the system to violate
> > its=20 security
> >   policies.
>
> Sure, privileged = code=20 also runs in applications so the kernel doesn't
> need to contain=20 everything.  Ideally OSes would limit privileges
> (ability = to bypass=20 some security check) more granularly (e.g. Solaris
> 10's = privilege model)=20 but many do not or the granularity isn't used so
> point = taken.
>=20
> I think one of the areas of discussion around the use of = TCG
>=20 verification is how to enable product vendors (or 3rd party = "integrity"
>=20 oriented vendors) to define trust dependency trees so that verifiers = can
>=20 determine what set of component measurements it needs to verify to = feel
>=20 safe trusting the requesting system for a particular purpose.  For=20 many
> use cases, only portions of the machine need to be checked = (e.g=20 when
> your just trusting a browser session so need to check the=20 kernel,
> privileged apps and things relied upon by the = brower.
>=20
> I don't think this is an unsolvable problem, just a hard one. =  We=20 need
> an ongoing dialog to understand what is running on the = requesting=20 system
> that needs to be trusted and traverse its trust = dependency tree.=20  For
> NEA this might be the kernel plus the set of = privileged apps=20 and some
> security configuration information or it might involve = checking=20 a
> special security partition + hypervisor (depending on the=20 system
> architecture.)
>
> >
> > The = only thing=20 the hash does is to assert that the code is
> > free from = any
>=20 >   *known* vulnerabilities.  Once the system is = compromised,=20
> > it can continue
> >   to provide an idyllic = view to=20 the TPM/PCR machinery.
>
> The hash just records that a = particular=20 image of code was run on the
> system (so it could later or = immediately be=20 verified [*]) in a way that
> can't be hidden.  The TPM only = allows=20 "extends" to the PCR so trusted
> apps can effectively add to the = values=20 but not remove prior entries.
> The meta-data about each extend is = stored=20 in a measurement log and is
> used for verification.  A = rootkit might=20 be able to alter the measurement
> log but to hide its existance = but it=20 wouldn't be able to change the PCRs
> to erase its = measurement.
>=20
> The way the TPM is used it has the capability of signing the = PCRs with=20 a
> private key for a particular attestation to a verifier. =  The=20 verifier
> needs an equivalent measurement log (history of the = PCR) to=20 verify that
> it correctly recomputes the aggregate current value = stored=20 in the PCR(s)
> and can verify the meta-data makes sense and is = considered=20 valid by
> policy.  I'm not sure how malware that was = measured into a=20 PCR could
> hide its presence without resetting the PCR back to a = desired=20 value.
>
> [*] - Background: the model allows for a local = verifier=20 that checks code
> measurements against a set of known valid = measurements=20 before allowing
> it to run. This effective prevents code with = known=20 vulnerabilities from
> running and establishes a trustworthy base = to build=20 upon as long as you
> can trust the verifier (done via chain of = trust.)=20  As Marcus correctly
> points out this doesn't catch unknown=20 vulnerabilities.  The TCG
> technology that I know of doesn't = do=20 behavioral checking although such
> technologies do exist and = watch for=20 zero-day attacks as we speak.  You
> could imagine that these = could=20 be integrated and will evolve over time.
>
> >
> = >=20
> > 3) How does the Posture Validator get that list of PCR=20 values
> >    for known good configurations?
> = >=20
> >    Typically from a subscription service that = maintains=20 a
> >    list of PCR values for various versions of = software=20 from
> >    all the major vendors. The decision about = which=20 software
> >    versions are "good" is a policy = decision=20 generally left
> >    to the network owner.
> = >=20
> > You have to assume that a compromised system would be able = to=20 maintain
> >   a consistently-idyllic view using some = similar type=20 of
> > "subscription service".
> >   = Essentially, a=20 compromised system can continue to update
> > the view of = the
>=20 >   world it wishes to present to the TCG subsystems.  The =
>=20 > *reality*, however,
> >   will be quite = different.
>=20
> Same comment as above.  How does the malware reset the = PCRs back=20 to the
> idyllic values so future attestations comes up clean? =  Most=20 of the PCRs
> do not allow "set" type of operations, so this means = the=20 malware
> couldn't use the TPM signed set of PCR values to spoof = the=20 verifier (nor
> could it use the TPM's cert since it lacks access = to the=20 private key to
> quote (sign) the incorrect pseudo-PCRs.)
> =
>=20 >  
> >
> > 4) Won't this prevent me from = using my=20 favorite OS?
> >
> >    That depends on = your=20 network's policy. If you don't like
> >    their = policy,=20 you're free to shop around. Remember that
> >    the = TPM is=20 an optional component and comes disabled. You
> >   =  can just=20 leave it disabled. Or you can run your favorite
> >   =  OS=20 within an untrusted application. Or you can have an
> >  =20  untrusted application forward packets from your favorite = OS.
> >=20    Anyway, those subscription services aren't cheap. = Trusted
>=20 >    boot will probably be mainly deployed in = high-security
>=20 >    environments.
> >
> > There's also = the=20 scenario of a NAT-like device in a
> >=20 TCG/TPM/NAP/NAC/whatever
> >   world.  You have a=20 "policy-compliant" system act as a proxy
> > for a = pool
> >=20   of non-compliant nodes.  "Fixing" that kind of scenario =
>=20 > tends to produce
> >   a system that is unusable for = ordinary=20 use.  Perfectly
> > secure, and utterly
> > =  =20 unusable.
>
> Not sure I follow.  Are you referring to = the=20 tunneling attack discussed
> in the TNC's IF-T specification or a = true=20 proxy?  In the true proxy
> case, the proxies should show up = in the=20 list of measurements required by
> the verifier and the verifier's = policy=20 DB shouldn't allow this
> configuration.  For the nested = tunnel=20 attack, there are already
> suggested countermeasures and work is = underway=20 for more (not
> unsolvable.)
>
> Was your comment = about=20 "fixing" the proxy case meaning that systems need
> to be able to = run such=20 software or else they aren't useful?  Maybe you
> could = explain more=20 about your thinking?
>
> >
> > 5) How does = this let=20 the server detect endpoint compromise?
> >
> >   =  If a trusted software component on the endpoint has been
> = >=20    compromised, that will show up as a PCR with an=20 unrecognized
> >    value. Because the TPM hashes the = software before it's run
> >    and won't let the = software=20 zero the PCR (and because the
> >    hash is preimage = resistant), the compromised software can't
> >    get = the TPM=20 to report a valid PCR value. And it can't
> >   =  replay an=20 old PCR value because of the nonce.
> >
> > That only = applies=20 to "compromised on disk".  The state of
> > said = software
>=20 >   at some time T after it has begun executing *cannot* be=20 attested-to
> >   by anything.  If that were = possible, then=20 it would imply having a
> >   general solution to the = halting=20 problem.  In fact, even the
> > known-good
> > =  =20 PCR values are only attesting to the fact that the software
> = > is=20 known to
> >   be resistant to all the vulnerabilities we = *know=20 about* in
> > the software.
> >   With the = emergence of=20 zero-day exploits of vulnerabilities, I wonder
> >   how = useful=20 this will actually be.
>
> Without trying to solve the = halting=20 problem you can introduce mechanisms
> to help raise the security = level of=20 the system.  Is this useless to try
> unless they are = foolproof?=20  There are an endless list of security
> mechanisms which = can't=20 address this issue (bug in an IKE implementation
> leaks phase 2 = keys,=20 buffer overflow of a privileged daemon and now we
> can change TLS = trust=20 anchors, timing attack against processor caches and
> you can = learn=20 OpenSSL private keys ...)  I agree it's a hard problem but
> = hope we=20 don't let it stop progress.  People are working (and = shipping)
>=20 technologies to try to catch zero-day exploits and these could = be
>=20 integrated with other system integrity protection features to raise = the
>=20 bar as best we can without waking Mr Turing :).
>
> If a = system=20 measured all software as its loaded and check it was clean
> = against known=20 vulnerabilities, recorded the measurement in a TPM (or
> = tamperproof=20 environment) and created a measurement log, used AV and
> = behavioral=20 techniques to watch for viruses in running code, ... and was
> = able to=20 produce an attestation of all of this and the
> = configurations/databases=20 it used in a non-spoofable way, this seems to
> be better then we = have=20 today.  Add in support for separate protection
> domains to = isolate=20 security mechanisms (and logs) and we seem to be
> raising the=20 bar.
>
> Of course this isn't TNC, but its something = orthogonal=20 that people in
> the industry are working on and seems to fit in = with what=20 is being
> planned.  Such integrity mechanisms could offer a=20 Posture
> Collector/Verifier pair to fit into the NEA = model.
>=20
> >    
> > 6) Aren't there ways to attack = this=20 system?
> >
> >    Yes. You can break the = system if=20 you can successfully attack
> >    any one of these: = the TPM=20 (with physical attacks or by finding
> >    flaws in = it), the=20 CAs that signed the TPM's certificates (or
> >   =  their=20 operators), the trusted software that's listed in the
> > =  =20  known good configs, the cryptographic algorithms and = protocols
>=20 >    involved, or the Network Enforcer or the NEA server or = their
> >    operators. There's also a clever attack=20 described in Appendix A
> >    of the TNC IF-T = document.=20 Countermeasures for that attack are
> >    given in = that=20 document.
> >
> >    I have omitted some = attacks=20 for which countermeasures are
> >    available. If = you have=20 other attacks you're interested in,
> >    please = raise them=20 and I'd be glad to address them.
> >
> > 7) Won't = there=20 inevitably be vulnerabilities in the trusted software?
> > =
>=20 >    Yes. That's true today. It will probably always be = true.=20
> > The best way
> >    to handle it is to = reduce=20 the number of vulnerabilities by making
> >    the = trusted=20 software as small and secure as possible. Beyond that,
> > =  =20  identify vulnerabilities as soon as possible (preferably = before
>=20 >    exploits are available), prepare fixes, and then = remove=20
> > the old buggy
> >    software from the = list of=20 known good configurations (or
> > move it to a
> > =  =20  list of configurations that require quarantine and = mandatory
> >=20    remediation).
> >
> > The problem is = that *real*=20 generally-useful computing
> > environments are still
> = >=20   going to have very large components that have to be trusted =
> >=20 to behave
> >   correctly at all times.   If you have = an=20 operating system
> > that has all
> > those
> = >=20   desirable properties, then you don't need any of this
> = >=20 TPM/TNC/NEA/TCG goop.
>
> Ah, but this means that we do = need=20 TPM/TNC/NEA/TCG goop :).  Clearly
> big, complex software = will have=20 security bugs that will get fixed and
> patches released. =  Hopefully=20 NEA will help get the lack of those patches
> recognized and = distributed=20 more quickly (being more centrally
> controlled) but will need new = measurement policies provisioned quickly.
>
> > =
> >=20 The raison d'etre for this stuff is precisely because
> > = operating=20 systems today
> >   are vulnerable due to a large number = of=20 factors, including
> > broken architectures,
> > =  =20 programming language design, human frailty, etc, etc.  And
> = > it=20 is precisely because
> >   of that that this stuff can't = be made=20 to work, for any
> > sufficiently-rigorous
> >   = definition of the word "work".
> >
> > The bad guys = are=20 getting cleverer, and a large fraction of
> > the "good guys"=20 haven't
> >   actually done any detailed analysis of all = this=20
> > TCG/TNC/TPM/NEA stuff yet.
>
> Having an NEA = WG just=20 helps bring exposure to this area so more detailed
> analysis can = be=20 performed and we can improve the situation.  The
> = TCG/TNC/TPM specs=20 are public so can be reviewed.  Their have been a
> number of = good=20 cryptographers and security people who have reviewed the
> TCG = stuff but=20 it's a work in progress so hopefully this momentum will
>=20 continue.
>
> >   I fully expect that there will be = gaping=20 holes found within
> > two years.
>
> That's why = we have=20 version 2 :).  History is certainly on your side
> (SSHv1, = SSLv1,=20 Kerberos v4, ...) have all needed updates to improve
> based on = holes, I'm=20 sure this will be the same.
>
> >
> > I'd be = perfectly=20 delighted to be proven wrong.
>
> Sorry but you'll still = have a job=20 for a few more years :).
>
> >
> >
> = >=20 _______________________________________________
> > Nea mailing = list
> > Nea@ietf.org
> > https://www1.ietf.org= /mailman/listinfo/nea
>=20 >
>
> = _______________________________________________
>=20 Nea mailing list
> Nea@ietf.org
> https://www1.ietf.org= /mailman/listinfo/nea

------_=_NextPart_001_01C6807A.E0C9C0CA-- --===============1723593200== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea --===============1723593200==-- From nea-bounces@ietf.org Fri May 26 07:52:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjarg-0006L4-K2; Fri, 26 May 2006 07:52:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjarf-0006Dc-CA for nea@ietf.org; Fri, 26 May 2006 07:52:23 -0400 Received: from zrtps0kn.nortel.com ([47.140.192.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fjare-0006dR-05 for nea@ietf.org; Fri, 26 May 2006 07:52:23 -0400 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nort...s0.corp.nortel.com [47.129.230.89]) by zrtps0kn.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id k4QBqI125764; Fri, 26 May 2006 07:52:19 -0400 (EDT) Received: from [47.248.126.240] ([47.248.126.240] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 May 2006 07:52:13 -0400 Message-ID: <4476EBF7.50606@nortel.com> Date: Fri, 26 May 2006 07:52:23 -0400 From: "Marcus Leech" User-Agent: Thunderbird 1.5.0.2 (X11/20060420) MIME-Version: 1.0 To: Thomas Hardjono Subject: Re: [Nea] RE: Detecting Compromised Endpoints References: <6874726B1AE3D441A3B4635B527E09B106A3F1@sledgehammer.signacert.com> In-Reply-To: <6874726B1AE3D441A3B4635B527E09B106A3F1@sledgehammer.signacert.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 May 2006 11:52:13.0895 (UTC) FILETIME=[D431E570:01C680BA] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 Thomas Hardjono wrote: > Thanks Frank - yes, you are spot on. > > My understanding as to how the discussion drifted to trusted hardware > arose from some questions in the IETF. > > Basically, some folks at the IETF were suggesting that we don't bother > with NEA because (a) any posture agent on the client can be modified > by malware (to then forge posture reports); and (b) They don't believe > in trusted hardware or even the possibility of secure systems. > > The funny thing is that virtually all protocols invented in the IETF > is subject to changes by malware in (a). This includes IPsec VPN > clients, routing code, NAT boxes, and even the entire IP stack. > I was going to simply let my contributions to this thread die, having said what I wanted to say. But this just has to be answered. There's a fundamental difference between compromise of something like an IPSEC client, and compromise of an agent. If I compromise an IPSec client in some way, it doesn't affect the security state of the VPN gateway, only that of the client. In the TCG scenario, security decisions made by the network as a whole rely entirely on the agent behaving correctly, including not having been compromised. You're making security decisions based on information that can't be independently verified. When I assert that I'm mleech@nortel.com to some gateway or NAS or whatever, my credentials (password, certificates, etc) act as a method of "indepenent verification" of my mleech@nortel.com assertion. Just because a remote, turing-complete, machine *asserts* that it is sane, and has notarization to "prove" it, doesn't necessarily make it so, and there's no way for the network infrastructure to verify those assertions with the same kind of solidity as verifying my mleech@nortel.com assertion by way of credentials. No amount of cryptographic mumbo-jumbo can get around that very fundamental problem, IMHO. Anyway, I'm done. Everyone knows what my opinion is on the fundamentals here, but to the extent that we all have drunk the kool-aid at some level, there needs to be protocol standards, and *that's* what NEA is all about. > Perhaps we should just give-up on the Internet :) Well, that's a whole other topic :-) _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri May 26 08:53:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjboa-0002HU-Av; Fri, 26 May 2006 08:53:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjboY-00029h-Pa for nea@ietf.org; Fri, 26 May 2006 08:53:14 -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 1FjboU-0005cQ-BQ for nea@ietf.org; Fri, 26 May 2006 08:53:14 -0400 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101-1.fm.intel.com with ESMTP; 26 May 2006 05:53:07 -0700 Received: from fmsmsx331.fm.intel.com (HELO fmsmsx331.amr.corp.intel.com) ([132.233.42.156]) by fmsmga001.fm.intel.com with ESMTP; 26 May 2006 05:53:07 -0700 X-IronPort-AV: i="4.05,176,1146466800"; d="scan'208"; a="42894196:sNHT24225390" Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 May 2006 05:53:07 -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); Fri, 26 May 2006 05:53:06 -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] RE: Detecting Compromised Endpoints Date: Fri, 26 May 2006 08:53:05 -0400 Message-ID: <279DDDAFA85EC74C9300A0598E704056156436@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] RE: Detecting Compromised Endpoints Thread-Index: AcaAuuxOOKC0Am1hTvWv0wJMXL5JOAABs6dw From: "Blumenthal, Uri" To: "Marcus Leech" X-OriginalArrivalTime: 26 May 2006 12:53:06.0767 (UTC) FILETIME=[5579EDF0:01C680C3] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 > But this just has to be answered. There's a fundamental difference=20 > between compromise of something like an IPSEC client, and compromise > of an agent. If I compromise an IPSec client in some way, it=20 > doesn't affect the security state of the VPN gateway, only > that of the client. Not so fast. :-) If an IPsec client is compromised - a malicious host is given access (via VPN) to the intranet. If a NEA agent is compromised - a malicious host is given access to the intranet. In both cases the intruder gets a shot at internal network. The difference with NEA is that NEA's tries to ensure that most every host connected to the intranet is at the top security level. P.S. While I appreciate the concern about the state of VPN gateway, usually it's not the door lock but the contents of the house that I want to keep secure. So if an adversary managed to find a way inside - it's not as important to me whether my door lock stayed intact. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri May 26 10:57:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjdkc-0000MW-PJ; Fri, 26 May 2006 10:57:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjdkb-0000MR-5U for nea@ietf.org; Fri, 26 May 2006 10:57:17 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fjcog-00030c-Ge for nea@ietf.org; Fri, 26 May 2006 09:57:26 -0400 Received: from mail.signacert.org ([207.162.214.7] helo=mail.signacert.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fjcmv-00088M-88 for nea@ietf.org; Fri, 26 May 2006 09:55:41 -0400 Received: from SLEDGEHAMMER.signacert.com (sledgehammer.signacert.com [70.103.105.28]) by mail.signacert.com (Postfix) with ESMTP id 8003518EC42B; Fri, 26 May 2006 06:55:35 -0700 (PDT) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message Subject: RE: [Nea] RE: Detecting Compromised Endpoints MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 May 2006 06:55:34 -0700 Message-ID: <6874726B1AE3D441A3B4635B527E09B106A401@sledgehammer.signacert.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] RE: Detecting Compromised Endpoints Thread-Index: AcaAuttAP5wZlUxmRe+uhfGbd2LhxQAEJSUg From: "Thomas Hardjono" To: "Marcus Leech" X-Spam-Score: -2.6 (--) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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 Marcus, The problem is that all devices out there that run software are targets to malware. This includes VPN Gateways, routers, firewalls, etc. etc. Just because we have not seen malware attacking these devices, it does not mean it will not happen. Perhaps its just a matter of time. Anyways, we should focus on NEA (which should be focusing on *protocols* for interoperability :) Cheers, /thomas/ -----Original Message----- From: Marcus Leech [mailto:mleech@nortel.com]=20 Sent: Friday, May 26, 2006 4:52 AM To: Thomas Hardjono Cc: nea@ietf.org; Frank Yeh Jr Subject: Re: [Nea] RE: Detecting Compromised Endpoints Thomas Hardjono wrote: > Thanks Frank - yes, you are spot on. > =20 > My understanding as to how the discussion drifted to trusted hardware=20 > arose from some questions in the IETF. > =20 > Basically, some folks at the IETF were suggesting that we don't bother > with NEA because (a) any posture agent on the client can be modified=20 > by malware (to then forge posture reports); and (b) They don't believe > in trusted hardware or even the possibility of secure systems. > =20 > The funny thing is that virtually all protocols invented in the IETF=20 > is subject to changes by malware in (a). This includes IPsec VPN=20 > clients, routing code, NAT boxes, and even the entire IP stack. > I was going to simply let my contributions to this thread die, having said what I wanted to say. But this just has to be answered. There's a fundamental difference between compromise of something like an IPSEC client, and compromise of an agent. If I compromise an IPSec client in some way, it doesn't affect the security state of the VPN gateway, only that of the client. In the TCG scenario, security decisions made by the network as a whole rely entirely on the agent behaving correctly, including not having been compromised. You're making security decisions based on information that can't be independently verified. When I assert that I'm mleech@nortel.com to some gateway or NAS or whatever, my credentials (password, certificates, etc) act as a method of "indepenent verification" of my mleech@nortel.com assertion. Just because a remote,=20 turing-complete, machine *asserts* that it is sane, and has notarization to "prove" it, doesn't necessarily make it so, and there's no way for the network infrastructure to verify those assertions with the same kind of solidity as verifying my mleech@nortel.com assertion by way of credentials. No amount of cryptographic mumbo-jumbo can get around that very fundamental problem, IMHO. Anyway, I'm done. Everyone knows what my opinion is on the fundamentals here, but to the extent that we all have drunk the kool-aid at some level, there needs to be protocol standards, and *that's* what NEA is all about. > Perhaps we should just give-up on the Internet :) Well, that's a whole other topic :-) _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri May 26 16:26:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjitJ-000695-6o; Fri, 26 May 2006 16:26:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjitH-0005yx-Ue for nea@ietf.org; Fri, 26 May 2006 16:26:35 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjitG-0008CB-WC for nea@ietf.org; Fri, 26 May 2006 16:26:35 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 26 May 2006 13:26:34 -0700 X-IronPort-AV: i="4.05,177,1146466800"; d="scan'208"; a="553842474:sNHT53060540" 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] RE: Detecting Compromised Endpoints Date: Fri, 26 May 2006 16:26:39 -0400 Message-ID: In-Reply-To: <6874726B1AE3D441A3B4635B527E09B106A3F1@sledgehammer.signacert.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] RE: Detecting Compromised Endpoints Thread-Index: AcaAX1Ji3fYfDP9PR5GPGmUGbPCT/gAGYlegAB5KNtA= From: "Stephen Hanna" To: "Thomas Hardjono" , , "Frank Yeh Jr" X-Spam-Score: 0.0 (/) X-Scan-Signature: d2bb8c7db26f2d12109e0cd8e454db52 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 One of the most common objections to NEA (and similar systems) is "If the endpoint is compromised, you can't trust anything it says." This issue continues to come up again and again. Several people on the NEA list have asked to have the charter address it, saying that it is out of scope for NEA (except that it will be addressed in the overall security analysis). The reason I started a separate thread on the topic of Detecting Compromised Endpoints was so that we could have a reasoned discussion of the problem and then refer future people who raise the issue to this thread. I said this in the first email on this thread. Thanks to all who have contributed to the thread. I think it has largely run its course. I will now draft some language on this for the charter and submit this for the mailing list to consider. I'll use a separate thread so we can keep this thread just for discussion of the technical problem of how and whether compromised endpoints can be handled. Thanks, Steve=20 > -----Original Message----- > From: Thomas Hardjono [mailto:thardjono@signacert.com]=20 > Sent: Friday, May 26, 2006 12:14 AM > To: nea@ietf.org; Frank Yeh Jr > Subject: RE: [Nea] RE: Detecting Compromised Endpoints >=20 > Thanks Frank - yes, you are spot on. > =20 > My understanding as to how the discussion drifted to trusted=20 > hardware arose from some questions in the IETF. > =20 > Basically, some folks at the IETF were suggesting that we=20 > don't bother with NEA because (a) any posture agent on the=20 > client can be modified by malware (to then forge posture=20 > reports); and (b) They don't believe in trusted hardware or=20 > even the possibility of secure systems. > =20 > The funny thing is that virtually all protocols invented in=20 > the IETF is subject to changes by malware in (a). This=20 > includes IPsec VPN clients, routing code, NAT boxes, and even=20 > the entire IP stack. > =20 > Perhaps we should just give-up on the Internet :) > =20 > cheers, > =20 > /thomas/ > =20 >=20 > =20 > ________________________________ >=20 > From: Frank Yeh Jr [mailto:fyeh@us.ibm.com]=20 > Sent: Thursday, May 25, 2006 5:57 PM > To: Paul Sangster > Cc: nea@ietf.org > Subject: RE: [Nea] RE: Detecting Compromised Endpoints >=20 >=20 >=20 > Greetings, >=20 > I am a little confused by this thread as it seems to me to be=20 > out of scope with the NEA work. Perhaps I added to the=20 > confusion by mentioning in a previous post that NEA could=20 > leverage trusted hardware. For that, I am sorry (well, sort of). >=20 > So my impression of the NEA charter is that the procotol will=20 > be about format, aggregation, and transport of Posture=20 > information. There does not seem to be anything related to=20 > establishing trust of the various components that use the=20 > procotol. However, it would be valid to use the NEA protocols=20 > to enable a single collector/validator pair that would attest=20 > to the integrity of all other components. I do not see why=20 > this should be part of the NEA protocols themselves. >=20 > This thread probably has to do with the many TCG-aware people=20 > participating in NEA, but I think that is confusing the=20 > issue. However, since I said TCG, I would point out that the=20 > TNC specs and the PTS spec are separate. Why then are we=20 > talking about combining these functions in NEA? >=20 > Regards, > Frank Yeh > Corporate Security Strategy Team > IBM > Tivoli Software >=20 >=20 > "Paul Sangster" wrote on=20 > 05/25/2006 03:39:02 PM: >=20 > >=20 > > Discussions like these make me wonder what the automotive safety > > engineers must have discussed when the idea of the: seat=20 > belt, air bag, > > crumple zones ... were being considered :). How many lives=20 > do we need > > to save to make it useful ... > >=20 > > Hopefully we wouldn't pass on doing NEA because its not a=20 > panacea for > > security (its not.) NEA itself doesn't try to solve the problems of > > this thread, we're merely discussing if they might be orthogonal > > mechanisms to help prevent the collector from mis-reporting the > > situation. Putting a spotlight on the desire to report=20 > configuration > > should help bring focus to protecting the collection/reporting > > mechanisms. > >=20 > > So with that said, let go into the interesting dialog. =20 > Clearly you've > > raised very interesting and challenging issues that most=20 > (all?) of our > > other standards couldn't live up to (fortunately, there are threat > > models to save the day by scoping them out :)) > >=20 > > > -----Original Message----- > > > From: Marcus Leech [mailto:mleech@nortel.com]=20 > > > Sent: Thursday, May 25, 2006 11:20 AM > > > To: Stephen Hanna; nea@ietf.org > > > Subject: RE: [Nea] RE: Detecting Compromised Endpoints > > >=20 > > >=20 > > >=20 > > > 1) What needs to be measured? > > >=20 > > > All the trusted code on the endpoint needs to be measured. > > > That includes all the software and firmware in the Trusted > > > Computing Base, any code whose compromise would potentially > > > cause the system to violate its security policies. This > > > includes the BIOS, the boot loader, the OS kernel, the > > > kernel drivers, etc. If the operating system is well written, > > > it should not include application code since that code > > > cannot cause the system to violate its security policies. > > >=20 > > > The essential problem is that for any *practical*=20 > operating system for > > > purposes of general-purpose computing, there *is*=20 > application code, > > > the compromise of which, can cause the system to violate=20 > > > its security > > > policies. > >=20 > > Sure, privileged code also runs in applications so the=20 > kernel doesn't > > need to contain everything. Ideally OSes would limit privileges > > (ability to bypass some security check) more granularly=20 > (e.g. Solaris > > 10's privilege model) but many do not or the granularity=20 > isn't used so > > point taken. > >=20 > > I think one of the areas of discussion around the use of TCG > > verification is how to enable product vendors (or 3rd party=20 > "integrity" > > oriented vendors) to define trust dependency trees so that=20 > verifiers can > > determine what set of component measurements it needs to=20 > verify to feel > > safe trusting the requesting system for a particular=20 > purpose. For many > > use cases, only portions of the machine need to be checked (e.g when > > your just trusting a browser session so need to check the kernel, > > privileged apps and things relied upon by the brower. > >=20 > > I don't think this is an unsolvable problem, just a hard=20 > one. We need > > an ongoing dialog to understand what is running on the=20 > requesting system > > that needs to be trusted and traverse its trust dependency=20 > tree. For > > NEA this might be the kernel plus the set of privileged=20 > apps and some > > security configuration information or it might involve checking a > > special security partition + hypervisor (depending on the system > > architecture.) > >=20 > > >=20 > > > The only thing the hash does is to assert that the code is=20 > > > free from any > > > *known* vulnerabilities. Once the system is compromised,=20 > > > it can continue > > > to provide an idyllic view to the TPM/PCR machinery. > >=20 > > The hash just records that a particular image of code was run on the > > system (so it could later or immediately be verified [*])=20 > in a way that > > can't be hidden. The TPM only allows "extends" to the PCR=20 > so trusted > > apps can effectively add to the values but not remove prior entries. > > The meta-data about each extend is stored in a measurement=20 > log and is > > used for verification. A rootkit might be able to alter=20 > the measurement > > log but to hide its existance but it wouldn't be able to=20 > change the PCRs > > to erase its measurement. > >=20 > > The way the TPM is used it has the capability of signing=20 > the PCRs with a > > private key for a particular attestation to a verifier. =20 > The verifier > > needs an equivalent measurement log (history of the PCR) to=20 > verify that > > it correctly recomputes the aggregate current value stored=20 > in the PCR(s) > > and can verify the meta-data makes sense and is considered valid by > > policy. I'm not sure how malware that was measured into a PCR could > > hide its presence without resetting the PCR back to a desired value. > >=20 > > [*] - Background: the model allows for a local verifier=20 > that checks code > > measurements against a set of known valid measurements=20 > before allowing > > it to run. This effective prevents code with known=20 > vulnerabilities from > > running and establishes a trustworthy base to build upon as=20 > long as you > > can trust the verifier (done via chain of trust.) As=20 > Marcus correctly > > points out this doesn't catch unknown vulnerabilities. The TCG > > technology that I know of doesn't do behavioral checking=20 > although such > > technologies do exist and watch for zero-day attacks as we=20 > speak. You > > could imagine that these could be integrated and will=20 > evolve over time. > >=20 > > >=20 > > >=20 > > > 3) How does the Posture Validator get that list of PCR values > > > for known good configurations? > > >=20 > > > Typically from a subscription service that maintains a > > > list of PCR values for various versions of software from > > > all the major vendors. The decision about which software > > > versions are "good" is a policy decision generally left > > > to the network owner. > > >=20 > > > You have to assume that a compromised system would be=20 > able to maintain > > > a consistently-idyllic view using some similar type of=20 > > > "subscription service". > > > Essentially, a compromised system can continue to update=20 > > > the view of the > > > world it wishes to present to the TCG subsystems. The=20 > > > *reality*, however, > > > will be quite different. > >=20 > > Same comment as above. How does the malware reset the PCRs=20 > back to the > > idyllic values so future attestations comes up clean? Most=20 > of the PCRs > > do not allow "set" type of operations, so this means the malware > > couldn't use the TPM signed set of PCR values to spoof the=20 > verifier (nor > > could it use the TPM's cert since it lacks access to the=20 > private key to > > quote (sign) the incorrect pseudo-PCRs.) > >=20 > > > =20 > > >=20 > > > 4) Won't this prevent me from using my favorite OS? > > >=20 > > > That depends on your network's policy. If you don't like > > > their policy, you're free to shop around. Remember that > > > the TPM is an optional component and comes disabled. You > > > can just leave it disabled. Or you can run your favorite > > > OS within an untrusted application. Or you can have an > > > untrusted application forward packets from your favorite OS. > > > Anyway, those subscription services aren't cheap. Trusted > > > boot will probably be mainly deployed in high-security > > > environments. > > >=20 > > > There's also the scenario of a NAT-like device in a=20 > > > TCG/TPM/NAP/NAC/whatever > > > world. You have a "policy-compliant" system act as a proxy=20 > > > for a pool > > > of non-compliant nodes. "Fixing" that kind of scenario=20 > > > tends to produce > > > a system that is unusable for ordinary use. Perfectly=20 > > > secure, and utterly > > > unusable. > >=20 > > Not sure I follow. Are you referring to the tunneling=20 > attack discussed > > in the TNC's IF-T specification or a true proxy? In the true proxy > > case, the proxies should show up in the list of=20 > measurements required by > > the verifier and the verifier's policy DB shouldn't allow this > > configuration. For the nested tunnel attack, there are already > > suggested countermeasures and work is underway for more (not > > unsolvable.) > >=20 > > Was your comment about "fixing" the proxy case meaning that=20 > systems need > > to be able to run such software or else they aren't useful?=20 > Maybe you > > could explain more about your thinking? > >=20 > > >=20 > > > 5) How does this let the server detect endpoint compromise? > > >=20 > > > If a trusted software component on the endpoint has been > > > compromised, that will show up as a PCR with an unrecognized > > > value. Because the TPM hashes the software before it's run > > > and won't let the software zero the PCR (and because the > > > hash is preimage resistant), the compromised software can't > > > get the TPM to report a valid PCR value. And it can't > > > replay an old PCR value because of the nonce. > > >=20 > > > That only applies to "compromised on disk". The state of=20 > > > said software > > > at some time T after it has begun executing *cannot* be=20 > attested-to > > > by anything. If that were possible, then it would=20 > imply having a > > > general solution to the halting problem. In fact, even the=20 > > > known-good > > > PCR values are only attesting to the fact that the software=20 > > > is known to > > > be resistant to all the vulnerabilities we *know about* in=20 > > > the software. > > > With the emergence of zero-day exploits of=20 > vulnerabilities, I wonder > > > how useful this will actually be. > >=20 > > Without trying to solve the halting problem you can=20 > introduce mechanisms > > to help raise the security level of the system. Is this=20 > useless to try > > unless they are foolproof? There are an endless list of security > > mechanisms which can't address this issue (bug in an IKE=20 > implementation > > leaks phase 2 keys, buffer overflow of a privileged daemon=20 > and now we > > can change TLS trust anchors, timing attack against=20 > processor caches and > > you can learn OpenSSL private keys ...) I agree it's a=20 > hard problem but > > hope we don't let it stop progress. People are working=20 > (and shipping) > > technologies to try to catch zero-day exploits and these could be > > integrated with other system integrity protection features=20 > to raise the > > bar as best we can without waking Mr Turing :). > >=20 > > If a system measured all software as its loaded and check=20 > it was clean > > against known vulnerabilities, recorded the measurement in a TPM (or > > tamperproof environment) and created a measurement log, used AV and > > behavioral techniques to watch for viruses in running code,=20 > ... and was > > able to produce an attestation of all of this and the > > configurations/databases it used in a non-spoofable way,=20 > this seems to > > be better then we have today. Add in support for separate=20 > protection > > domains to isolate security mechanisms (and logs) and we seem to be > > raising the bar. > >=20 > > Of course this isn't TNC, but its something orthogonal that=20 > people in > > the industry are working on and seems to fit in with what is being > > planned. Such integrity mechanisms could offer a Posture > > Collector/Verifier pair to fit into the NEA model. > >=20 > > > =20 > > > 6) Aren't there ways to attack this system? > > >=20 > > > Yes. You can break the system if you can successfully attack > > > any one of these: the TPM (with physical attacks or by finding > > > flaws in it), the CAs that signed the TPM's certificates (or > > > their operators), the trusted software that's listed in the > > > known good configs, the cryptographic algorithms and protocols > > > involved, or the Network Enforcer or the NEA server or their > > > operators. There's also a clever attack described in Appendix A > > > of the TNC IF-T document. Countermeasures for that attack are > > > given in that document. > > >=20 > > > I have omitted some attacks for which countermeasures are > > > available. If you have other attacks you're interested in, > > > please raise them and I'd be glad to address them. > > >=20 > > > 7) Won't there inevitably be vulnerabilities in the=20 > trusted software? > > >=20 > > > Yes. That's true today. It will probably always be true.=20 > > > The best way > > > to handle it is to reduce the number of=20 > vulnerabilities by making > > > the trusted software as small and secure as possible.=20 > Beyond that, > > > identify vulnerabilities as soon as possible (preferably before > > > exploits are available), prepare fixes, and then remove=20 > > > the old buggy > > > software from the list of known good configurations (or=20 > > > move it to a > > > list of configurations that require quarantine and mandatory > > > remediation). > > >=20 > > > The problem is that *real* generally-useful computing=20 > > > environments are still > > > going to have very large components that have to be trusted=20 > > > to behave > > > correctly at all times. If you have an operating system=20 > > > that has all > > > those > > > desirable properties, then you don't need any of this=20 > > > TPM/TNC/NEA/TCG goop. > >=20 > > Ah, but this means that we do need TPM/TNC/NEA/TCG goop :). Clearly > > big, complex software will have security bugs that will get=20 > fixed and > > patches released. Hopefully NEA will help get the lack of=20 > those patches > > recognized and distributed more quickly (being more centrally > > controlled) but will need new measurement policies=20 > provisioned quickly.=20 > >=20 > > >=20 > > > The raison d'etre for this stuff is precisely because=20 > > > operating systems today > > > are vulnerable due to a large number of factors, including=20 > > > broken architectures, > > > programming language design, human frailty, etc, etc. And=20 > > > it is precisely because > > > of that that this stuff can't be made to work, for any=20 > > > sufficiently-rigorous > > > definition of the word "work". > > >=20 > > > The bad guys are getting cleverer, and a large fraction of=20 > > > the "good guys" haven't > > > actually done any detailed analysis of all this=20 > > > TCG/TNC/TPM/NEA stuff yet. > >=20 > > Having an NEA WG just helps bring exposure to this area so=20 > more detailed > > analysis can be performed and we can improve the situation. The > > TCG/TNC/TPM specs are public so can be reviewed. Their have been a > > number of good cryptographers and security people who have=20 > reviewed the > > TCG stuff but it's a work in progress so hopefully this=20 > momentum will > > continue. > >=20 > > > I fully expect that there will be gaping holes found within=20 > > > two years. > >=20 > > That's why we have version 2 :). History is certainly on your side > > (SSHv1, SSLv1, Kerberos v4, ...) have all needed updates to improve > > based on holes, I'm sure this will be the same. > >=20 > > >=20 > > > I'd be perfectly delighted to be proven wrong. > >=20 > > Sorry but you'll still have a job for a few more years :). > >=20 > > >=20 > > >=20 > > > _______________________________________________ > > > Nea mailing list > > > Nea@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nea > > >=20 > >=20 > > _______________________________________________ > > Nea mailing list > > Nea@ietf.org > > https://www1.ietf.org/mailman/listinfo/nea >=20 >=20 >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri May 26 16:35:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjj1c-0004dM-3C; Fri, 26 May 2006 16:35:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjj1Z-0004dG-CQ for nea@ietf.org; Fri, 26 May 2006 16:35:10 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fjj1Y-00015l-4p for nea@ietf.org; Fri, 26 May 2006 16:35:09 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 26 May 2006 13:35:07 -0700 X-IronPort-AV: i="4.05,177,1146466800"; d="scan'208"; a="553844052:sNHT26684688" 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, 26 May 2006 16:35:10 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Charter language on compromised endpoints Thread-Index: AcaBA+I9MyasHRJKT8GE5e7OHEA0nA== From: "Stephen Hanna" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Nea] Charter language on compromised endpoints 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 Since several people on the NEA list have asked to have the charter address the matter of compromised endpoints but nobody has suggested that this should be in scope for NEA (except that it will be addressed in the overall security analysis), I propose adding the following text to the current draft charter just before the milestones: ----- One commonly discussed issue with NEA systems is how to handle compromised endpoints, whose reports of their own posture may not be accurate. This issue is out of scope for the NEA working group except in the security analysis section of the Requirements document. ----- I invite comments on this proposal. Thanks, Steve _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri May 26 17:04:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjjTw-000600-QD; Fri, 26 May 2006 17:04:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjjTu-0005vZ-Rq for nea@ietf.org; Fri, 26 May 2006 17:04:26 -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 1FjjTs-0004rS-FM for nea@ietf.org; Fri, 26 May 2006 17:04:26 -0400 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101-1.fm.intel.com with ESMTP; 26 May 2006 14:04:19 -0700 Received: from orsmsx332.jf.intel.com (HELO orsmsx332.amr.corp.intel.com) ([192.168.65.60]) by fmsmga001.fm.intel.com with ESMTP; 26 May 2006 14:04:19 -0700 X-IronPort-AV: i="4.05,177,1146466800"; d="scan'208"; a="43108202:sNHT23530682" Received: from orsmsx408.amr.corp.intel.com ([192.168.65.52]) by orsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 May 2006 14:04:18 -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] Charter language on compromised endpoints Date: Fri, 26 May 2006 14:04:17 -0700 Message-ID: <96E39AF1B99FDC47A38DDAB22C3E70CA07EAB3F3@orsmsx408> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Charter language on compromised endpoints Thread-Index: AcaBA+I9MyasHRJKT8GE5e7OHEA0nAAA6S6Q From: "Sahita, Ravi" To: "Stephen Hanna" , X-OriginalArrivalTime: 26 May 2006 21:04:18.0659 (UTC) FILETIME=[F417C330:01C68107] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 One option is to put the discussion on the list and other input on this issue in a short informational draft so that it is available as a reference if similar questions/comments come up, The text below for the charter seems ok. Ravi -----Original Message----- From: Stephen Hanna [mailto:shanna@juniper.net]=20 Sent: Friday, May 26, 2006 1:35 PM To: nea@ietf.org Subject: [Nea] Charter language on compromised endpoints Since several people on the NEA list have asked to have the charter address the matter of compromised endpoints but nobody has suggested that this should be in scope for NEA (except that it will be addressed in the overall security analysis), I propose adding the following text to the current draft charter just before the milestones: ----- One commonly discussed issue with NEA systems is how to handle compromised endpoints, whose reports of their own posture may not be accurate. This issue is out of scope for the NEA working group except in the security analysis section of the Requirements document. ----- I invite comments on this proposal. Thanks, 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 Fri May 26 17:33:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjjvv-0004i3-Q1; Fri, 26 May 2006 17:33:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjjvu-0004hy-LQ for nea@ietf.org; Fri, 26 May 2006 17:33:22 -0400 Received: from mail.signacert.com ([207.162.214.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fjjvt-0000mP-CX for nea@ietf.org; Fri, 26 May 2006 17:33:22 -0400 Received: from SLEDGEHAMMER.signacert.com (sledgehammer.signacert.com [70.103.105.28]) by mail.signacert.com (Postfix) with ESMTP id 7ACBD18EC42B; Fri, 26 May 2006 14:33:17 -0700 (PDT) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Nea] Charter language on compromised endpoints Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 26 May 2006 14:33:17 -0700 Message-ID: <6874726B1AE3D441A3B4635B527E09B106A46E@sledgehammer.signacert.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Charter language on compromised endpoints Thread-Index: AcaBA+I9MyasHRJKT8GE5e7OHEA0nAACBO5A From: "Thomas Hardjono" To: "Stephen Hanna" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 Looks good Steve. /thomas/=20 -----Original Message----- From: Stephen Hanna [mailto:shanna@juniper.net]=20 Sent: Friday, May 26, 2006 1:35 PM To: nea@ietf.org Subject: [Nea] Charter language on compromised endpoints Since several people on the NEA list have asked to have the charter address the matter of compromised endpoints but nobody has suggested that this should be in scope for NEA (except that it will be addressed in the overall security analysis), I propose adding the following text to the current draft charter just before the milestones: ----- One commonly discussed issue with NEA systems is how to handle compromised endpoints, whose reports of their own posture may not be accurate. This issue is out of scope for the NEA working group except in the security analysis section of the Requirements document. ----- I invite comments on this proposal. Thanks, 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 Fri May 26 17:51:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjkDe-0003rH-MY; Fri, 26 May 2006 17:51:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjkDc-0003rC-Kc for nea@ietf.org; Fri, 26 May 2006 17:51:40 -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 1FjkDb-0004iY-BB for nea@ietf.org; Fri, 26 May 2006 17:51:40 -0400 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101-1.ch.intel.com with ESMTP; 26 May 2006 14:51:35 -0700 Received: from orsmsx331.jf.intel.com (HELO orsmsx331.amr.corp.intel.com) ([192.168.65.56]) by azsmga001.ch.intel.com with ESMTP; 26 May 2006 14:51:18 -0700 X-IronPort-AV: i="4.05,177,1146466800"; d="scan'208"; a="42237845:sNHT9500037988" Received: from orsmsx411.amr.corp.intel.com ([10.22.226.47]) by orsmsx331.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 May 2006 14:51: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] Charter language on compromised endpoints Date: Fri, 26 May 2006 14:51:17 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Charter language on compromised endpoints Thread-Index: AcaBA+I9MyasHRJKT8GE5e7OHEA0nAACpPeA From: "Khosravi, Hormuzd M" To: "Stephen Hanna" , X-OriginalArrivalTime: 26 May 2006 21:51:17.0985 (UTC) FILETIME=[848AC510:01C6810E] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 Looks good to me, Steve. We'll also add some text around this in the Requirements draft as you suggested. Thanks Hormuzd -----Original Message----- From: Stephen Hanna [mailto:shanna@juniper.net]=20 Sent: Friday, May 26, 2006 1:35 PM To: nea@ietf.org Subject: [Nea] Charter language on compromised endpoints Since several people on the NEA list have asked to have the charter address the matter of compromised endpoints but nobody has suggested that this should be in scope for NEA (except that it will be addressed in the overall security analysis), I propose adding the following text to the current draft charter just before the milestones: ----- One commonly discussed issue with NEA systems is how to handle compromised endpoints, whose reports of their own posture may not be accurate. This issue is out of scope for the NEA working group except in the security analysis section of the Requirements document. ----- I invite comments on this proposal. Thanks, 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 Fri May 26 21:43:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjnqR-0007YS-3Z; Fri, 26 May 2006 21:43:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FjnqP-0007X8-1G for nea@ietf.org; Fri, 26 May 2006 21:43:57 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FjnqN-0004Fc-5d for nea@ietf.org; Fri, 26 May 2006 21:43:56 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4R1hsBI004711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 26 May 2006 18:43:54 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4R1hqvX021401; Fri, 26 May 2006 18:43:52 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 26 May 2006 18:43:52 -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] Revised draft NEA charter Date: Fri, 26 May 2006 18:43:49 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB8490B682@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Revised draft NEA charter Thread-Index: AcZ5/TK96YKZLzFqSlWmAS+rsP1glQAI0qrgAFkpUOAAmPKskAA6myzgAAVgzCAADR928AAhvgxgABQPjXAATUVe4A== From: "Narayanan, Vidya" To: "Stephen Hanna" X-OriginalArrivalTime: 27 May 2006 01:43:52.0270 (UTC) FILETIME=[01F1AEE0:01C6812F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 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 Steve, >=20 > Vidya, >=20 > Sorry I mischaracterized your comments as coming from a=20 > service provider perspective. Whatever the perspective, I=20 > appreciate them. >=20 No worries.=20 > > I don't see how NEA can detect compromised endpoints even=20 > with trusted=20 > > hardware - with trusted hardware storing the attributes, it=20 > just means=20 > > that a compromised device may not be able to tweak the=20 > attributes (I'm=20 > > not even totally convinced of this at the moment, but let's=20 > say that). >=20 > This is a big discussion. I'll start a separate thread for it. >=20 I'm slowly catching up with that thread. I'll respond to this point on that thread.=20 > > > Re-validation after an IP address has been assigned would=20 > typically=20 > > > (but not necessarily) be done via a layer 3 protocol,=20 > thus avoiding=20 > > > the need to disrupt network access during the re-validation. > > >=20 > >=20 > > Having said this, what is the result of posture validation?=20 > > The analogy > > I am able to make in my mind is something like a virus or=20 > application=20 > > patch update/notification process - is that what is being=20 > > standardized? >=20 > The results of posture validation can include remediation or=20 > restrictions on network access. For validation some time=20 > after network access has already been granted, restricting=20 > network access may use RADIUS CoA message, for example.=20 > Remediation is the process of fixing problems with the=20 > endpoint, manually or automatically. > It can include installing patches or updates to the operating=20 > system, applications, or virus definitions. That's common. It=20 > can also include changes to configuration settings on the=20 > endpoint (like enabling the firewall) and other things like=20 > doing a virus scan. >=20 > The current NEA charter does not propose to standardize what=20 > happens after posture validation. It's focused on the=20 > protocols for posture validation itself. >=20 Right, I do understand this. In order to appreciate the charter and the work, I was, however, trying to piece the big picture together.=20 > > The charter says "It will also include requirements for the=20 > protocol=20 > > transporting PA, PB: the Posture Transport protocol (PT). Specific=20 > > requirements for an EAP instantiation of PT will be identified." -=20 > > this seems to imply that the primary protocol intended to=20 > carry PA and=20 > > PB is an EAP method. Or, am I missing something? >=20 > That darn sentence has been causing all sorts of trouble! ;-)=20 > The NEA charter is supposed to be transport independent. But=20 > people are definitely interested in EAP. It's a very popular=20 > transport, supported by all the major NAC architectures but=20 > in incompatible ways. So it was suggested that we should=20 > include specific requirements for EAP so that the EMU group=20 > or someone else could work on a standard transport for NEA if=20 > they want to at some later time. >=20 > Maybe the sentence should be changed to something like this: >=20 > Specific requirements for an EAP instantiation of PT will be=20 > identified in case standardization in that area is desired. > However, standardization of an EAP instantiation is not in=20 > scope for the NEA working group. >=20 The wording itself is okay, but I am trying to see what the deployment model is likely to be, given what NEA is standardizing and what it may ask other WGs in the IETF to standardize. Right now, I'm only seeing EAP as the alluded solution and that in general concerns me.=20 Regards, Vidya > > > The requirements document includes a discussion of device=20 > compromise=20 > > > in its security considerations section (8.1). > > > Maybe we will need to include something about this in the=20 > charter.=20 > > > What do others think? > >=20 > > I believe the charter should clarify this.=20 >=20 > We seem to have consensus on this. Let's add a paragraph on=20 > this topic to the charter once we agree on what it should say. ;-) >=20 > > > As for de-coupling NEA from network access, that's=20 > already part of=20 > > > the plan (as described above). Maybe we need to make the charter=20 > > > clearer on this point. > > >=20 > >=20 > > Aside from the confusions mentioned above, when it is=20 > de-coupled from=20 > > network access, it is not clear to me as to where the transport=20 > > protocol is going to be specified. >=20 > There are other working groups better suited for such work. > For instance, an EAP method should probably go through the=20 > EAP or EMU working groups. I don't think our charter should=20 > call out work for other working groups. That got us into=20 > trouble last time. I hope the text on this that I proposed=20 > above will help clarify it. >=20 > Thanks, >=20 > Steve >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Sat May 27 02:15:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjs4q-0003AO-2s; Sat, 27 May 2006 02:15:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fjs4p-0003AJ-Mb for nea@ietf.org; Sat, 27 May 2006 02:15:07 -0400 Received: from nz-out-0102.google.com ([64.233.162.197]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fjs4o-00080m-Ez for nea@ietf.org; Sat, 27 May 2006 02:15:07 -0400 Received: by nz-out-0102.google.com with SMTP id f1so204731nzc for ; Fri, 26 May 2006 23:15:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fvsN9Tck1fUcHKCzK6NJ3g1xGEOXsG7dECkpRMEfATemhWawoPkJxBTHw2Q7hy92e5jkoofKOmortqLv3MBbFgYTyqIJq4YtufWzQq9/O6n4U38/mZZSQ3Ka/nJMC5oCFEhCqezBM0UDUhTB8ZusyRxMPBEkb0RywcLG9NzEIQ4= Received: by 10.36.220.78 with SMTP id s78mr259754nzg; Fri, 26 May 2006 23:15:06 -0700 (PDT) Received: by 10.36.46.9 with HTTP; Fri, 26 May 2006 23:15:05 -0700 (PDT) Message-ID: Date: Fri, 26 May 2006 23:15:05 -0700 From: "Sean Convery" To: "Khosravi, Hormuzd M" Subject: Re: [Nea] Charter language on compromised endpoints In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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 Would it be appropriate to extend this wording to include some basic statements that we, as a group, agree that there is value conferred on the system even if some elements (the compromised ones) don't accurately report their health? The wording as written seems to beg the question, "Well why isn't it in scope?" Thanks, Sean On 5/26/06, Khosravi, Hormuzd M wrote: > Looks good to me, Steve. > > We'll also add some text around this in the Requirements draft as you > suggested. > > Thanks > Hormuzd > > -----Original Message----- > From: Stephen Hanna [mailto:shanna@juniper.net] > Sent: Friday, May 26, 2006 1:35 PM > To: nea@ietf.org > Subject: [Nea] Charter language on compromised endpoints > > Since several people on the NEA list have asked to have > the charter address the matter of compromised endpoints > but nobody has suggested that this should be in scope > for NEA (except that it will be addressed in the overall > security analysis), I propose adding the following text > to the current draft charter just before the milestones: > > ----- > > One commonly discussed issue with NEA systems is how to > handle compromised endpoints, whose reports of their own > posture may not be accurate. This issue is out of scope > for the NEA working group except in the security analysis > section of the Requirements document. > > ----- > > I invite comments on this proposal. > > Thanks, > > 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 > _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea