From nea-bounces@ietf.org Sat Nov 04 07:33:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgKi4-0004mF-M9; Sat, 04 Nov 2006 07:33:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgKi3-0004m1-Aj; Sat, 04 Nov 2006 07:33:15 -0500 Received: from elasmtp-spurfowl.atl.sa.earthlink.net ([209.86.89.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgKi1-0004pw-Ov; Sat, 04 Nov 2006 07:33:15 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Mzni1jN06PaZP6P+LIhFiK0XxYMiiMZR+zheRgcPSGbdZA6Feeshh3PmIM7JKFAV; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [4.246.45.8] (helo=gw) by elasmtp-spurfowl.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GgKhw-0002CY-Ve; Sat, 04 Nov 2006 07:33:11 -0500 Message-ID: <006601c7000d$750846c0$010aa8c0@home.glassey.com> From: "todd glassey" To: , "IESG Secretary" References: Subject: Re: [Nea] WG Action: Network Endpoint Assessment (nea) Date: Sat, 4 Nov 2006 04:33:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec793c22e5b795751881f94d9633fafba7a3350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.246.45.8 X-Spam-Score: 0.0 (/) X-Scan-Signature: f8184d7d4d1b986353eb58ea3e887935 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 All - not that you ever listen to me - but what you are referring to is an auditing protocol so allow me to make some commentary about the charter and tuning it. There are a number of spots where it gets too granular and those need to be removed wholesale. NEA is unlike ANY OTHER IETF PROJECT since it encompasses a who range of functionality and services. It is essentially possibly something that needs its own Area as well. Since it is an amalgam of other protocols and processes within the scope 'of being able to prove the integrity of the operating nodes in some network'. --- As to the rest ... this document starts to focus on the workproduct of the NEA team rather than the team and its goals. Bluntly, it designs too much of NEA rather than the WG that is going to implement it. Or how that WG intends to standardize or develop or cobrand this work effort. IMHO The NEA Charter is for the organization to produce the product not the product itself. (sorry that's one of my complaints about the IETF process - anyway more 'editing' below. ----- Original Message ----- From: "IESG Secretary" To: Cc: Sent: Tuesday, October 31, 2006 3:50 PM Subject: [Nea] WG Action: Network Endpoint Assessment (nea) > A new IETF working group has been formed in the Security Area. > For additional information, please contact the Area Directors > or the WG Chairs. > > +++ > > Network Endpoint Assessment (nea) > =================================== > > Current Status: Active Working Group > > Chair(s): > Steve Hanna > Susan Thomson > > Security Area Director(s): > Russ Housley > Sam Hartman > > Security Area Advisor: > Russ Housley > > Mailing Lists: > General Discussion: nea@ietf.org > Subscription: http://www1.ietf.org/mailman/listinfo/nea > Archive: http://www1.ietf.org/mail-archive/web/nea/current/index.html > > Description of Working Group: > > Network Endpoint Assessment (NEA) architectures have been implemented > in the industry to assess Replace the word ASSESS with COMMUNICATE >the "posture" Replace this use of the term POSTURE with OPERATIONAL COMPLIANCE > of endpoint devices for the > purposes of monitoring compliance to an organization's posture Replace this use of the term POSTURE with "IT SECURITY and OPERATING" > policy period. End of sentence. > And optionally restricting access until the endpoint has been updated > to satisfy the posture requirements. Yeah - more posturing... lose this as well. Hey Sam - Steve and Susan; I understand the need to want to be able to control the node if it comes out of compliance, but this is a separate action from the CONTROL of reporting when that device is out of compliance. So you got several pieces here, you need a compliance framework, a set of metrics for the compliance models. A set of baseline policies to use as controls, and then the protocol and messaging model itself. All in all this is several man-years worth of work, especially for a group with as many cooks in the kitchen as this one has. By the way, NEA as an Audit Tool is a neat idea but what it really is, is a platform configuration and integrity management service and the daemon's to implement it.Everything boils down from an audit perspective to being a config/integrity or function transaction instance. So ... let me put my auditor hat on and say - The AUDIT DISTINCTION between reporting and functional controls in a IT Workflow is critical to the design of any service that could conceivably be used to control remote nodes' operations. What you are taking about is a Systems Integrity System; A Policy-Centric SCADA for OS and IT Infrastructure Appliances per se. > An endpoint that does not comply > with posture policy may be vulnerable to a number of known threats that > may exist on the network. Too wordy. Lose this whole FEAR UNCERTAINTY AND DOUBT schtick please, its worthless in the bigger picture of things and doesnt paint a nice picture for the audit community who will be asked to rely on this system > The intent of NEA is to facilitate corrective > actions to address these known vulnerabilities before a host is exposed > to potential attack. Hmmm- I would tune this too - At the functional level, the NEA is a tool set that allows remote control of a node with regard to its operating compliance to some defined set of organisational IT policies. It (NEA) provides the transport and messaging models for those communications and some secured agent services which can then be used to make operating changes in the remote nodes based on the reports that NEA delivers from those nodes on their compliance-status. It will also be the task of the NEA Working Group to define some prototype controls and messaging features for an implmentation of this system. The Intent of the NEA is to aggregate all of those controls and features used in the divergent systems in a IT device so that they can be monitored, controlled, and administered through a common framework in a secure and reliable manner. > Note that an endpoint that is deemed compliant may > still be vulnerable to threats that may exist on the network. > The > network may thus continue to be exposed to such threats as well as the > range of other threats not addressed by maintaining endpoint > compliance. JFC - > > Posture refers to the hardware or software configuration of an endpoint > as it pertains to an organization's security policy. It should also control endpont configuration and updates for code footprint management. Likewise patching would need to be manageed by NEA as well to enable it to know when some end-node was out of compliance with some set or specific IT Policy. > Posture may > include knowledge that software installed to protect the machine (e.g. > patch management software, anti-virus software, host firewall software, > host intrusion protection software or any custom software) is enabled > and up-to-date. An endpoint supporting NEA protocols can be queried for > posture information. Why define the scope of the messaging? Leave it open-ended. > > An organization may make a range of policy decisions based on the > posture of an endpoint. NEA is not intended to be prescriptive in this > regard. Supported deployment scenarios will include, but are not > limited to, providing normal access regardless of compliance result > along with any recommendations for remediation ("advisory mode"), as > well as providing restricted access sufficient for remediation purposes > and any essential services until an endpoint is in compliance > ("mandatory mode"). Specifying mechanisms for providing restricted > access is outside the scope of the NEA WG. This is way too much detail for the Charter. This should go into the ID and RFC's for the compnents of the NEA System. > > Since NEA involves many different components from different vendors, > interoperability is important. The priority of the NEA working group is > to develop standard protocols at the higher layers in the architecture: > the Posture Attribute protocol (PA) and the Posture Broker protocol > (PB). PA and PB will be designed to support a variety of lower layer > protocols. When used with standards for lower layers, the PA and PB > protocols will allow interoperability between an NEA Client from one > vendor and an NEA Server from another. > > Since there are already several non-standard protocols at these higher > layers, the NEA working group will consider these existing protocols as > candidates for the standard protocols. 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 the PA and PB protocols, and an > overall security analysis. It will also include generic requirements > for the protocol transporting PA, PB: the Posture Transport protocol > (PT). PT protocols may be standardized in other WGs since these > protocols may not be specific to NEA. The NEA WG will identify and > specify the use of one mandatory to implement PT protocol that is fully > documented in an RFC. > > The PA (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. A base set of standard posture > attributes will be specified that are expected to address many common > posture policies. Vendor-specific attributes will also be supported; > vendor-specific attributes will be identified by a private enterprise > number and a vendor assigned value. Vendors are strongly encouraged to > document vendor-specific attributes in an RFC. The NEA WG will > investigate the use of a standard syntax for all attributes. > > The PB (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. > > The PT (Posture Transport) protocol carries the PB protocol. > > The NEA working group will not specify protocols other than PA and PB > at this time. The expectation is that an existing protocol can be used > for the PT. > > One commonly discussed issue with NEA systems is how to handle > compromised endpoints, whose reports of their own posture may not be > accurate. Detecting or handling such endpoints is out of scope of the > NEA WG. Work on PA will focus on attributes useful for assessing > posture of those endpoints reporting accurate information. However, the > protocols developed by the NEA WG must be designed to accommodate > emerging technologies for identifying and dealing with lying endpoints. > > Note that NEA is not chartered to develop standard protocols for > remediation. NEA is intended to be used with new or existing tools that > can be used in the absence of NEA. NEA is applicable to computing > enterprise environments, where endpoints accessing the enterprise's > network are owned and/or expected to conform to the policies set forth > by the organization that owns and operates the network. All other > cases are outside the scope of the NEA charter, since we do not know > that NEA would be useful in such cases. NEA applicability and security > considerations will be described in the appropriate NEA documents. > > Further work in the NEA WG will be considered via the rechartering > process after the completion of these milestones. > > Milestones: > > November 2006: > * At IETF 67, discuss issues with NEA Requirements I-D > * Submit first draft of NEA Requirements I-D > * Agree on solutions to issues with NEA Requirements I-D > > December 2007: > * Submit revised requirements I-D > > February 2007: > * WGLC on NEA Requirements I-D > > March 2007: > * At IETF 68, resolve any open issues with requirements I-D > > April 2007: > * Submit NEA Requirements I-D to the IESG for IETF Last Call > and publication as an Informational RFC > > _______________________________________________ > 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 Tue Nov 07 17:03:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhZ2P-0003DX-DJ; Tue, 07 Nov 2006 17:03:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhYpz-0001ko-02 for nea@ietf.org; Tue, 07 Nov 2006 16:50:31 -0500 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhYpt-0002Ou-RF for nea@ietf.org; Tue, 07 Nov 2006 16:50:30 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 07 Nov 2006 13:47:35 -0800 X-IronPort-AV: i="4.09,397,1157353200"; d="ppt'32?scan'32,208,32"; a="615680409:sNHT230959148" X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C702B6.BA8AC742" Date: Tue, 7 Nov 2006 16:50:24 -0500 Message-ID: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Slides for today's NEA session Thread-index: AccCteCQci9AzI6MSziYK+P/mnUTgA== From: "Stephen Hanna" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 79e1ea95334c34a95f01d2cb7dc66a55 X-Mailman-Approved-At: Tue, 07 Nov 2006 17:03:20 -0500 Subject: [Nea] Slides for today's NEA session 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_01C702B6.BA8AC742 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here are the slides for today's NEA WG session. These will probably be especially useful for remote participants. Thanks, Steve ------_=_NextPart_001_01C702B6.BA8AC742 Content-Type: application/vnd.ms-powerpoint; name="NEA_WG_Nov_2006v4.ppt" Content-Transfer-Encoding: base64 Content-Description: NEA_WG_Nov_2006v4.ppt Content-Disposition: attachment; filename="NEA_WG_Nov_2006v4.ppt" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAApwAAAAAAAAAA EAAAqQAAAAEAAAD+////AAAAAKMAAACoAAAA//////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////8P AOgDNSAAAAEA6QMoAAAAgBYAAOAQAAAAEgAAoBcAAAUAAAAKAAAAEQAAAAAAAAABAAAAAAEAAQ8A 8gMUAQAALwDIDwwAAAAwANIPBAAAAAEAAAAPANUHTAAAAAAAtw9EAAAAQQByAGkAYQBsAAAAyIMT ADZUFDDIgxMAAAAAADAA0g9glhMAYJYTAMRqtw3ogxMAl1QUMOiDEwAAAAAADwDVBwAABAAAAKQP CAAAAIAAQAAAAP//AAClDwwAAAAAAAAILgAAAAcAAAAAAKkPCgAAAAcAAAACAAkEAABAAKMPbgAA AAUA//0/AAAAIiAAAGQAAAAA/wAAZAAAAAAAAAAAAEACAAAAAAcAAAD//+8AAAAAAP///////xIA AAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAADwAL BIwCAAAPAADwhAIAAAAABvAgAgAABggBAEMAAADqAAAAGQAAAAEAAAAHAAAAAgAAAAQAAAADAAAA BAAAAAQAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAACAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAPAAAABAAAABAAAAAIAAAAEQAAAAQA AAAAAAAABAAAABMAAAAEAAAAAAAAAAgAAAAAAAAABgAAAAAAAAAGAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAABwAAAAjAAAAHQAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAALQAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAqAAAAIwAAACsAAAAEAAAALAAAAAQAAAAtAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAAAAAABAAAADEAAAAEAAAAMgAAAAQAAAAzAAAAJgAAADQAAAAEAAAAAAAA AB8AAAAAAAAABAAAADcAAAAlAAAAOAAAAAQAAAA5AAAAKwAAADoAAAAEAAAAAAAAAEUAAAAAAAAA BAAAAD0AAAAIAAAAPgAAAAQAAAAAAAAAJwAAAAAAAAAEAAAAAAAAAAgAAAAAAAAABgAAAIMAC/Aw AAAAgQEEAAAIgwEAAAAIhkEAAAAAvwEQABAAwAEBAAAIxUEAAAAA/wEIAAgAAQICAAAIEAAa8QQA AAD/W1sAQAAe8RAAAAAHAAAIAQAACAIAAAj3AAAQHwDwDxwAAAAAAPMDFAAAAAIAAAAAAAAAAAAA AAAAAIAAAAAADwDQBzMBAAAfABQEHAAAAAAAFQQUAAAAupOw9gDKmjutB5THAMqaOwEBAAAPAPoD ZwAAAAAA/gMDAAAAAAEAAAD9AzQAAAA/AAAAZAAAAD8AAABkAAAAAAAAAOwItw0AhBMAl1QUMAAA AAAAAAAAoP///wT///8BABMAcAD7AwgAAAAAAAAAcAgAAHAA+wMIAAAAAQAAAEALAAAfABMEPAAA AAAA/QM0AAAAZAAAAGQAAABkAAAAZAAAACyEEwCcIRQwYJYTAKBqtw0AAAAAAAAAAAAAAAAAAAAA AAETAB8A/wMUAAAAAgAABAwAAAAAAAAAAAAAAAIAAAAPAIgTOAAAAA8AihMwAAAAAAC6DxAAAABf AF8AXwBQAFAAVAAxADAAAACLExAAAAAAAA0ECAAAAADAAAAAwAAAPwDZD1IAAAAAANoPBAAAAAAA LQAAALoPIAAAAE4AbwB2AGUAbQBiAGUAcgAgADcALAAgADIAMAAwADYAIAC6DxYAAABJAEUAVABG ACAATgBFAEEAIABXAEcATwDZDwwAAAAAANoPBAAAAA0APQAPAPAP5BkAAAAA8wMUAAAAAwAAAAAA AAACAAAAAAEAAAAAAAAAAJ8PBAAAAAYAAAAAAKgPLwAAAElFVEYgTkVBIFdHCyhORUEgPSBOZXR3 b3JrIEVuZHBvaW50IEFzc2Vzc21lbnQpAAChDxwAAAAwAAAAAAAAAAAADAAAAAAAAAAkAAAAAAAC ACAAEACfDwQAAAAFAAAAAACgD04BAABuAGUAYQBbAC0AcgBlAHEAdQBlAHMAdABdAEAAaQBlAHQA ZgAuAG8AcgBnAA0AQwBoAGEAaQByAHMAOgAJAFMAdABlAHYAZQAgAEgAYQBuAG4AYQAsACAASgB1 AG4AaQBwAGUAcgAJAHMAaABhAG4AbgBhAEAAagB1AG4AaQBwAGUAcgAuAG4AZQB0AA0ACQBTAHUA cwBhAG4AIABUAGgAbwBtAHMAbwBuACwAIABDAGkAcwBjAG8ACQBzAGUAdABoAG8AbQBzAG8AQABj AGkAcwBjAG8ALgBjAG8AbQANAA0ASQBFAFQARgAgADYANwAsACAAVAB1AGUAcwBkAGEAeQAsACAA TgBvAHYAZQBtAGIAZQByACAANwAsACAAMgAwADAANgAsACAAMwA6ADIAMAAgAFAATQAgABMgIAA1 ADoAMgAwACAAUABNAA0AAAChDzgAAAAXAAAAAAAAEAAAUABaAAAAAAAAGAAAAABQADcAAAAAAAAQ AABQABcAAAAAAAAAkQAAAAAAAgAUAAAAqg82AAAAFgAAAAEAAAABAB4AAAAAAAAAEgAAAAEAAAAB ABcAAAAAAAAAEgAAAAEAAAABADkAAAAAAAAADwDyDxgAAAAAAPMPEAAAAAAAAAAAAAAAAAAAAAhK FDAAAN8PCAAAADQAAABGAAAADwDyDxgAAAAAAPMPEAAAAAAAAAAAAAAAAAAAAAhKFDAAAN8PCAAA AF0AAABvAAAAAADzAxQAAAAEAAAAAAAAAAIAAAABAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8NAAAA QWdlbmRhIFJldmlldxAAnw8EAAAAAQAAAAAAqA+UAAAAMzoyMAlCbHVlIFNoZWV0cywgSmFiYmVy ICYgTWludXRlcyBTY3JpYmVzDTM6MjUJQWdlbmRhIEJhc2hpbmcNMzozMAlORUEgTWlsZXN0b25l cw0zOjQwCURpc2N1c3Npb24gb2YgUmVxdWlyZW1lbnRzIEktRA01OjEwCU5leHQgU3RlcHMNNToy MAlBZGpvdXJuDQAAoQ8eAAAAlAAAAAAAAQAAAAAAAQAAAAAAAAAAAJUAAAAAAAAAAADzAxQAAAAQ AAAAAAAAAAIAAAANAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8OAAAATkVBIE1pbGVzdG9uZXMQAJ8P BAAAAAEAAAAAAKAPlgEAAEYAaQByAHMAdAAgAE0AaQBsAGUAcwB0AG8AbgBlAHMADQBQAHIAZQBw AGEAcgBlACAATgBFAEEAIABSAGUAcQB1AGkAcgBlAG0AZQBuAHQAcwAgAEkALQBEACAAKABOAG8A dgAtAEoAYQBuACkADQBXAEcATABDACAAbwBuACAATgBFAEEAIABSAGUAcQB1AGkAcgBlAG0AZQBu AHQAcwAgAEkALQBEACAAKABGAGUAYgAgABggMAA3ACkADQBJAEUAVABGACAATABDACAAbwBuACAA TgBFAEEAIABSAGUAcQB1AGkAcgBlAG0AZQBuAHQAcwAgAEkALQBEACAAKABBAHAAcgAgABggMAA3 ACkADQANAFQAaABlAG4AIAB3AGUAGSBsAGwAIABhAGQAZAAgAG0AaQBsAGUAcwB0AG8AbgBlAHMA IABmAG8AcgAgAFAAQQAsACAAUABCACwAIABlAHQAYwAuAA0AUwB1AGIAagBlAGMAdAAgAHQAbwAg AEEARAAgAGEAcABwAHIAbwB2AGEAbAAAAKEPTAAAABEAAAAAAAAAAAB5AAAAAQAAAAAAKwAAAAAA AAAAABcAAAABAAAAAAARAAAAAAAAAHkAAAAAAAAAKwAAAAAEAAAABBcAAAAACAAAAAgAAPMDFAAA AAkAAAAAAAAAAgAAAAYBAAAAAAAAAACfDwQAAAAAAAAAAACoDx4AAABORUEgUm9sZXMgYW5kIFJl c3BvbnNpYmlsaXRpZXMQAJ8PBAAAAAEAAAAAAKgPpwEAAE5FQSBSZXF1aXJlbWVudHMgRGVzaWdu IFRlYW0gYW5kIEVkaXRvcnMNVm9sdW50ZWVycyBzb2xpY2l0ZWQgb24gbGlzdCBhbmQgYXQgSUVU RiA2Nw1TZWxlY3RlZCBieSBORUEgV0cgY2hhaXJzDQ1EZXZlbG9wIGluaXRpYWwgUmVxdWlyZW1l bnRzIEktRA1SZXZpc2UgSS1EIGluIHJlc3BvbnNlIHRvIFdHIHJvdWdoIGNvbnNlbnN1cw0NTkVB IFdHIFBhcnRpY2lwYW50cw1SZXZpZXcgZHJhZnQgZG9jdW1lbnRzDURpc2N1c3Mgb24gZW1haWwg bGlzdCBhbmQgYXQgSUVURiBtZWV0aW5ncw1SZWFjaCByb3VnaCBjb25zZW5zdXMgb24gZW1haWwg bGlzdA0NTkVBIFdHIENoYWlycw1TZWxlY3QgRGVzaWduIFRlYW1zIGFuZCBFZGl0b3JzDU1vZGVy YXRlIFdHIGRpc2N1c3Npb25zDUp1ZGdlIHJvdWdoIGNvbnNlbnN1cw1NYW5hZ2UgV0cgcHJvY2Vz cwAAoQ+MAAAAKQAAAAAAABAAAFAAlgAAAAEAABAAAFAAFAAAAAAAABAAAFAAZwAAAAEAABAAAFAA DgAAAAAAABAAAFAAYAAAAAEAABAAAFAAKQAAAAAAAgASAJYAAAAAAAIAEAAUAAAAAAQCAAAEEgBn AAAAAAQCAAAEEAAOAAAAAAgCAAAIEgBgAAAAAAwCAAAMEAAAAPMDFAAAAC0AAAAAAAAAAgAAACcB AAAAAAAAAACfDwQAAAAAAAAAAACoDw8AAABHb2FscyBmb3IgVG9kYXkQAJ8PBAAAAAEAAAAAAKgP awAAAERpc2N1c3MgUmVxdWlyZW1lbnRzIEktRA1HZXQgZmVlZGJhY2sgb24gY3VycmVudCBpZGVh cw0NUmVjcnVpdCB2b2x1bnRlZXJzIGZvciBORUEgUmVxdWlyZW1lbnRzIERlc2lnbiBUZWFtAACh DzYAAAAZAAAAAAAAAAAAHwAAAAEAAAAAADQAAAAAAAAAAAAZAAAAAAAAAB8AAAAAAAAANAAAAAAA AAAAAPMDFAAAAAUAAAAAAAAAAgAAAAIBAAAAAAAAAACfDwQAAAAAAAAAAACoDxgAAABSZXF1aXJl bWVudHMgSS1EIE91dGxpbmUQAJ8PBAAAAAEAAAAAAKAP2gEAAEEAYgBzAHQAcgBhAGMAdAAsACAA QgBvAGkAbABlAHIAcABsAGEAdABlAA0ASQBuAHQAcgBvAGQAdQBjAHQAaQBvAG4ADQBUAGUAcgBt AGkAbgBvAGwAbwBnAHkADQBBAHAAcABsAGkAYwBhAGIAaQBsAGkAdAB5AA0AUAByAG8AYgBsAGUA bQAgAFMAdABhAHQAZQBtAGUAbgB0AA0AUgBlAGYAZQByAGUAbgBjAGUAIABNAG8AZABlAGwADQBV AHMAZQAgAEMAYQBzAGUAcwANAFIAZQBxAHUAaQByAGUAbQBlAG4AdABzAA0AQwBvAG0AbQBvAG4A DQBQAHIAbwB0AG8AYwBvAGwALQBzAHAAZQBjAGkAZgBpAGMAIAAoAFAAQQAsACAAUABCACwAIABQ AFQAKQANAFMAZQBjAHUAcgBpAHQAeQAgAEEAbgBhAGwAeQBzAGkAcwAvAEMAbwBuAHMAaQBkAGUA cgBhAHQAaQBvAG4AcwANAFIAZQBmAGUAcgBlAG4AYwBlAHMALAAgAEUAZABpAHQAbwByAHMAGSAg AEEAZABkAHIAZQBzAHMAZQBzACwAIABBAGMAawBuAG8AdwBsAGUAZABnAGUAbQBlAG4AdABzAAAA oQ9CAAAAdgAAAAAAABAAAFAAJgAAAAEAABAAAFAAUgAAAAAAABAAAFAAdgAAAAAAAgAYACYAAAAA AAIAFABSAAAAAAACABgAAADzAxQAAAAUAAAAAAAAAAIAAAAQAQAAAAAAAAAAnw8EAAAAAAAAAAAA qA8LAAAAVGVybWlub2xvZ3kQAJ8PBAAAAAEAAAAAAKgPDQEAAEVuZHBvaW50DUEgaG9zdCB0aGF0 IGNhbiBiZSBjb25uZWN0ZWQgdG8gYSBuZXR3b3JrDUxhcHRvcCwgZGVza3RvcCwgc2VydmVyLCBw cmludGVyLCBjZWxsIHBob25lLAthbnkgZGV2aWNlIHdpdGggYW4gSVAgYWRkcmVzcw0NUG9zdHVy ZQ1FbmRwb2ludCBzZWN1cml0eS1yZWxldmFudCBjb25maWd1cmF0aW9uDU9TIGFuZCBhcHBsaWNh dGlvbiB2ZXJzaW9uIGFuZCBwYXRjaCBsZXZlbCwgc2VjdXJpdHkgc29mdHdhcmUgY29uZmlndXJh dGlvbiBhbmQgc3RhdHVzLCBldGMuAAChD4oAAAAJAAAAAAAAAAAAKgAAAAEAAAAAAEwAAAACAAAA AAABAAAAAQAAAAAACAAAAAAAAAAAACkAAAABAAAAAABdAAAAAgAAAAAACQAAAAAAAAAqAAAAAAQA AAAETAAAAAAEAAAABAEAAAAACAAAAAgIAAAAAAgAAAAIKQAAAAAMAAAADF0AAAAAEAAAABAAAPMD FAAAABIAAAAAAAAAAgAAAA4BAAAAAAAAAACfDwQAAAAAAAAAAACoDxEAAABQcm9ibGVtIFN0YXRl bWVudBAAnw8EAAAAAQAAAAAAqA87AQAAQXNzZXNzIGVuZHBvaW50IHBvc3R1cmUNDVZhcmlvdXMg YWN0aW9ucyBtYXkgZm9sbG93DUluLXNjb3BlDURlbGl2ZXIgYXNzZXNzbWVudCByZXN1bHQgdG8g ZW5kcG9pbnQNRGVsaXZlciByZW1lZGlhdGlvbiBpbnN0cnVjdGlvbnMgdG8gZW5kcG9pbnQNT3V0 LW9mLXNjb3BlIGJ1dCBtdXN0IGJlIGFjY29tbW9kYXRlZA1FdmFsdWF0ZSBwb3N0dXJlIHBvbGlj eSBjb21wbGlhbmNlDU1vbml0b3IgY29tcGxpYW5jZQ1CaW5kaW5nIHRvIG5ldHdvcmsgYWNjZXNz IGNvbnRyb2wgcHJvdG9jb2xzDVJlbWVkaWF0ZQ1JZGVudGlmeSBseWluZyBlbmRwb2ludHMNAACh D6YAAAAYAAAAAAAAEAAAWgABAAAAAQAAEAAAWgAbAAAAAAAAEAAAWgAJAAAAAQAAEAAAWgBTAAAA AgAAEAAAWgAmAAAAAQAAEAAAWgCGAAAAAgAAEAAAWgAYAAAABAACAAQAHAABAAAAAAACABgAGwAA AAAEAgAABBwACQAAAAAIAgAACBgAUwAAAAAIAgAACBQAJgAAAAAMAgAADBgAhgAAAAAQAgAAEBQA AADzAxQAAAAbAAAABAAAAAIAAAAXAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8TAAAATkVBIFJlZmVy ZW5jZSBNb2RlbAAAoQ8eAAAAFAAAAAAAAAAAABMAAAAAAAIAKAABAAAAAAACACAAEACfDwQAAAAB AAAAAACqDwoAAAABAAAAAQAAAAAAAADzAxQAAAAmAAAABAAAAAIAAAAiAQAAAAAAAAAAnw8EAAAA AAAAAAAAqA8TAAAATkVBIFJlZmVyZW5jZSBNb2RlbAAAoQ8eAAAAFAAAAAAAAAAAABMAAAAAAAIA KAABAAAAAAACACAAEACfDwQAAAABAAAAAACqDwoAAAABAAAAAQAAAAAAAADzAxQAAAA4AAAAAAAA AAIAAAAtAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8JAAAAVXNlIENhc2VzEACfDwQAAAABAAAAAACo D24AAABHb2Fscw1TcGFuIHRoZSBwcm9ibGVtIHNwYWNlDURyaXZlIHJlcXVpcmVtZW50cw0NTm9u LUdvYWxzDUxpc3QgYWxsIHVzZSBjYXNlcw1EZXNjcmliZSBkZXRhaWxzIG9mIFBUIHByb3RvY29s cwAAoQ9MAAAABgAAAAAAAAAAACsAAAABAAAAAAAKAAAAAAAAAAAANAAAAAEAAAAAAAYAAAAAAAAA KwAAAAAAAAAKAAAAAAQAAAAENAAAAAAIAAAACAAA8wMUAAAAKQAAAAAAAAACAAAAIwEAAAAAAAAA AJ8PBAAAAAAAAAAAAKgPDgAAAFR5cGVzIG9mIEZsb3dzEACfDwQAAAABAAAAAACoD9EAAABJbml0 aWFsIGFzc2Vzc21lbnQgb2YgZW5kcG9pbnQNVHJpZ2dlcmVkIGJ5IE5ldHdvcmsgQ29ubmVjdGlv bg1UcmlnZ2VyZWQgYnkgU2VydmljZSBSZXF1ZXN0DQ1SZS1hc3Nlc3NtZW50IG9mIGVuZHBvaW50 DVRyaWdnZXJlZCBieSBORUEgU2VydmVyICh0aW1lciwgZXZlbnQsIGV0Yy4pDVRyaWdnZXJlZCBi eSBORUEgQ2xpZW50ICh0aW1lciwgZXZlbnQsIGV0Yy4pDQAAoQ90AAAAHwAAAAAAIAAAAAAAAAE9 AAAAAQAgAAAAAAAAAQEAAAAAACEAAAAAAAAAAAEaAAAAAAAgAAAAAAAAAVsAAAABACAAAAAAAAAB HwAAAAAAAAA9AAAAAAAAAAEAAAAAAAAAGgAAAAAEAAAABFsAAAAACAAAAAgAAPMDFAAAACoAAAAA AAAAAgAAACQBAAAAAAAAAACfDwQAAAAAAAAAAACoDxMAAABUeXBlcyBvZiBBdHRyaWJ1dGVzEACf DwQAAAABAAAAAACoD0kBAABFbmRwb2ludCBEYXRhIChjbGllbnQgdG8gc2VydmVyKQ1CeSB2YWx1 ZQ1CeSByZWZlcmVuY2UNDUNvbXBsaWFuY2UgUG9saWN5IChzZXJ2ZXIgdG8gY2xpZW50KQ0NQ29t cGxpYW5jZSBQb2xpY3kgRXZhbHVhdGlvbiBSZXN1bHRzIChjbGllbnQgdG8gc2VydmVyKQ0NQ3J5 cHRvZ3JhcGhpYyBQcm90b2NvbHMgKG11bHRpcGxlIHJvdW5kIHRyaXBzKQ1Qcm9vZiBvZiBwb3Nz ZXNzaW9uDVJlcGxheSBwcm90ZWN0aW9uIG1lY2hhbmlzbXMNDUNvbXBsaWFuY2UgUmVzdWx0IChz ZXJ2ZXIgdG8gY2xpZW50KQ0NUmVtZWRpYXRpb24gSW5zdHJ1Y3Rpb25zIChzZXJ2ZXIgdG8gY2xp ZW50KQAAoQ+IAAAAIQAAAAAAIBAAAAAAAAFQABcAAAABACAQAAAAAAABUACOAAAAAAAgEAAAAAAA AVAAMgAAAAEAIBAAAAAAAAFQAFIAAAAAACAQAAAAAAABUAAhAAAAAAACABIAFwAAAAAAAgAQAI4A AAAABAIAAAQSADIAAAAABAIAAAQQAFIAAAAABAIAAAQSAAAA8wMUAAAALgAAAAQAAAACAAAAKAEA AAAAAAAAAJ8PBAAAAAAAAAAAAKgPEwAAAEVtcGxveWVlIEpvaG4gU21pdGgAAKEPFAAAABQAAAAA AAAAAAAUAAAAAAACACAAEACfDwQAAAABAAAAAACqDwoAAAABAAAAAQAAAAAAAADzAxQAAAAyAAAA BAAAAAIAAAAqAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8SAAAAUHJvZmVzc29yIEphbmUgRG9lAACh DxQAAAATAAAAAAAAAAAAEwAAAAAAAgAgABAAnw8EAAAAAQAAAAAAqg8KAAAAAQAAAAEAAAAAAAAA 8wMUAAAANAAAAAQAAAACAAAAKwEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPDwAAAENvbG9uZWwgTXVz dGFyZAAAoQ8UAAAAEAAAAAAAAAAAABAAAAAAAAIAIAAQAJ8PBAAAAAEAAAAAAKoPCgAAAAEAAAAB AAAAAAAAAPMDFAAAADkAAAAAAAAAAgAAAC4BAAAAAAAAAACfDwQAAAAAAAAAAACoDxAAAABPdGhl ciBVc2UgQ2FzZXM/EACfDwQAAAABAAAAAACoD1MAAABPdGhlciB1c2UgY2FzZXMgdGhhdDoNTXVz dCBiZSBhZGRyZXNzZWQgYnkgTkVBDURyaXZlIG5ldyBQQSwgUEIsIG9yIFBUIHJlcXVpcmVtZW50 cwAAoQ8mAAAAFgAAAAAAAAAAAD4AAAABAAAAAAAWAAAAAAAAAD4AAAAABAAAAAQAAPMDFAAAACwA AAAAAAAAAgAAACYBAAAAAAAAAACfDwQAAAAAAAAAAACoDwoAAABOZXh0IFN0ZXBzEACfDwQAAAAB AAAAAACoD4oAAABTb2xpY2l0IERlc2lnbiBUZWFtIENvbnRyaWJ1dG9ycw1UaHJvdWdoIE5vdmVt YmVyIDE2DQ1TdGFydCBEZXNpZ24gVGVhbSBXZWVrbHkgQ29uY2FsbHMNV2VlayBvZiBOb3ZlbWJl ciAyNw0NRmlyc3QgUmVxdWlyZW1lbnRzIEktRCBQb3N0ZWQAAKEPYAAAACEAAAAAAAAAAAAVAAAA AQAAAAAAIgAAAAAAAAAAABUAAAABAAAAAAAeAAAAAAAAAAAAIQAAAAAAAAAVAAAAAAAAACIAAAAA BAAAAAQVAAAAAAQAAAAEHgAAAAAEAAAABAAAqg8aAAAATwAAAAAAAAAIAAAAAQAAAAEANAAAAAAA AAAvAPAPjAAAAAAA8wMUAAAAHQAAAAAAAAAAAAAAAAEAAAAAAAAAAPMDFAAAACgAAAAAAAAAAAAA AAEBAAAAAAAAAADzAxQAAAAvAAAAAAAAAAAAAAACAQAAAAAAAAAA8wMUAAAAMwAAAAAAAAAAAAAA BAEAAAAAAAAAAPMDFAAAADUAAAAAAAAAAAAAAAUBAAAAAAAAAADqAwAAAAAPAPgD8gkAAAIA7wMY AAAAAQAAAAECBwkIAAAAAAAAAAAAAAAAABQwYADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMz mQAAmZkAmcwAAGAA8AcgAAAA////AAAAAACWlpYAAAAAAPvfUwD/mWYAzDMAAJlmAABgAPAHIAAA AP///wAAAAAAgICAAAAAAACZzP8AzMz/ADMzzACvZ/8AYADwByAAAADe9vEAAAAAAJaWlgAAAAAA ////AI3G/wAAZswAAKgAAGAA8AcgAAAA///ZAAAAAAB3d3cAAAAAAP//9wAzzMwA/1BQAP+ZAABg APAHIAAAAACAgAD///8AAFpYAP//mQAAZGIAbW/HAAD//wAA/wAAYADwByAAAACAAAAA////AFwf AADf0pMAzDMAAL55YAD//5kA06IZAGAA8AcgAAAAAACZAP///wAAM2YAzP//ADNmzAAAsAAAZsz/ AP/nAQBgAPAHIAAAAAAAAAD///8AM2aZAOPr8QAAM5kARopLAGbM/wDw5QAAYADwByAAAABoa10A ////AHd3dwDR0csAkJCCAICeqAD/zGYA6dy5AGAA8AcgAAAAZmaZAP///wA+PlwA////AGBZewBm Zv8Amcz/AP//mQBgAPAHIAAAAFI+JgD///8ALSAVAN/AjQCMe3AAj18vAMy0AACMnqAAAACjDz4A AAABAP/9PwAAACIgAABkAAAAAP8BAGQAAAAAAAAAAABAAgAAAAAHAAAA///vAAAAAAD///////8s AAAAAAMAABAAow98AAAABQD//T8AAQAiIAAAZAAAAAD/AABkABQAAADYAAAAQAIAAAAABwAAAP// 7wAAAAAA////////IAAAAAABAACABQAAEyDUASABAAACABwAgAUAACIg0AJAAgAAAgAYAIAFAAAT IPADYAMAAAIAFACABQAAuwAQBYAEAAAAACAAow9uAAAABQD//T8AAAAiIAAAZAAAAAD/AABkAB4A AAAAAAAAQAIAAAAABwAAAP//7wAAAAAA////////DAAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJA AgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAABQAKMPUgAAAAUAAAABCQAAAAABAAAAAAAAAAEA AQkAAAAAAQAgAQAAAAACAAEJAAAAAAEAQAIAAAAAAwABCQAAAAABAGADAAAAAAQAAQkAAAAAAQCA BAAAAABgAKMPDAAAAAEAAAAAAAAAAAAAAHAAow8+AAAABQAAAAAAAAAAAAIAHAABAAAAAAAAAAIA GAACAAAAAAAAAAIAFAADAAAAAAAAAAIAEgAEAAAAAAAAAAIAEgCAAKMPPgAAAAUAAAAAAAAAAAAC ABgAAQAAAAAAAAACABQAAgAAAAAAAAACABIAAwAAAAAAAAACABAABAAAAAAAAAACABAADwAMBCQF AAAPAALwHAUAABAACPAIAAAABgAAAAYEAAAPAAPwtAQAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAA AAAAAAAAAAAAAgAK8AgAAAAABAAABQAAAA8ABPDSAAAAEgAK8AgAAAACBAAAAAoAAJMAC/A2AAAA fwABAAUAgAAwJrcNhwABAAAAgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ 8AgAAACtACABYBV9Aw8AEfAQAAAAAADDCwgAAAAAAAAAAQC3DQ8ADfBUAAAAAACfDwQAAAAAAAAA AACoDyAAAABDbGljayB0byBlZGl0IE1hc3RlciB0aXRsZSBzdHlsZQAAog8GAAAAIQAAAAAAAACq DwoAAAAhAAAAAQAAAAAADwAE8BYBAAASAArwCAAAAAMEAAAACgAAgwAL8DAAAAB/AAEABQCAAOin cxuBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAPADIAFgFRMPDwAR 8BAAAAAAAMMLCAAAAAEAAAACALcNDwAN8J4AAAAAAJ8PBAAAAAEAAAAAAKgPUgAAAENsaWNrIHRv IGVkaXQgTWFzdGVyIHRleHQgc3R5bGVzDVNlY29uZCBsZXZlbA1UaGlyZCBsZXZlbA1Gb3VydGgg bGV2ZWwNRmlmdGggbGV2ZWwAAKIPHgAAACEAAAAAAA0AAAABAAwAAAACAA0AAAADAAwAAAAEAAAA qg8KAAAAUwAAAAEAAAAAAA8ABPDQAAAAEgAK8AgAAAAEBAAAAAoAAIMAC/AwAAAAfwABAAUAgABY lHMbgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAABeDyABYAaKEA8A EfAQAAAAAADDCwgAAAACAAAABwG3DQ8ADfBYAAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8U AAAAAgAAAAAAAAAAAAIAAAAAAAIADgAAAPgPBAAAAAAAAAAAAKoPEgAAAAEAAAABAAAAAAABAAAA AAAAAA8ABPDSAAAAEgAK8AgAAAAFBAAAAAoAAIMAC/AwAAAAfwABAAUAgAAsmHMbgQEEAAAIgwEA AAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAABeD7AH0A6KEA8AEfAQAAAAAADDCwgA AAADAAAACQK3DQ8ADfBaAAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8WAAAAAgAAAAAAAAgA AAEAAgAAAAAAAgAOAAAA+g8EAAAAAAAAAAAAqg8SAAAAAQAAAAEAAAAAAAEAAAAAAAAADwAE8NIA AAASAArwCAAAAAYEAAAACgAAgwAL8DAAAAB/AAEABQCAAKCbcxuBAQQAAAiDAQAAAAi/AQEAEQDA AQEAAAj/AQEACQABAgIAAAgAABDwCAAAAF4PIBBgFYoQDwAR8BAAAAAAAMMLCAAAAAQAAAAIAnMb DwAN8FoAAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxYAAAACAAAAAAAACAAAAgACAAAAAAAC AA4AAADYDwQAAAAAAAAAAACqDxIAAAABAAAAAQAAAAAAAQAAAAAAAAAPAATwSAAAABIACvAIAAAA AQQAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAA AD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTOAAAAA8A ihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAAOsuCAAAAKr+xgEQ7r/8IAC6 DxwAAABEAGUAZgBhAHUAbAB0ACAARABlAHMAaQBnAG4ADwDwAwgHAAABAPEDCAAAAAAAAIAAABQw DwAMBIgGAAAPAALwgAYAAAABCPAIAAAABwAAAAdAAAAPAAPwGAYAAA8ABPAoAAAAAQAJ8BAAAAAA AAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAQAAABQAAAA8ABPAEAQAAEgAK8AgAAAACQAAAAAoAANMA C/BOAAAAfwABAAUAgACYVysOgQCVeQEAggDLvAAAgwCVeQEAhADLvAAAvwAQAB8AgQEEAAAIgwEA AAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAAAAAAAAzQcuAQ8AEfAQAAAAAADDCwgA AAAAAAAACgK3DQ8ADfBuAAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8UAAAAAgAAAAAAAAAA AAIAAAAAAAIADQAAAPkPBAAAAAAAAAAAAKoPCgAAAAIAAAABAAAAAAAAAKYPFgAAAPEeAABhAjAB MAFhAmECkQORA8IEwgQPAATwBgEAABIACvAIAAAAA0AAAAAKAADTAAvwTgAAAH8AAQAFAIAA6G8r DoEAlXkBAIIAy7wAAIMAlXkBAIQAy7wAAL8AEAAfAIEBBAAACIMBAAAACL8BAQARAMABAQAACP8B AQAJAAECAgAACAAAEPAIAAAAAAAyCv8RLgEPABHwEAAAAAAAwwsIAAAAAQAAAAcAtw0PAA3wcAAA AAAAnw8EAAAABAAAAAAAoA8CAAAAKgAAAKEPFgAAAAIAAAAAAAAIAAACAAIAAAAAAAIADQAAAPgP BAAAAAAAAAAAAKoPCgAAAAIAAAABAAAAAAAAAKYPFgAAAPEeAABhAjABMAFhAmECkQORA8IEwgQP AATwZAAAABIACvAIAAAABEAAAAAKAABjAAvwJAAAAH8ABAEEAYcAAQAAAH8BAAABAL8BEQARAP8B CAAJAD8CAQABAAAAEPAIAAAAxgEYA+gOogoPABHwEAAAAAAAwwsIAAAAAgAAAAUAKw4PAATwNAEA ABIACvAIAAAABUAAAAAKAADTAAvwTgAAAH8AAQAFAIAATGUrDoEAlXkBAIIAy7wAAIMAlXkBAIQA y7wAAL8AEAAfAIEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACAAAEPAIAAAAOQvN ATMQ2hUPABHwEAAAAAAAwwsIAAAAAwAAAAYCKw4PAA3wngAAAAAAnw8EAAAAAgAAAAAAqA9SAAAA Q2xpY2sgdG8gZWRpdCBNYXN0ZXIgdGV4dCBzdHlsZXMNU2Vjb25kIGxldmVsDVRoaXJkIGxldmVs DUZvdXJ0aCBsZXZlbA1GaWZ0aCBsZXZlbAAAog8eAAAAIQAAAAAADQAAAAEADAAAAAIADQAAAAMA DAAAAAQAAACqDwoAAABTAAAAAQAAAAAADwAE8AoBAAASAArwCAAAAAZAAAAACgAA4wAL8FQAAAB/ AAEABQCAANwnKw6BAJV5AQCCAMu8AACDAJV5AQCEAMu8AACHAAIAAAC/ABAAHwCBAQQAAAiDAQAA AAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAHEWAADNB58XDwAR8BAAAAAAAMMLCAAA AAQAAAAJAisODwAN8G4AAAAAAJ8PBAAAAAQAAAAAAKAPAgAAACoAAAChDxQAAAACAAAAAAAAAAAA AgAAAAAAAgANAAAA+g8EAAAAAAAAAAAAqg8KAAAAAgAAAAEAAAAAAAAApg8WAAAA8R4AAGECMAEw AWECYQKRA5EDwgTCBA8ABPAMAQAAEgAK8AgAAAAHQAAAAAoAAOMAC/BUAAAAfwABAAUAgAAsIisO gQCVeQEAggDLvAAAgwCVeQEAhADLvAAAhwACAAAAvwAQAB8AgQEEAAAIgwEAAAAIvwEBABEAwAEB AAAI/wEBAAkAAQICAAAIAAAQ8AgAAABxFjIK/xGfFw8AEfAQAAAAAADDCwgAAAAFAAAACAIrDg8A DfBwAAAAAACfDwQAAAAEAAAAAACgDwIAAAAqAAAAoQ8WAAAAAgAAAAAAAAgAAAIAAgAAAAAAAgAN AAAA2A8EAAAAAAAAAAAAqg8KAAAAAgAAAAEAAAAAAAAApg8WAAAA8R4AAGECMAEwAWECYQKRA5ED wgTCBA8ABPBIAAAAEgAK8AgAAAABQAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwHOt28AlAF+ mZIAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMz mQAAmZkAmcwAAA8AiBM4AAAADwCKEzAAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTEAAA AAAA6y4IAAAAf//GAXD9FBMPAO4DfQIAAAIA7wMYAAAAAAAAAA8QAAAAAAAAAAAAgAAAAAAHABQw DwAMBJQBAAAPAALwjAEAACAACPAIAAAAAwAAAAMIAAAPAAPwJAEAAA8ABPAoAAAAAQAJ8BAAAAAA AAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAACAAABQAAAA8ABPByAAAAEgAK8AgAAAACCAAAIAIAAFMA C/AeAAAAfwAAAAQAgAAkWrcNvwEAAAEA/wEAAAEAAQMCBAAAAAAQ8AgAAACSArAB0BQwBg8AEfAQ AAAAAADDCwgAAAAAAAAADwC3DQ8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HIAAAASAArwCAAAAAMI AAAgAgAAUwAL8B4AAAB/AAAABACAAIQ+tw2/AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAAJAJoALg E+ANDwAR8BAAAAAAAMMLCAAAAAEAAAAQALcNDwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwSAAAABIA CvAIAAAAAQgAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAI AAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgT kQAAAA8AihOJAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE2kAAAAAAOsuCAAAAKr+xgEQ X8L8AAAAKwQAAAAAAAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAAB3Gf// //8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAADwACKwAAAAAPAO4DmwIAAAIA7wMYAAAAAQAAAA0O AAAAAAAAAAAAgAAAAAAHABQwDwAMBLIBAAAPAALwqgEAADAACPAIAAAAAwAAAAMMAAAPAAPwQgEA AA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAADAAABQAAAA8ABPByAAAA EgAK8AgAAAACDAAAIAIAAFMAC/AeAAAAfwAAAAQAgAAABLcNvwEAAAEA/wEAAAEAAQMCBAAAAAAQ 8AgAAACtACABYBV9Aw8AEfAQAAAAAADDCwgAAAAAAAAADQC3DQ8ADfAMAAAAAACeDwQAAAAAAAAA DwAE8JAAAAASAArwCAAAAAMMAAAgAgAAUwAL8B4AAAB/AAAABACAAOgedxm/AQAAAQD/AQAAAQAB AwMEAAAAABDwCAAAAPADIAFgFRMPDwAR8BAAAAAAAMMLCAAAAAEAAAAOALcNDwAN8CoAAAAAAJ4P BAAAAAEAAAAAAKYPFgAAAPgeAABlAoYD0gJeBM4DNgWmBA4GfgUPAATwSAAAABIACvAIAAAAAQwA AAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8D AQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTkQAAAA8AihOJ AAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE2kAAAAAAOsuCAAAAK7+xgFg9nqQAAAAKwQA AAAAAAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAAB3Gf////8SAAAADwA9 8Q0AAABAAULxBQAAAAEJAAAADwACKwAAAAAPAO4DfQIAAAIA7wMYAAAAAQAAAA0OAAAAAAAAAAAA gAAAAAAHABQwDwAMBJQBAAAPAALwjAEAAPAACPAIAAAAAwAAAAM8AAAPAAPwJAEAAA8ABPAoAAAA AQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAPAAABQAAAA8ABPByAAAAEgAK8AgAAAAC PAAAIAIAAFMAC/AeAAAAfwAAAAQAgADI0XcZvwEAAAEA/wEAAAEAAQMCBAAAAAAQ8AgAAACtACAB YBV9Aw8AEfAQAAAAAADDCwgAAAAAAAAADQB3GQ8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HIAAAAS AArwCAAAAAM8AAAgAgAAUwAL8B4AAAB/AAAABACAAKDSdxm/AQAAAQD/AQAAAQABAwMEAAAAABDw CAAAAPADIAFgFRMPDwAR8BAAAAAAAMMLCAAAAAEAAAAOAHcZDwAN8AwAAAAAAJ4PBAAAAAEAAAAP AATwSAAAABIACvAIAAAAATwAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8B EgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZ AJnMAAAPAIgTkQAAAA8AihOJAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE2kAAAAAAOsu CAAAAHn/xgFADYaaAAAAKwQAAAAAAAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAA AAAAAAB3Gf////8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAADwACKwAAAAAPAO4DfQIAAAIA7wMY AAAAAQAAAA0OAAAAAAAAAAAAgAAAAAAHABQwDwAMBJQBAAAPAALwjAEAAIAACPAIAAAAAwAAAAMg AAAPAAPwJAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAIAAABQAA AA8ABPByAAAAEgAK8AgAAAACIAAAIAIAAFMAC/AeAAAAfwAAAAQAgAAMF3cZvwEAAAEA/wEAAAEA AQMCBAAAAAAQ8AgAAACtACABYBV9Aw8AEfAQAAAAAADDCwgAAAAAAAAADQB3GQ8ADfAMAAAAAACe DwQAAAAAAAAADwAE8HIAAAASAArwCAAAAAMgAAAgAgAAUwAL8B4AAAB/AAAABACAAPwXdxm/AQAA AQD/AQAAAQABAwMEAAAAABDwCAAAAPADIAFgFRMPDwAR8BAAAAAAAMMLCAAAAAEAAAAOAHcZDwAN 8AwAAAAAAJ4PBAAAAAEAAAAPAATwSAAAABIACvAIAAAAASAAAAAMAACDAAvwMAAAAIEBAAAACIMB BQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACA gIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTkQAAAA8AihOJAAAAAAC6DxAAAABfAF8AXwBQAFAA VAAxADAAAACLE2kAAAAAAOsuCAAAAFT/xgEATInqAAAAKwQAAAAAAAAAHwBE8T0AAAAAACfxIAAA AAAAAAADAAAAAAAAAAAAAAAAAAAAAAB3Gf////8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAADwAC KwAAAAAPAO4DfQIAAAIA7wMYAAAAAQAAAA0OAAAAAAAAAAAAgAAAAAAHABQwDwAMBJQBAAAPAALw jAEAACADCPAIAAAAAwAAAAPIAAAPAAPwJAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAA AAAAAgAK8AgAAAAAyAAABQAAAA8ABPByAAAAEgAK8AgAAAACyAAAIAIAAFMAC/AeAAAAfwAAAAQA gABAAHMbvwEAAAEA/wEAAAEAAQMCBAAAAAAQ8AgAAACtACABYBV9Aw8AEfAQAAAAAADDCwgAAAAA AAAADQBzGw8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HIAAAASAArwCAAAAAPIAAAgAgAAUwAL8B4A AAB/AAAABACAAMhscxu/AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAAPADIAFgFRMPDwAR8BAAAAAA AMMLCAAAAAEAAAAOAHMbDwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwSAAAABIACvAIAAAAAcgAAAAM AACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQAB ABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTkQAAAA8AihOJAAAA AAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE2kAAAAAAOsuCAAAAHcCxwEQNQdxAAAAKwQAAAAA AAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAAB3Gf////8SAAAADwA98Q0A AABAAULxBQAAAAEJAAAADwACKwAAAAAPAO4DfQIAAAIA7wMYAAAAAQAAAA0OAAAAAAAAAAAAgAAA AAAHABQwDwAMBJQBAAAPAALwjAEAAEAACPAIAAAAAwAAAAMQAAAPAAPwJAEAAA8ABPAoAAAAAQAJ 8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAEAAABQAAAA8ABPByAAAAEgAK8AgAAAACEAAA IAIAAFMAC/AeAAAAfwAAAAQAgADAQncZvwEAAAEA/wEAAAEAAQMCBAAAAAAQ8AgAAACtACABYBV9 Aw8AEfAQAAAAAADDCwgAAAAAAAAADQB3GQ8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HIAAAASAArw CAAAAAMQAAAgAgAAUwAL8B4AAAB/AAAABACAANhjdxm/AQAAAQD/AQAAAQABAwMEAAAAABDwCAAA APADIAFgFRMPDwAR8BAAAAAAAMMLCAAAAAEAAAAOAHcZDwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATw SAAAABIACvAIAAAAARAAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgAS AP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnM AAAPAIgTkQAAAA8AihOJAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE2kAAAAAAOsuCAAA AK/+xgGwfPtlAAAAKwQAAAAAAAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAAAAAA AAB3Gf////8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAADwACKwAAAAAPAO4DfQIAAAIA7wMYAAAA AQAAAA0OAAAAAAAAAAAAgAAAAAAHABQwDwAMBJQBAAAPAALwjAEAADABCPAIAAAAAwAAAANMAAAP AAPwJAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAATAAABQAAAA8A BPByAAAAEgAK8AgAAAACTAAAIAIAAFMAC/AeAAAAfwAAAAQAgABEJ2cOvwEAAAEA/wEAAAEAAQMC BAAAAAAQ8AgAAACtACABYBV9Aw8AEfAQAAAAAADDCwgAAAAAAAAADQBnDg8ADfAMAAAAAACeDwQA AAAAAAAADwAE8HIAAAASAArwCAAAAANMAAAgAgAAUwAL8B4AAAB/AAAABACAABwoZw6/AQAAAQD/ AQAAAQABAwMEAAAAABDwCAAAAPADIAFgFRMPDwAR8BAAAAAAAMMLCAAAAAEAAAAOAGcODwAN8AwA AAAAAJ4PBAAAAAEAAAAPAATwSAAAABIACvAIAAAAAUwAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAA CJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAA AAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTkQAAAA8AihOJAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAx ADAAAACLE2kAAAAAAOsuCAAAAH//xgEAppd1AAAAKwQAAAAAAAAAHwBE8T0AAAAAACfxIAAAAAAA AAADAAAAAAAAAAAAAAAAAAAAAAB3Gf////8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAADwACKwAA AAAPAO4DfQIAAAIA7wMYAAAAAQAAAA0OAAAAAAAAAAAAgAAAAAAHABQwDwAMBJQBAAAPAALwjAEA ABABCPAIAAAAAwAAAANEAAAPAAPwJAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAA AgAK8AgAAAAARAAABQAAAA8ABPByAAAAEgAK8AgAAAACRAAAIAIAAFMAC/AeAAAAfwAAAAQAgAB0 B2cOvwEAAAEA/wEAAAEAAQMCBAAAAAAQ8AgAAACtACABYBV9Aw8AEfAQAAAAAADDCwgAAAAAAAAA DQBnDg8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HIAAAASAArwCAAAAANEAAAgAgAAUwAL8B4AAAB/ AAAABACAAEwIZw6/AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAAPADIAFgFRMPDwAR8BAAAAAAAMML CAAAAAEAAAAOAGcODwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwSAAAABIACvAIAAAAAUQAAAAMAACD AAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA 8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTkQAAAA8AihOJAAAAAAC6 DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE2kAAAAAAOsuCAAAAH//xgEAoEIwAAAAKwQAAAAAAAAA HwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAAB3Gf////8SAAAADwA98Q0AAABA AULxBQAAAAEJAAAADwACKwAAAAAPAO4DFRIAAAIA7wMYAAAAAQAAAA0OAAAAAAAAAAAAgAABAAAH ABQwDwAMBCwRAAAPAALwJBEAAMABCPAIAAAAIgAAACJwAAAPAAPwvBAAAA8ABPAoAAAAAQAJ8BAA AAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAcAAABQAAAA8ABPB4AAAAEgAK8AgAAAACcAAAIAIA AGMAC/AkAAAAfwAAAAQAgADMG2cOvwEAAAEA/wEAAAEAAQMCBAAAiAMAAAAAAAAQ8AgAAAAAACAB YBXQAg8AEfAQAAAAAADDCwgAAAAAAAAADQBnDg8ADfAMAAAAAACeDwQAAAAAAAAADwAE8FgAAAAS AArwCAAAAANwAAAACgAAgwAL8DAAAACFAAIAAACHAAEAAACBAQQAAAiDAQAAAAi/ARAAEADAAQEA AAj/AQgACAABAgIAAAgAABDwCAAAACAEAAMwBgAGDwAE8FgAAAASAArwCAAAAARwAAAACgAAgwAL 8DAAAACFAAIAAACHAAEAAACBAQQAAAiDAQAAAAi/ARAAEADAAQEAAAj/AQgACAABAgIAAAgAABDw CAAAAIAEYAOQBmAGDwAE8FgAAAASAArwCAAAAAVwAAAACgAAgwAL8DAAAACFAAIAAACHAAEAAACB AQQAAAiDAQAAAAi/ARAAEADAAQEAAAj/AQgACAABAgIAAAgAABDwCAAAAOAEwAPwBsAGDwAE8FgA AAASAArwCAAAAAZwAAAACgAAgwAL8DAAAACFAAIAAACHAAEAAACBAQQAAAiDAQAAAAi/ARAAEADA AQEAAAj/AQgACAABAgIAAAgAABDwCAAAACAEIBBQEwAGDwAE8FgAAAASAArwCAAAAAdwAAAACgAA gwAL8DAAAACFAAIAAACHAAEAAACBAQQAAAiDAQAAAAi/ARAAEADAAQEAAAj/AQgACAABAgIAAAgA ABDwCAAAAIAEwA/wEmAGDwAE8FgAAAASAArwCAAAAAhwAAAACgAAgwAL8DAAAACFAAIAAACHAAEA AACBAQQAAAiDAQAAAAi/ARAAEADAAQEAAAj/AQgACAABAgIAAAgAABDwCAAAAOAEYA+QEsAGDwAE 8FgAAAASAArwCAAAAAlwAAAACgAAgwAL8DAAAACFAAIAAACHAAEAAACBAQQAAAiDAQAAAAi/ARAA EADAAQEAAAj/AQgACAABAgIAAAgAABDwCAAAAHALYA+QEhAODwAE8EwAAABCAQrwCAAAAApwAAAA CgAAYwAL8CQAAABEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAj/ARgAGAABAgIAAAgAABDwCAAAAMAG QAVABUAIDwAE8EwAAABCAQrwCAAAAAtwAAAACgAAYwAL8CQAAABEAQQAAAB/AQAAAQC/AQAAEADA AQEAAAj/ARgAGAABAgIAAAgAABDwCAAAAMAG4BDgEEAIDwAE8EwAAABCAQrwCAAAAAxwAAAACgAA YwAL8CQAAABEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAj/ARgAGAABAgIAAAgAABDwCAAAACAKQAVA BaALDwAE8EwAAABCAQrwCAAAAA1wAAAACgAAYwAL8CQAAABEAQQAAAB/AQAAAQC/AQAAEADAAQEA AAj/ARgAGAABAgIAAAgAABDwCAAAACAK4BDgEHALDwAE8F4AAABCAQrwCAAAAA5wAAAACgAAkwAL 8DYAAABEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAjLAZ9vAADQAQEAAADRAQEAAAD/ARgAGAABAgIA AAgAABDwCAAAANAF8AZgD9AFDwAE8F4AAABCAQrwCAAAAA9wAAAACgAAkwAL8DYAAABEAQQAAAB/ AQAAAQC/AQAAEADAAQEAAAjLAZ9vAADQAQEAAADRAQEAAAD/ARgAGAABAgIAAAgAABDwCAAAAAAJ 8AZgDwAJDwAE8EwAAABCAQrwCAAAABBwAAAACgAAYwAL8CQAAABEAQQAAAB/AQAAAQC/AQAAEADA AQEAAAj/ARgAGAABAgIAAAgAABDwCAAAAPAMwAZgCfAMDwAE8EwAAABCAQrwCAAAABFwAAAACgAA YwAL8CQAAABEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAj/ARgAGAABAgIAAAgAABDwCAAAAPAMIA1g D/AMDwAE8K8AAACiDArwCAAAABJwAAAACgAAowAL8DwAAACAALxeZw6FAAIAAACHAAYAAAC/AAIA AgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAABAFIAQUB6QGDwAN 8EMAAAAAAJ8PBAAAAAQAAAAAAKgPEwAAAFBvc3R1cmUgDUNvbGxlY3RvcnMAAKEPFAAAABQAAAAA AAAAAAAUAAAAAAAgAAAADwAE8K8AAACiDArwCAAAABNwAAAACgAAowAL8DwAAACAAMhwZw6FAAIA AACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAA ABAFkA+EEqQGDwAN8EMAAAAAAJ8PBAAAAAQAAAAAAKgPEwAAAFBvc3R1cmUgDVZhbGlkYXRvcnMA AKEPFAAAABQAAAAAAAAAAAAUAAAAAAAgAAAADwAE8LQAAACiDArwCAAAABRwAAAACgAAowAL8DwA AACAAEwUZw6FAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAAB AgIAAAgAABDwCAAAAKALYA8MEuENDwAN8EgAAAAAAJ8PBAAAAAQAAAAAAKgPGAAAAE5ldHdvcmsN QWNjZXNzDUF1dGhvcml0eQAAoQ8UAAAAGQAAAAAAAAAAABkAAAAAACAAAAAPAATwvAAAAKIMCvAI AAAAFXAAAAAKAACjAAvwPAAAAIAAEBZnDoUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8B AAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAAEAVQB4wP9wUPAA3wUAAAAAAAnw8EAAAABAAA AAAAqA8gAAAAUG9zdHVyZSBBdHRyaWJ1dGUgKFBBKSBwcm90b2NvbCAAAKEPFAAAACEAAAAAAAAA AAAhAAAAAAAgAAAADwAE8LgAAACiDArwCAAAABZwAAAACgAAowAL8DwAAACAAPS0Zw6FAAIAAACH AAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAABAI UAf0DvcIDwAN8EwAAAAAAJ8PBAAAAAQAAAAAAKgPHAAAAFBvc3R1cmUgQnJva2VyIChQQikgcHJv dG9jb2wAAKEPFAAAAB0AAAAAAAAAAAAdAAAAAAAgAAAADwAE8KoAAACiDArwCAAAABdwAAAACgAA owAL8DwAAACAAPxRZw6FAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/ AQAACAABAgIAAAgAABDwCAAAAAAD0AJ/BvoDDwAN8D4AAAAAAJ8PBAAAAAQAAAAAAKgPCgAAAE5F QSBDbGllbnQAAKEPGAAAAAsAAAAAAAAAAAALAAAAAQAiAAEAAAAUAA8ABPCqAAAAogwK8AgAAAAY cAAAAAoAAKMAC/A8AAAAgAAcgWcOhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAA wAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAAAAA8APpRP6Aw8ADfA+AAAAAACfDwQAAAAEAAAAAACo DwoAAABORUEgU2VydmVyAAChDxgAAAALAAAAAAAAAAAACwAAAAEAIgABAAAAFAAPAATwWAAAABIA CvAIAAAAGXAAAAAKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8BEAAQAMABAQAA CP8BCAAIAAECAgAACAAAEPAIAAAAoAtgCSANEA4PAATwtgAAAKIMCvAIAAAAGnAAAAAKAACjAAvw PAAAAIAASJ5nDoUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAI AAECAgAACAAAEPAIAAAA0AuQCTQNEQ4PAA3wSgAAAAAAnw8EAAAABAAAAAAAqA8aAAAATmV0d29y aw1FbmZvcmNlbWVudA1EZXZpY2UAAKEPFAAAABsAAAAAAAAAAAAbAAAAAAAgAAAADwAE8F4AAABC AQrwCAAAABtwAAAACgAAkwAL8DYAAABEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAjLAZ9vAADQAQEA AADRAQEAAAD/ARgAGAABAgIAAAgAABDwCAAAAHAL8AZgD3ALDwAE8LwAAACiDArwCAAAABxwAAAA CgAAowAL8DwAAACAAEyiZw6FAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEA AAj/AQAACAABAgIAAAgAABDwCAAAAIAKwAZkD2cLDwAN8FAAAAAAAJ8PBAAAAAQAAAAAAKgPIAAA AFBvc3R1cmUgVHJhbnNwb3J0IChQVCkgcHJvdG9jb2xzAAChDxQAAAAhAAAAAAAAAAAAIQAAAAAA IAAAAA8ABPBYAAAAEgAK8AgAAAAdcAAAAAoAAIMAC/AwAAAAhQACAAAAhwABAAAAgQEEAAAIgwEA AAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAQ8AgAAABwC8AD8AbgDQ8ABPC0AAAAogwK8AgA AAAecAAAAAoAAKMAC/A8AAAAgAAgg2cOhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEAAAAIvwEA ABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAABwC/AD/AaxDQ8ADfBIAAAAAACfDwQAAAAEAAAA AACoDxgAAABOZXR3b3JrDUFjY2Vzcw1SZXF1ZXN0b3IAAKEPFAAAABkAAAAAAAAAAAAZAAAAAAAg AAAADwAE8FgAAAASAArwCAAAAB9wAAAACgAAgwAL8DAAAACFAAIAAACHAAEAAACBAQQAAAiDAQAA AAi/ARAAEADAAQEAAAj/AQgACAABAgIAAAgAABDwCAAAAEAIwAPwBoAKDwAE8LEAAACiDArwCAAA ACBwAAAACgAAowAL8DwAAACAAIhaZw6FAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAA EADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAAEAIUAS0BoEKDwAN8EUAAAAAAJ8PBAAAAAQAAAAA AKgPFQAAAFBvc3R1cmUNQnJva2VyDUNsaWVudAAAoQ8UAAAAFgAAAAAAAAAAABYAAAAAACAAAAAP AATwWAAAABIACvAIAAAAIXAAAAAKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8B EAAQAMABAQAACP8BCAAIAAECAgAACAAAEPAIAAAAQAhgD5ASgAoPAATwsQAAAKIMCvAIAAAAInAA AAAKAACjAAvwPAAAAIAAqD1nDoUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMAB AQAACP8BAAAIAAECAgAACAAAEPAIAAAAQAjADyQSgQoPAA3wRQAAAAAAnw8EAAAABAAAAAAAqA8V AAAAUG9zdHVyZQ1Ccm9rZXINU2VydmVyAAChDxQAAAAWAAAAAAAAAAAAFgAAAAAAIAAAAA8ABPBI AAAAEgAK8AgAAAABcAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA /wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwA AA8AiBORAAAADwCKE4kAAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTaQAAAAAA6y4IAAAA FkPGAVADVR0AAAArBAAAAAAAAAAfAETxPQAAAAAAJ/EgAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAA AHcZ/////xIAAAAPAD3xDQAAAEABQvEFAAAAAQkAAAAPAAIrAAAAAA8A7gNPEAAAAgDvAxgAAAAB AAAADQ4AAAAAAAAAAACAAQEAAAcAFDAPAAwEZg8AAA8AAvBeDwAAoAII8AgAAAAeAAAAIqgAAA8A A/D2DgAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAACAArwCAAAAACoAAAFAAAADwAE 8HgAAAASAArwCAAAAAKoAAAgAgAAYwAL8CQAAAB/AAAABACAAHxFZw6/AQAAAQD/AQAAAQABAwIE AACIAwAAAAAAABDwCAAAAAAAIAFgFdACDwAR8BAAAAAAAMMLCAAAAAAAAAANAGcODwAN8AwAAAAA AJ4PBAAAAAAAAAAPAATwWAAAABIACvAIAAAAA6gAAAAKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEB BAAACIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACAAAEPAIAAAAIAQAAzAGAAYPAATwWAAA ABIACvAIAAAABKgAAAAKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8BEAAQAMAB AQAACP8BCAAIAAECAgAACAAAEPAIAAAAgARgA5AGYAYPAATwWAAAABIACvAIAAAABagAAAAKAACD AAvwMAAAAIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACAAA EPAIAAAA4ATAA/AGwAYPAATwWAAAABIACvAIAAAABqgAAAAKAACDAAvwMAAAAIUAAgAAAIcAAQAA AIEBBAAACIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACAAAEPAIAAAAIAQgEFATAAYPAATw WAAAABIACvAIAAAAB6gAAAAKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8BEAAQ AMABAQAACP8BCAAIAAECAgAACAAAEPAIAAAAgATAD/ASYAYPAATwWAAAABIACvAIAAAACKgAAAAK AACDAAvwMAAAAIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAA CAAAEPAIAAAA4ARgD5ASwAYPAATwWAAAABIACvAIAAAACagAAAAKAACDAAvwMAAAAIUAAgAAAIcA AQAAAIEBBAAACIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACAAAEPAIAAAAcAtgD5ASEA4P AATwTAAAAEIBCvAIAAAACqgAAAAKAABjAAvwJAAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACP8B GAAYAAECAgAACAAAEPAIAAAAwAZABUAFQAgPAATwTAAAAEIBCvAIAAAAC6gAAAAKAABjAAvwJAAA AEQBBAAAAH8BAAABAL8BAAAQAMABAQAACP8BGAAYAAECAgAACAAAEPAIAAAAwAbgEOAQQAgPAATw TAAAAEIBCvAIAAAADKgAAAAKAABjAAvwJAAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACP8BGAAY AAECAgAACAAAEPAIAAAAIApABUAFoAsPAATwTAAAAEIBCvAIAAAADagAAAAKAABjAAvwJAAAAEQB BAAAAH8BAAABAL8BAAAQAMABAQAACP8BGAAYAAECAgAACAAAEPAIAAAAIArgEOAQcAsPAATwXgAA AEIBCvAIAAAADqgAAAAKAACTAAvwNgAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACMsBn28AANAB AQAAANEBAQAAAP8BGAAYAAECAgAACAAAEPAIAAAA0AXwBmAP0AUPAATwXgAAAEIBCvAIAAAAD6gA AAAKAACTAAvwNgAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACMsBn28AANABAQAAANEBAQAAAP8B GAAYAAECAgAACAAAEPAIAAAAAAnwBmAPAAkPAATwrwAAAKIMCvAIAAAAEqgAAAAKAACjAAvwPAAA AIAAMH1nDoUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAEC AgAACAAAEPAIAAAAEAUgBBQHpAYPAA3wQwAAAAAAnw8EAAAABAAAAAAAqA8TAAAAUG9zdHVyZSAN Q29sbGVjdG9ycwAAoQ8UAAAAFAAAAAAAAAAAABQAAAAAACAAAAAPAATwrwAAAKIMCvAIAAAAE6gA AAAKAACjAAvwPAAAAIAATJNnDoUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMAB AQAACP8BAAAIAAECAgAACAAAEPAIAAAAEAWQD4QSpAYPAA3wQwAAAAAAnw8EAAAABAAAAAAAqA8T AAAAUG9zdHVyZSANVmFsaWRhdG9ycwAAoQ8UAAAAFAAAAAAAAAAAABQAAAAAACAAAAAPAATwtAAA AKIMCvAIAAAAFKgAAAAKAACjAAvwPAAAAIAAQJhnDoUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMB AAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAAoAtgDzwS4Q0PAA3wSAAAAAAAnw8E AAAABAAAAAAAqA8YAAAAUG9zdHVyZQ1UcmFuc3BvcnQNU2VydmVyAAChDxQAAAAZAAAAAAAAAAAA GQAAAAAAIAAAAA8ABPC8AAAAogwK8AgAAAAVqAAAAAoAAKMAC/A8AAAAgACcmWcOhQACAAAAhwAG AAAAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAAAQBSAH XA/3BQ8ADfBQAAAAAACfDwQAAAAEAAAAAACoDyAAAABQb3N0dXJlIEF0dHJpYnV0ZSAoUEEpIHBy b3RvY29sIAAAoQ8UAAAAIQAAAAAAAAAAACEAAAAAACAAAAAPAATwuAAAAKIMCvAIAAAAFqgAAAAK AACjAAvwPAAAAIAAlNRnDoUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAA CP8BAAAIAAECAgAACAAAEPAIAAAAEAgsB9AO9wgPAA3wTAAAAAAAnw8EAAAABAAAAAAAqA8cAAAA UG9zdHVyZSBCcm9rZXIgKFBCKSBwcm90b2NvbAAAoQ8UAAAAHQAAAAAAAAAAAB0AAAAAACAAAAAP AATwqgAAAKIMCvAIAAAAF6gAAAAKAACjAAvwPAAAAIAA/NxnDoUAAgAAAIcABgAAAL8AAgACAIEB BAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAAAAPQAn8G+gMPAA3wPgAA AAAAnw8EAAAABAAAAAAAqA8KAAAATkVBIENsaWVudAAAoQ8YAAAACwAAAAAAAAAAAAsAAAABACIA AQAAABQADwAE8KoAAACiDArwCAAAABioAAAACgAAowAL8DwAAACAAFRMZw6FAAIAAACHAAYAAAC/ AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAAAADwA+lE/oD DwAN8D4AAAAAAJ8PBAAAAAQAAAAAAKgPCgAAAE5FQSBTZXJ2ZXIAAKEPGAAAAAsAAAAAAAAAAAAL AAAAAQAiAAEAAAAUAA8ABPBeAAAAQgEK8AgAAAAbqAAAAAoAAJMAC/A2AAAARAEEAAAAfwEAAAEA vwEAABAAwAEBAAAIywGfbwAA0AEBAAAA0QEBAAAA/wEYABgAAQICAAAIAAAQ8AgAAADADPAGYA/A DA8ABPC8AAAAogwK8AgAAAAcqAAAAAoAAKMAC/A8AAAAgAAAKWcOhQACAAAAhwAGAAAAvwACAAIA gQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAADQC8AGZA+3DA8ADfBQ AAAAAACfDwQAAAAEAAAAAACoDyAAAABQb3N0dXJlIFRyYW5zcG9ydCAoUFQpIHByb3RvY29scwAA oQ8UAAAAIQAAAAAAAAAAACEAAAAAACAAAAAPAATwWAAAABIACvAIAAAAHagAAAAKAACDAAvwMAAA AIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACAAAEPAIAAAA cAvAA/AG4A0PAATwtAAAAKIMCvAIAAAAHqgAAAAKAACjAAvwPAAAAIAA7CxnDoUAAgAAAIcABgAA AL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAAcAvwA8wG sQ0PAA3wSAAAAAAAnw8EAAAABAAAAAAAqA8YAAAAUG9zdHVyZQ1UcmFuc3BvcnQNQ2xpZW50AACh DxQAAAAZAAAAAAAAAAAAGQAAAAAAIAAAAA8ABPBYAAAAEgAK8AgAAAAfqAAAAAoAAIMAC/AwAAAA hQACAAAAhwABAAAAgQEEAAAIgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAQ8AgAAABA CMAD8AaACg8ABPCxAAAAogwK8AgAAAAgqAAAAAoAAKMAC/A8AAAAgAAgwGcOhQACAAAAhwAGAAAA vwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAABACFAEtAaB Cg8ADfBFAAAAAACfDwQAAAAEAAAAAACoDxUAAABQb3N0dXJlDUJyb2tlcg1DbGllbnQAAKEPFAAA ABYAAAAAAAAAAAAWAAAAAAAgAAAADwAE8FgAAAASAArwCAAAACGoAAAACgAAgwAL8DAAAACFAAIA AACHAAEAAACBAQQAAAiDAQAAAAi/ARAAEADAAQEAAAj/AQgACAABAgIAAAgAABDwCAAAAEAIYA+Q EoAKDwAE8LEAAACiDArwCAAAACKoAAAACgAAowAL8DwAAACAAMzaZw6FAAIAAACHAAYAAAC/AAIA AgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAAEAIwA8kEoEKDwAN 8EUAAAAAAJ8PBAAAAAQAAAAAAKgPFQAAAFBvc3R1cmUNQnJva2VyDVNlcnZlcgAAoQ8UAAAAFgAA AAAAAAAAABYAAAAAACAAAAAPAATwSAAAABIACvAIAAAAAagAAAAMAACDAAvwMAAAAIEBAAAACIMB BQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACA gIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTkQAAAA8AihOJAAAAAAC6DxAAAABfAF8AXwBQAFAA VAAxADAAAACLE2kAAAAAAOsuCAAAABZDxgFQA1UdAAAAKwQAAAAAAAAAHwBE8T0AAAAAACfxIAAA AAAAAAADAAAAAAAAAAAAAAAAAAAAAAB3Gf////8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAADwAC KwAAAAAPAO4DfQIAAAIA7wMYAAAAAQAAAA0OAAAAAAAAAAAAgAAAAAAHABQwDwAMBJQBAAAPAALw jAEAANADCPAIAAAAAwAAAAf0AAAPAAPwJAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAA AAAAAgAK8AgAAAAA9AAABQAAAA8ABPByAAAAEgAK8AgAAAAC9AAAIAIAAFMAC/AeAAAAfwAAAAQA gAD0y2cOvwEAAAEA/wEAAAEAAQMCBAAAAAAQ8AgAAACtACABYBV9Aw8AEfAQAAAAAADDCwgAAAAA AAAADQBnDg8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HIAAAASAArwCAAAAAf0AAAgAgAAUwAL8B4A AAB/AAAABACAAJzMZw6/AQAAAQD/AQAAAQABAwMEAAAAABDwCAAAAPADIAFgFRMPDwAR8BAAAAAA AMMLCAAAAAEAAAAOAGcODwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwSAAAABIACvAIAAAAAfQAAAAM AACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQAB ABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTkQAAAA8AihOJAAAA AAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE2kAAAAAAOsuCAAAAIQCxwGgYt7YAAAAKwQAAAAA AAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAAB3Gf////8SAAAADwA98Q0A AABAAULxBQAAAAEJAAAADwACKwAAAAAPAO4DfQIAAAIA7wMYAAAAAQAAAA0OAAAAAAAAAAAAgAAA AAAHABQwDwAMBJQBAAAPAALwjAEAAMACCPAIAAAAAwAAAAOwAAAPAAPwJAEAAA8ABPAoAAAAAQAJ 8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAsAAABQAAAA8ABPByAAAAEgAK8AgAAAACsAAA IAIAAFMAC/AeAAAAfwAAAAQAgAB4h2cOvwEAAAEA/wEAAAEAAQMCBAAAAAAQ8AgAAACtACABYBV9 Aw8AEfAQAAAAAADDCwgAAAAAAAAADQBnDg8ADfAMAAAAAACeDwQAAAAAAAAADwAE8HIAAAASAArw CAAAAAOwAAAgAgAAUwAL8B4AAAB/AAAABACAADyIZw6/AQAAAQD/AQAAAQABAwMEAAAAABDwCAAA APADIAFgFdAODwAR8BAAAAAAAMMLCAAAAAEAAAAOAGcODwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATw SAAAABIACvAIAAAAAbAAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgAS AP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnM AAAPAIgTkQAAAA8AihOJAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLE2kAAAAAAOsuCAAA AAECxwEAqLoXAAAAKwQAAAAAAAAAHwBE8T0AAAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAAAAAA AAB3Gf////8SAAAADwA98Q0AAABAAULxBQAAAAEJAAAADwACKwAAAAAPAO4DiQIAAAIA7wMYAAAA AQAAAA0OAAAAAAAAAAAAgAAAAAAHABQwDwAMBKABAAAPAALwmAEAANACCPAIAAAAAwAAAAO0AAAP AAPwMAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAtAAABQAAAA8A BPB4AAAAEgAK8AgAAAACtAAAIAIAAGMAC/AkAAAAfwAAAAQAgAAUp2cOvwEAAAEA/wEAAAEAAQMC BAAAiAMAAAAAAAAQ8AgAAACtACABYBV9Aw8AEfAQAAAAAADDCwgAAAAAAAAADQBnDg8ADfAMAAAA AACeDwQAAAAAAAAADwAE8HgAAAASAArwCAAAAAO0AAAgAgAAYwAL8CQAAAB/AAAABACAAOynZw6/ AQAAAQD/AQAAAQABAwMEAACIAwAAAAAAABDwCAAAAPADIAFgFdAODwAR8BAAAAAAAMMLCAAAAAEA AAAOAGcODwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATwSAAAABIACvAIAAAAAbQAAAAMAACDAAvwMAAA AIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BEgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA ////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZAJnMAAAPAIgTkQAAAA8AihOJAAAAAAC6DxAAAABf AF8AXwBQAFAAVAAxADAAAACLE2kAAAAAAOsuCAAAAAECxwEAqLoXAAAAKwQAAAAAAAAAHwBE8T0A AAAAACfxIAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAAB3Gf////8SAAAADwA98Q0AAABAAULxBQAA AAEJAAAADwACKwAAAAAPAO4DJSMAAAIA7wMYAAAAAQAAAA0OAAAAAAAAAAAAgAIBAAAHABQwDwAM BMMSAAAPAALwuxIAADADCPAIAAAAIQAAACXMAAAPAAPwUxIAAA8ABPAoAAAAAQAJ8BAAAAAAAAAA AAAAAAAAAAAAAAAAAgAK8AgAAAAAzAAABQAAAA8ABPCtAAAAQggK8AgAAAAjzAAAAAoAAKMAC/A8 AAAAfwAAAAQAgADYYmcOhQACAAAAhwABAAAAgQHAwMAAgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgA AQICAAAIEwAi8QYAAAC/AQAAYAAAABDwCAAAANAF4BOQFYAHDwAN8DMAAAAAAJ8PBAAAAAQAAAAA AKgPAwAAAExvZwAAoQ8UAAAABAAAAAAAAAgAAAEABAAAAAAAAAAPAATweAAAABIACvAIAAAAAswA ACACAABjAAvwJAAAAH8AAAAEAIAA4GVnDr8BAAABAP8BAAABAAEDAgQAAIgDAAAAAAAAEPAIAAAA AAAgAWAV0AIPABHwEAAAAAAAwwsIAAAAAAAAAA0AZw4PAA3wDAAAAAAAng8EAAAAAAAAAA8ABPBY AAAAEgAK8AgAAAAFzAAAAAoAAIMAC/AwAAAAhQACAAAAhwABAAAAgQEEAAAIgwEAAAAIvwEQABAA wAEBAAAI/wEIAAgAAQICAAAIAAAQ8AgAAADQBcAD8AawBw8ABPBYAAAAEgAK8AgAAAAIzAAAAAoA AIMAC/AwAAAAhQACAAAAhwABAAAAgQEEAAAIgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAI AAAQ8AgAAADQBWAPkBKwBw8ABPBYAAAAEgAK8AgAAAAJzAAAAAoAAIMAC/AwAAAAhQACAAAAhwAB AAAAgQEEAAAIgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAQ8AgAAABgDGAPkBIADw8A BPBMAAAAQgEK8AgAAAAKzAAAAAoAAGMAC/AkAAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI/wEY ABgAAQICAAAIAAAQ8AgAAACwB0AFQAUwCQ8ABPBMAAAAQgEK8AgAAAALzAAAAAoAAGMAC/AkAAAA RAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI/wEYABgAAQICAAAIAAAQ8AgAAACwB+AQ4BAwCQ8ABPBM AAAAQgEK8AgAAAAMzAAAAAoAAGMAC/AkAAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI/wEYABgA AQICAAAIAAAQ8AgAAAAQC0AFQAWQDA8ABPBMAAAAQgEK8AgAAAANzAAAAAoAAGMAC/AkAAAARAEE AAAAfwEAAAEAvwEAABAAwAEBAAAI/wEYABgAAQICAAAIAAAQ8AgAAAAQC+AQ4BBgDA8ABPCwAAAA ogwK8AgAAAAQzAAAAAoAAKMAC/A8AAAAgADcaGcOhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEA AAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAAAABiAEDAeUBw8ADfBEAAAAAACfDwQA AAAEAAAAAACoDxQAAABJbnZlbnRvcnkgDUNvbGxlY3RvcgAAoQ8UAAAAFQAAAAAAAAAAABUAAAAA ACAAAAAPAATw0gAAAKIMCvAIAAAAEcwAAAAKAACjAAvwPAAAAIAAPIlnDoUAAgAAAIcABgAAAL8A AgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAAAAaQD3wSlAcP AA3wZgAAAAAAnw8EAAAABAAAAAAAqA8UAAAASW52ZW50b3J5IA1WYWxpZGF0b3IAAKEPFAAAABUA AAAAAAAAAAAVAAAAAAAgAAAAAACqDxoAAAALAAAAAAAAAAkAAAABAAAAAQABAAAAAAAAAA8ABPC0 AAAAogwK8AgAAAASzAAAAAoAAKMAC/A8AAAAgAC8P2UOhQACAAAAhwAGAAAAvwACAAIAgQEEAAAI gwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAACQDGAPPBLRDg8ADfBIAAAAAACf DwQAAAAEAAAAAACoDxgAAABQb3N0dXJlDVRyYW5zcG9ydA1TZXJ2ZXIAAKEPFAAAABkAAAAAAAAA AAAZAAAAAAAgAAAADwAD8K4BAAAPAATwbAAAAAEACfAQAAAA8AYAABAFAABgDwAA9wUAAAIACvAI AAAAIcwAAAECAAAAABDwCAAAAAAG8AZgD+cGDwAR8CwAAAAPABQQJAAAAAEA8Q8cAAAAAAAABwBE AAAAAAAAAAAAAAUAAQABAAAAAAAUMA8ABPBmAAAAQgEK8AgAAAAOzAAAAgoAAJMAC/A2AAAARAEE AAAAfwEAAAEAvwEAABAAwAEBAAAIywGfbwAA0AEBAAAA0QEBAAAA/wEYABgAAQICAAAIAAAP8BAA AADwBgAA0AUAAGAPAADQBQAADwAE8MQAAACiDArwCAAAABPMAAACCgAAowAL8DwAAACAAOhIZQ6F AAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAAA/w EAAAACAHAAAQBQAAXA8AAPcFAAAPAA3wUAAAAAAAnw8EAAAABAAAAAAAqA8gAAAAUG9zdHVyZSBB dHRyaWJ1dGUgKFBBKSBwcm90b2NvbCAAAKEPFAAAACEAAAAAAAAAAAAhAAAAAAAgAAAADwAD8KoB AAAPAATwbAAAAAEACfAQAAAA8AYAABAIAABgDwAAAAkAAAIACvAIAAAAIMwAAAECAAAAABDwCAAA AGAJ8AZgD1AKDwAR8CwAAAAPABQQJAAAAAEA8Q8cAAAAAAAABwBEAAAAAAAAAAAAAAQAAQABAAAA AAAUMA8ABPBmAAAAQgEK8AgAAAAPzAAAAgoAAJMAC/A2AAAARAEEAAAAfwEAAAEAvwEAABAAwAEB AAAIywGfbwAA0AEBAAAA0QEBAAAA/wEYABgAAQICAAAIAAAP8BAAAADwBgAAAAkAAGAPAAAACQAA DwAE8MAAAACiDArwCAAAABTMAAACCgAAowAL8DwAAACAAIxOZQ6FAAIAAACHAAYAAAC/AAIAAgCB AQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAAA/wEAAAACwHAAAQCAAA0A4AAPcI AAAPAA3wTAAAAAAAnw8EAAAABAAAAAAAqA8cAAAAUG9zdHVyZSBCcm9rZXIgKFBCKSBwcm90b2Nv bAAAoQ8UAAAAHQAAAAAAAAAAAB0AAAAAACAAAAAPAATwqgAAAKIMCvAIAAAAFcwAAAAKAACjAAvw PAAAAIAAQFJlDoUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAI AAECAgAACAAAEPAIAAAAsARxAyAHqgUPAA3wPgAAAAAAnw8EAAAABAAAAAAAqA8KAAAATkVBIENs aWVudAAAoQ8YAAAACwAAAAAAAAAAAAsAAAABACIAAQAAABQADwAE8KoAAACiDArwCAAAABbMAAAA CgAAowAL8DwAAACAAEBWZQ6FAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEA AAj/AQAACAABAgIAAAgAABDwCAAAALAEwA+lE6oFDwAN8D4AAAAAAJ8PBAAAAAQAAAAAAKgPCgAA AE5FQSBTZXJ2ZXIAAKEPGAAAAAsAAAAAAAAAAAALAAAAAQAiAAEAAAAUAA8AA/CuAQAADwAE8GwA AAABAAnwEAAAAMAGAADQCwAAZA8AAMAMAAACAArwCAAAAB/MAAABAgAAAAAQ8AgAAADADMAGZA+w DQ8AEfAsAAAADwAUECQAAAABAPEPHAAAAAAAAAcARAAAAAAAAAAAAAADAAEAAQAAAAAAFDAPAATw ZgAAAEIBCvAIAAAAF8wAAAIKAACTAAvwNgAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACMsBn28A ANABAQAAANEBAQAAAP8BGAAYAAECAgAACAAAD/AQAAAA8AYAAMAMAABgDwAAwAwAAA8ABPDEAAAA ogwK8AgAAAAYzAAAAgoAAKMAC/A8AAAAgADgWWUOhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEA AAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAP8BAAAADABgAA0AsAAGQPAAC3DAAADwAN8FAA AAAAAJ8PBAAAAAQAAAAAAKgPIAAAAFBvc3R1cmUgVHJhbnNwb3J0IChQVCkgcHJvdG9jb2xzAACh DxQAAAAhAAAAAAAAAAAAIQAAAAAAIAAAAA8ABPBYAAAAEgAK8AgAAAAZzAAAAAoAAIMAC/AwAAAA hQACAAAAhwABAAAAgQEEAAAIgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAQ8AgAAABg DMAD8AbQDg8ABPC0AAAAogwK8AgAAAAazAAAAAoAAKMAC/A8AAAAgACwXmUOhQACAAAAhwAGAAAA vwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAABgDPADzAah Dg8ADfBIAAAAAACfDwQAAAAEAAAAAACoDxgAAABQb3N0dXJlDVRyYW5zcG9ydA1DbGllbnQAAKEP FAAAABkAAAAAAAAAAAAZAAAAAAAgAAAADwAE8FgAAAASAArwCAAAABvMAAAACgAAgwAL8DAAAACF AAIAAACHAAEAAACBAQQAAAiDAQAAAAi/ARAAEADAAQEAAAj/AQgACAABAgIAAAgAABDwCAAAADAJ wAPwBnALDwAE8LEAAACiDArwCAAAABzMAAAACgAAowAL8DwAAACAAChkZQ6FAAIAAACHAAYAAAC/ AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAADAJUAS0BnEL DwAN8EUAAAAAAJ8PBAAAAAQAAAAAAKgPFQAAAFBvc3R1cmUNQnJva2VyDUNsaWVudAAAoQ8UAAAA FgAAAAAAAAAAABYAAAAAACAAAAAPAATwWAAAABIACvAIAAAAHcwAAAAKAACDAAvwMAAAAIUAAgAA AIcAAQAAAIEBBAAACIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACAAAEPAIAAAAMAlgD5AS cAsPAATwsQAAAKIMCvAIAAAAHswAAAAKAACjAAvwPAAAAIAA3GdlDoUAAgAAAIcABgAAAL8AAgAC AIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAAMAnADyQScQsPAA3w RQAAAAAAnw8EAAAABAAAAAAAqA8VAAAAUG9zdHVyZQ1Ccm9rZXINU2VydmVyAAChDxQAAAAWAAAA AAAAAAAAFgAAAAAAIAAAAA8ABPCvAAAAEgAK8AgAAAAizAAAAAoAAKMAC/A8AAAAfwAAAAQAgADs a2UOhQACAAAAhwABAAAAgQH/W1sAgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAQ8AgA AACw/gAAsAHQ/w8ADfBDAAAAAACfDwQAAAAEAAAAAACoDxEAAABJbnZlbnRvcnkLTWVzc2FnZQAA oQ8WAAAAEgAAAAAAAAgAAAEAEgAAAAAAAgAMAA8ABPBMAAAAQgEK8AgAAAAkzAAAAAoAAGMAC/Ak AAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI/wEYABgAAQICAAAIAAAQ8AgAAADABpAS4BPABg8A BPBNAQAAogwK8AgAAAAlzAAAAAoAAKMAC/A8AAAAgACoemUOhQACAAAAhwAGAAAAvwACAAIAgQEE AAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAACgApAD5BI0BA8AEfAsAAAA DwAUECQAAAABAPEPHAAAAAAAAAcARAAAAAAAAAAAAAACAAEAAQAAAAAAFDAPAA3wrQAAAAAAnw8E AAAABAAAAAAAqA9dAAAAMC4JRW5kcG9pbnQgQXNzZXNzbWVudCBUcmlnZ2VyZWQgQnkgTmV0d29y ayBDb25uZWN0aW9uDVNvZnR3YXJlIEludmVudG9yeSBSZXBvcnRlZCBhbmQgTG9nZ2VkAAChDx4A AAA3AAAAAAAAAAAAJwAAAAAAAQAAAAEAXgAAAAAAAAAAAKYPDgAAAPgAAADYAPgBGAM4BFgFDwAE 8EgAAAASAArwCAAAAAHMAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIA EgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZ zAAADwCIEwoQAAAPAIoTAhAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixPiDwAAAADrLggA AAAWQ8YBUANVHQAAACsEAAAAL/Q4dx8ARPF+DwAAAAAn8SAAAAAAAAAAAwAAAAAAAAAAAAAAAAAA AAB/ZQ7/////EgAAAA8APfENAAAAQAFC8QUAAAABCQAAAB8ARPE5DwAAAAAn8SAAAAAAAAAAAAAA AAEAAAAAAAAAAAAAAACCEwD/////GAAAAA8APfENAAAAQAFC8QUAAAABBAAAAAAAQfEUAAAAAQAA AAEAAAAAAAAAAAAAAAMAAAA/ACXxLAAAAAAAKPEQAAAAAQAAAAkAAAAAAAAAAAAAAA8APPEMAAAA AAABKwQAAAABAAAATwAl8SwAAAAAACjxEAAAAAEAAAAKAAAAAAAAAAAAAAAPADzxDAAAAAAAASsE AAAAAQAAAB8ARPE0AgAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8A PfEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAP////8fAETx3AEAAAAAJ/EgAAAAAAAA AAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAA AAAAAAAAAAAAAAAAHwBE8YQBAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAB AAAADwA98TQAAABAAULxBQAAAAEBAAAAkABC8QUAAAABAQAAAKAAQvEFAAAAAQAAAACwAELxBQAA AAEBAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETx+AAAAAAAJ/EgAAAAAAAA AAAAAAADAAAAAwAAAAAAAAAAAAAAAQAAABkAAAAPAD3xAAAAAA8AMfGgAAAAAAA68QgAAAABAAAA AQAAABAAQvERAAAAA3YAaQBzAGkAYgBsAGUAAAAPACrxbwAAAAAAM/EQAAAABAAAAAAAAAAAAAAA AAAAAB8APvErAAAAAABC8SMAAAADcwB0AHkAbABlAC4AdgBpAHMAaQBiAGkAbABpAHQAeQAAAA8A PPEcAAAAAAD7KhQAAAACAAAAAQAAACXMAAAAAAAANwAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAA AAAAAAAAAAAAHwBE8TQCAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAA DwA98QAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAA/////x8ARPHcAQAAAAAn8SAAAAAA AAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfEAAAAAHwAl8RgAAAAAACjxEAAAAAAA AAAAAAAAAAAAAAAAAAAfAETxhAEAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAA AAEAAAAPAD3xNAAAAEABQvEFAAAAAQEAAACQAELxBQAAAAEBAAAAoABC8QUAAAABAAAAALAAQvEF AAAAAQEAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPH4AAAAAAAn8SAAAAAA AAAAAAAAAAMAAAADAAAAAAAAAAAAAAABAAAAGQAAAA8APfEAAAAADwAx8aAAAAAAADrxCAAAAAEA AAABAAAAEABC8REAAAADdgBpAHMAaQBiAGwAZQAAAA8AKvFvAAAAAAAz8RAAAAAEAAAAAAAAAAAA AAAAAAAAHwA+8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2AGkAcwBpAGIAaQBsAGkAdAB5AAAA DwA88RwAAAAAAPsqFAAAAAAAAAABAAAAH8wAAP//////////HwAl8RgAAAAAACjxEAAAAAAAAAAA AAAAAAAAAAAAAAAfAETxNAIAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEA AAAPAD3xAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAD/////HwBE8dwBAAAAACfxIAAA AAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98QAAAAAfACXxGAAAAAAAKPEQAAAA AAAAAAAAAAAAAAAAAAAAAB8ARPGEAQAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAA AAAAAQAAAA8APfE0AAAAQAFC8QUAAAABAQAAAJAAQvEFAAAAAQEAAACgAELxBQAAAAEAAAAAsABC 8QUAAAABAQAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8fgAAAAAACfxIAAA AAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAAEAAAAZAAAADwA98QAAAAAPADHxoAAAAAAAOvEIAAAA AQAAAAEAAAAQAELxEQAAAAN2AGkAcwBpAGIAbABlAAAADwAq8W8AAAAAADPxEAAAAAQAAAAAAAAA AAAAAAAAAAAfAD7xKwAAAAAAQvEjAAAAA3MAdAB5AGwAZQAuAHYAaQBzAGkAYgBpAGwAaQB0AHkA AAAPADzxHAAAAAAA+yoUAAAAAAAAAAEAAAAgzAAA//////////8fACXxGAAAAAAAKPEQAAAAAAAA AAAAAAAAAAAAAAAAAB8ARPE0AgAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAA AQAAAA8APfEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAP////8fAETx3AEAAAAAJ/Eg AAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xAAAAAB8AJfEYAAAAAAAo8RAA AAAAAAAAAAAAAAAAAAAAAAAAHwBE8YQBAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAA AAAAAAABAAAADwA98TQAAABAAULxBQAAAAEBAAAAkABC8QUAAAABAQAAAKAAQvEFAAAAAQAAAACw AELxBQAAAAEBAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETx+AAAAAAAJ/Eg AAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAAAQAAABkAAAAPAD3xAAAAAA8AMfGgAAAAAAA68QgA AAABAAAAAQAAABAAQvERAAAAA3YAaQBzAGkAYgBsAGUAAAAPACrxbwAAAAAAM/EQAAAABAAAAAAA AAAAAAAAAAAAAB8APvErAAAAAABC8SMAAAADcwB0AHkAbABlAC4AdgBpAHMAaQBiAGkAbABpAHQA eQAAAA8APPEcAAAAAAD7KhQAAAAAAAAAAQAAACHMAAD//////////x8AJfEYAAAAAAAo8RAAAAAA AAAAAAAAAAAAAAAAAAAAHwBE8TQCAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAA AAABAAAADwA98QAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAA/////x8ARPHcAQAAAAAn 8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfEAAAAAHwAl8RgAAAAAACjx EAAAAAAAAAAAAAAAAAAAAAAAAAAfAETxhAEAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAA AAAAAAAAAAEAAAAPAD3xNAAAAEABQvEFAAAAAQEAAACQAELxBQAAAAEBAAAAoABC8QUAAAABAAAA ALAAQvEFAAAAAQEAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPH4AAAAAAAn 8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAABAAAAGQAAAA8APfEAAAAADwAx8aAAAAAAADrx CAAAAAEAAAABAAAAEABC8REAAAADdgBpAHMAaQBiAGwAZQAAAA8AKvFvAAAAAAAz8RAAAAAEAAAA AAAAAAAAAAAAAAAAHwA+8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2AGkAcwBpAGIAaQBsAGkA dAB5AAAADwA88RwAAAAAAPsqFAAAAAIAAAABAAAAJcwAADcAAABeAAAAHwAl8RgAAAAAACjxEAAA AAAAAAAAAAAAAAAAAAAAAAAfAETxRAMAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAA AAAAAAEAAAAPAD3xAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAD/////HwBE8ewCAAAA ACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98QAAAAAfACXxGAAAAAAA KPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPGUAgAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAA AAAAAAAAAAAAAQAAAA8APfFBAAAAQAFC8QUAAAABAQAAAJAAQvEFAAAAAQAAAACgAELxBQAAAAEA AAAAsABC8QUAAAABBAAAADABQvEFAAAAAQAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAA AAAAAAAAKfEIAAAAAwAAAAAAAD8AACnxCAAAAAQAAAAAAAA/HwBE8dsBAAAAACfxIAAAAAAAAAAA AAAAAwAAAAMAAAAAAAAAAAAAALgLAAAZAAAADwA98QAAAAAPAC7xowEAAAAAN/EgAAAA2AAAAAAA yEIAAMhCAAAAAAAAAAAAAMhCAADIQgIAAAAQAELxrwAAAANNACAAMAAuADEAOQA0ADEAIAAwAC4A NAA0ADYANQAyACAATAAgADAALgAxADkANAAxACAAMAAuADgAMwAzADMAMwAgAEwAIAAwAC4ANwAw ADYANwA3ACAAMAAuADgAMwAzADEAIABMACAAMAAuADcAMAA5ADIAIAAwAC4ANAA0ADQAMgAxACAA TAAgADAALgA4ADgAMgA0ADcAIAAwAC4ANAA0ADIAMQAzACAAAAAPACrxvAAAAAAAM/EQAAAABAAA AAAAAAAAAAAAAAAAAB8APvEqAAAAAABC8Q0AAAADcABwAHQAXwB4AAAAAABC8Q0AAAADcABwAHQA XwB5AAAADwA98UYAAAAwAELxAgAAAAAAoABC8Q0AAAADQQBBAEEAQQBBAAAAcABC8QUAAAACAAAA AIAAQvEFAAAAAoMtsD6QAELxBQAAAALnykM+DwA88RwAAAAAAPsqFAAAAAAAAAABAAAAIswAAP// ////////DwACKzgAAAAPAAgrMAAAAAAAAysQAAAAAQAAAAAAAAAizAAAAQABMAEACSsQAAAAAwAA AAEAAAABAAAAAAAAAA8A7gMOKwAAAgDvAxgAAAABAAAADQ4AAAAAAAAAAACABAEAAAcAFDAPAAwE 9RIAAA8AAvDtEgAAcAMI8AgAAAAgAAAAJNwAAA8AA/CFEgAADwAE8CgAAAABAAnwEAAAAAAAAAAA AAAAAAAAAAAAAAACAArwCAAAAADcAAAFAAAADwAE8HgAAAASAArwCAAAAAPcAAAgAgAAYwAL8CQA AAB/AAAABACAAGgzZQ6/AQAAAQD/AQAAAQABAwIEAACIAwAAAAAAABDwCAAAAAAAIAFgFdACDwAR 8BAAAAAAAMMLCAAAAAAAAAANAGUODwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwWAAAABIACvAIAAAA BNwAAAAKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8BEAAQAMABAQAACP8BCAAI AAECAgAACAAAEPAIAAAA0AXAA/AGsAcPAATwWAAAABIACvAIAAAABdwAAAAKAACDAAvwMAAAAIUA AgAAAIcAAQAAAIEBBAAACIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACAAAEPAIAAAA0AVg D5ASsAcPAATwWAAAABIACvAIAAAABtwAAAAKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEBBAAACIMB AAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACAAAEPAIAAAAYAxgD5ASAA8PAATwTAAAAEIBCvAI AAAAB9wAAAAKAABjAAvwJAAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACP8BGAAYAAECAgAACAAA EPAIAAAAsAdABUAFMAkPAATwTAAAAEIBCvAIAAAACNwAAAAKAABjAAvwJAAAAEQBBAAAAH8BAAAB AL8BAAAQAMABAQAACP8BGAAYAAECAgAACAAAEPAIAAAAsAfgEOAQMAkPAATwTAAAAEIBCvAIAAAA CdwAAAAKAABjAAvwJAAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACP8BGAAYAAECAgAACAAAEPAI AAAAEAtABUAFkAwPAATwTAAAAEIBCvAIAAAACtwAAAAKAABjAAvwJAAAAEQBBAAAAH8BAAABAL8B AAAQAMABAQAACP8BGAAYAAECAgAACAAAEPAIAAAAEAvgEOAQYAwPAATwsgAAAKIMCvAIAAAAC9wA AAAKAACjAAvwPAAAAIAAKDdlDoUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMAB AQAACP8BAAAIAAECAgAACAAAEPAIAAAAIAYgBOgGZgcPAA3wRgAAAAAAnw8EAAAABAAAAAAAqA8U AAAAUGF0Y2ggTWdtdA1Db2xsZWN0b3IAAKEPFgAAABUAAAAAAAAAAAAVAAAAAAAiAAAADgAPAATw 1QAAAKIMCvAIAAAADNwAAAAKAACjAAvwPAAAAIAAuCxlDoUAAgAAAIcABgAAAL8AAgACAIEBBAAA CIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAAIAaQD3cSZgcPAA3waQAAAAAA nw8EAAAABAAAAAAAqA8VAAAAUGF0Y2ggTWdtdCANVmFsaWRhdG9yAAChDxYAAAAWAAAAAAAAAAAA FgAAAAAAIgAAAA4AAACqDxoAAAAMAAAAAAAAAAkAAAABAAAAAQABAAAAAAAAAA8ABPC0AAAAogwK 8AgAAAAN3AAAAAoAAKMAC/A8AAAAgADYAGUOhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEAAAAI vwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAACQDGAPPBLRDg8ADfBIAAAAAACfDwQAAAAE AAAAAACoDxgAAABQb3N0dXJlDVRyYW5zcG9ydA1TZXJ2ZXIAAKEPFAAAABkAAAAAAAAAAAAZAAAA AAAgAAAADwAD8LwBAAAPAATwegAAAAEACfAQAAAA8AYAABAFAABgDwAA9wUAAAIACvAIAAAADtwA AAECAAATAAvwBgAAAIgDAAAAAAAAEPAIAAAAAAbwBmAP5wYPABHwLAAAAA8AFBAkAAAAAQDxDxwA AAAAAAAHAEQAAAAAAAAAAAAABQABAAEAAAAAABQwDwAE8GYAAABCAQrwCAAAAA/cAAACCgAAkwAL 8DYAAABEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAjLAZ9vAADQAQEAAADRAQEAAAD/ARgAGAABAgIA AAgAAA/wEAAAAPAGAADQBQAAYA8AANAFAAAPAATwxAAAAKIMCvAIAAAAENwAAAIKAACjAAvwPAAA AIAAeAVlDoUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAEC AgAACAAAD/AQAAAAIAcAABAFAABcDwAA9wUAAA8ADfBQAAAAAACfDwQAAAAEAAAAAACoDyAAAABQ b3N0dXJlIEF0dHJpYnV0ZSAoUEEpIHByb3RvY29sIAAAoQ8UAAAAIQAAAAAAAAAAACEAAAAAACAA AAAPAAPwuAEAAA8ABPB6AAAAAQAJ8BAAAADwBgAAEAgAAGAPAAAACQAAAgAK8AgAAAAR3AAAAQIA ABMAC/AGAAAAiAMAAAAAAAAQ8AgAAABgCfAGYA9QCg8AEfAsAAAADwAUECQAAAABAPEPHAAAAAAA AAcARAAAAAAAAAAAAAAEAAEAAQAAAAAAFDAPAATwZgAAAEIBCvAIAAAAEtwAAAIKAACTAAvwNgAA AEQBBAAAAH8BAAABAL8BAAAQAMABAQAACMsBn28AANABAQAAANEBAQAAAP8BGAAYAAECAgAACAAA D/AQAAAA8AYAAAAJAABgDwAAAAkAAA8ABPDAAAAAogwK8AgAAAAT3AAAAgoAAKMAC/A8AAAAgACI IWUOhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAI AAAP8BAAAAAsBwAAEAgAANAOAAD3CAAADwAN8EwAAAAAAJ8PBAAAAAQAAAAAAKgPHAAAAFBvc3R1 cmUgQnJva2VyIChQQikgcHJvdG9jb2wAAKEPFAAAAB0AAAAAAAAAAAAdAAAAAAAgAAAADwAE8KoA AACiDArwCAAAABTcAAAACgAAowAL8DwAAACAAOQhZQ6FAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiD AQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAALAEcQMgB6oFDwAN8D4AAAAAAJ8P BAAAAAQAAAAAAKgPCgAAAE5FQSBDbGllbnQAAKEPGAAAAAsAAAAAAAAAAAALAAAAAQAiAAEAAAAU AA8ABPCqAAAAogwK8AgAAAAV3AAAAAoAAKMAC/A8AAAAgABECGUOhQACAAAAhwAGAAAAvwACAAIA gQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAACwBDAPFROqBQ8ADfA+ AAAAAACfDwQAAAAEAAAAAACoDwoAAABORUEgU2VydmVyAAChDxgAAAALAAAAAAAAAAAACwAAAAEA IgABAAAAFAAPAAPwvAEAAA8ABPB6AAAAAQAJ8BAAAADABgAA0AsAAGQPAADADAAAAgAK8AgAAAAW 3AAAAQIAABMAC/AGAAAAiAMAAAAAAAAQ8AgAAADADMAGZA+wDQ8AEfAsAAAADwAUECQAAAABAPEP HAAAAAAAAAcARAAAAAAAAAAAAAADAAEAAQAAAAAAFDAPAATwZgAAAEIBCvAIAAAAF9wAAAIKAACT AAvwNgAAAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACMsBn28AANABAQAAANEBAQAAAP8BGAAYAAEC AgAACAAAD/AQAAAA8AYAAMAMAABgDwAAwAwAAA8ABPDEAAAAogwK8AgAAAAY3AAAAgoAAKMAC/A8 AAAAgAAIvmUOhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgA AQICAAAIAAAP8BAAAADABgAA0AsAAGQPAAC3DAAADwAN8FAAAAAAAJ8PBAAAAAQAAAAAAKgPIAAA AFBvc3R1cmUgVHJhbnNwb3J0IChQVCkgcHJvdG9jb2xzAAChDxQAAAAhAAAAAAAAAAAAIQAAAAAA IAAAAA8ABPBYAAAAEgAK8AgAAAAZ3AAAAAoAAIMAC/AwAAAAhQACAAAAhwABAAAAgQEEAAAIgwEA AAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAQ8AgAAABgDMAD8AbQDg8ABPC0AAAAogwK8AgA AAAa3AAAAAoAAKMAC/A8AAAAgACwx2UOhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEAAAAIvwEA ABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAABgDPADzAahDg8ADfBIAAAAAACfDwQAAAAEAAAA AACoDxgAAABQb3N0dXJlDVRyYW5zcG9ydA1DbGllbnQAAKEPFAAAABkAAAAAAAAAAAAZAAAAAAAg AAAADwAE8FgAAAASAArwCAAAABvcAAAACgAAgwAL8DAAAACFAAIAAACHAAEAAACBAQQAAAiDAQAA AAi/ARAAEADAAQEAAAj/AQgACAABAgIAAAgAABDwCAAAADAJwAPwBnALDwAE8LEAAACiDArwCAAA ABzcAAAACgAAowAL8DwAAACAAHDDZQ6FAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAA EADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAADAJUAS0BnELDwAN8EUAAAAAAJ8PBAAAAAQAAAAA AKgPFQAAAFBvc3R1cmUNQnJva2VyDUNsaWVudAAAoQ8UAAAAFgAAAAAAAAAAABYAAAAAACAAAAAP AATwWAAAABIACvAIAAAAHdwAAAAKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8B EAAQAMABAQAACP8BCAAIAAECAgAACAAAEPAIAAAAMAlgD5AScAsPAATwsQAAAKIMCvAIAAAAHtwA AAAKAACjAAvwPAAAAIAANMhlDoUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMAB AQAACP8BAAAIAAECAgAACAAAEPAIAAAAMAnADyQScQsPAA3wRQAAAAAAnw8EAAAABAAAAAAAqA8V AAAAUG9zdHVyZQ1Ccm9rZXINU2VydmVyAAChDxQAAAAWAAAAAAAAAAAAFgAAAAAAIAAAAA8ABPCr AAAAEgAK8AgAAAAf3AAAAAoAAKMAC/A8AAAAfwAAAAQAgAD002UOhQACAAAAhwABAAAAgQH/W1sA gwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAQ8AgAAACA/gAAsAGg/w8ADfA/AAAAAACf DwQAAAAEAAAAAACoDw0AAABQYXRjaAtNZXNzYWdlAAChDxYAAAAOAAAAAAAACAAAAQAOAAAAAAAC AAwADwAE8KcBAACiDArwCAAAACHcAAAACgAAowAL8DwAAACAABjoZQ6FAAIAAACHAAYAAAC/AAIA AgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAAHACkANkErEEDwAR 8CwAAAAPABQQJAAAAAEA8Q8cAAAAAAAABwBEAAAAAAAAAAAAAAIAAQABAAAAAAAUMA8ADfAHAQAA AACfDwQAAAAEAAAAAACoD5UAAAAwLglFbmRwb2ludCBBc3Nlc3NtZW50IFRyaWdnZXJlZCBCeSBT ZXJ2aWNlIFJlcXVlc3QNUGF0Y2ggTWFuYWdlbWVudCBDb2xsZWN0b3IgUmVwb3J0cyBQYXRjaCBM ZXZlbHMNUGF0Y2ggTWFuYWdlbWVudCBWYWxpZGF0b3Igc2VuZHMgVXBncmFkZSBBZHZpc29yeQAA oQ8eAAAANAAAAAAAAAAAAGIAAAAAAAEAAAABAJYAAAAAAAAAAACqDxoAAAB1AAAAAAAAAAkAAAAB AAAAAQAYAAAAAAAAAAAApg8OAAAA+AAAANgA+AEYAzgEWAUPAATwrgAAABIACvAIAAAAJNwAAAAK AACjAAvwPAAAAH8AAAAEAIAAjOllDoUAAgAAAIcAAQAAAIEB/1tbAIMBAAAACL8BEAAQAMABAQAA CP8BCAAIAAECAgAACAAAEPAIAAAAgP5ACPAJoP8PAA3wQgAAAAAAnw8EAAAABAAAAAAAqA8QAAAA QWR2aXNvcnkLTWVzc2FnZQAAoQ8WAAAAEQAAAAAAAAgAAAEAEQAAAAAAAgAMAA8ABPBIAAAAEgAK 8AgAAAAB3AAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgA BAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBPB FwAADwCKE7kXAAAAALoPEAAAAF8AXwBfAFAAUABUADEAMAAAAIsTmRcAAAAA6y4IAAAAFkPGAVAD VR0AAAArBAAAAE9yhbkfAETxxRYAAAAAJ/EgAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAAv2UO//// /xIAAAAPAD3xDQAAAEABQvEFAAAAAQkAAAAfAETxgBYAAAAAJ/EgAAAAAAAAAAAAAAABAAAAAAAA AAAAAAAAghMA/////xgAAAAPAD3xDQAAAEABQvEFAAAAAQQAAAAAAEHxFAAAAAEAAAABAAAAAAAA AAAAAAADAAAAPwAl8SwAAAAAACjxEAAAAAEAAAAJAAAAAAAAAAAAAAAPADzxDAAAAAAAASsEAAAA AQAAAE8AJfEsAAAAAAAo8RAAAAABAAAACgAAAAAAAAAAAAAADwA88QwAAAAAAAErBAAAAAEAAAAf AETxNAIAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xAAAAAB8A JfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAD/////HwBE8dwBAAAAACfxIAAAAAAAAAAAAAAAAAAA AAMAAAAAAAAAAAAAAAAAAAABAAAADwA98QAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAA AAAAAB8ARPGEAQAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfE0 AAAAQAFC8QUAAAABAQAAAJAAQvEFAAAAAQEAAACgAELxBQAAAAEAAAAAsABC8QUAAAABAQAAAB8A JfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8fgAAAAAACfxIAAAAAAAAAAAAAAAAwAA AAMAAAAAAAAAAAAAAAEAAAAZAAAADwA98QAAAAAPADHxoAAAAAAAOvEIAAAAAQAAAAEAAAAQAELx EQAAAAN2AGkAcwBpAGIAbABlAAAADwAq8W8AAAAAADPxEAAAAAQAAAAAAAAAAAAAAAAAAAAfAD7x KwAAAAAAQvEjAAAAA3MAdAB5AGwAZQAuAHYAaQBzAGkAYgBpAGwAaQB0AHkAAAAPADzxHAAAAAAA +yoUAAAAAgAAAAEAAAAh3AAAAAAAADQAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAA AB8ARPE0AgAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfEAAAAA HwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAP////8fAETx3AEAAAAAJ/EgAAAAAAAAAAAAAAAA AAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAA AAAAAAAAHwBE8YQBAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA9 8TQAAABAAULxBQAAAAEBAAAAkABC8QUAAAABAQAAAKAAQvEFAAAAAQAAAACwAELxBQAAAAEBAAAA HwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETx+AAAAAAAJ/EgAAAAAAAAAAAAAAAD AAAAAwAAAAAAAAAAAAAAAQAAABkAAAAPAD3xAAAAAA8AMfGgAAAAAAA68QgAAAABAAAAAQAAABAA QvERAAAAA3YAaQBzAGkAYgBsAGUAAAAPACrxbwAAAAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8A PvErAAAAAABC8SMAAAADcwB0AHkAbABlAC4AdgBpAHMAaQBiAGkAbABpAHQAeQAAAA8APPEcAAAA AAD7KhQAAAAAAAAAAQAAABbcAAD//////////x8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAA AAAAHwBE8TQCAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98QAA AAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAA/////x8ARPHcAQAAAAAn8SAAAAAAAAAAAAAA AAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAA AAAAAAAAAAAfAETxhAEAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAP AD3xNAAAAEABQvEFAAAAAQEAAACQAELxBQAAAAEBAAAAoABC8QUAAAABAAAAALAAQvEFAAAAAQEA AAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPH4AAAAAAAn8SAAAAAAAAAAAAAA AAMAAAADAAAAAAAAAAAAAAABAAAAGQAAAA8APfEAAAAADwAx8aAAAAAAADrxCAAAAAEAAAABAAAA EABC8REAAAADdgBpAHMAaQBiAGwAZQAAAA8AKvFvAAAAAAAz8RAAAAAEAAAAAAAAAAAAAAAAAAAA HwA+8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2AGkAcwBpAGIAaQBsAGkAdAB5AAAADwA88RwA AAAAAPsqFAAAAAAAAAABAAAAEdwAAP//////////HwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAA AAAAAAAfAETxNAIAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3x AAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAD/////HwBE8dwBAAAAACfxIAAAAAAAAAAA AAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98QAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAA AAAAAAAAAAAAAB8ARPGEAQAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAA AA8APfE0AAAAQAFC8QUAAAABAQAAAJAAQvEFAAAAAQEAAACgAELxBQAAAAEAAAAAsABC8QUAAAAB AQAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8fgAAAAAACfxIAAAAAAAAAAA AAAAAwAAAAMAAAAAAAAAAAAAAAEAAAAZAAAADwA98QAAAAAPADHxoAAAAAAAOvEIAAAAAQAAAAEA AAAQAELxEQAAAAN2AGkAcwBpAGIAbABlAAAADwAq8W8AAAAAADPxEAAAAAQAAAAAAAAAAAAAAAAA AAAfAD7xKwAAAAAAQvEjAAAAA3MAdAB5AGwAZQAuAHYAaQBzAGkAYgBpAGwAaQB0AHkAAAAPADzx HAAAAAAA+yoUAAAAAAAAAAEAAAAO3AAA//////////8fACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAA AAAAAAAAAB8ARPE0AgAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8A PfEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAP////8fAETx3AEAAAAAJ/EgAAAAAAAA AAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAA AAAAAAAAAAAAAAAAHwBE8YQBAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAB AAAADwA98TQAAABAAULxBQAAAAEBAAAAkABC8QUAAAABAQAAAKAAQvEFAAAAAQAAAACwAELxBQAA AAEBAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETx+AAAAAAAJ/EgAAAAAAAA AAAAAAADAAAAAwAAAAAAAAAAAAAAAQAAABkAAAAPAD3xAAAAAA8AMfGgAAAAAAA68QgAAAABAAAA AQAAABAAQvERAAAAA3YAaQBzAGkAYgBsAGUAAAAPACrxbwAAAAAAM/EQAAAABAAAAAAAAAAAAAAA AAAAAB8APvErAAAAAABC8SMAAAADcwB0AHkAbABlAC4AdgBpAHMAaQBiAGkAbABpAHQAeQAAAA8A PPEcAAAAAAD7KhQAAAACAAAAAQAAACHcAAA0AAAAZAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAA AAAAAAAAAAAAHwBE8SADAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAA DwA98QAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAA/////x8ARPHIAgAAAAAn8SAAAAAA AAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfEAAAAAHwAl8RgAAAAAACjxEAAAAAAA AAAAAAAAAAAAAAAAAAAfAETxcAIAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAA AAEAAAAPAD3xQQAAAEABQvEFAAAAAQEAAACQAELxBQAAAAEAAAAAoABC8QUAAAABAAAAALAAQvEF AAAAAQQAAAAwAULxBQAAAAEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAAACnx CAAAAAMAAAAAAAA/AAAp8QgAAAAEAAAAAAAAPx8ARPG3AQAAAAAn8SAAAAAAAAAAAAAAAAMAAAAD AAAAAAAAAAAAAAC4CwAAGQAAAA8APfEAAAAADwAu8X8BAAAAADfxIAAAANgAAAAAAMhCAADIQgAA AAAAAAAAAADIQgAAyEICAAAAEABC8Y0AAAADTQAgADAALgAxADkANAAxACAAMAAuADQANQA3ADYA MwAgAEwAIAAwAC4AMQA5ADQAMQAgADAALgA4ADQANAA0ADQAIABMACAAMAAuADcAMAA2ADcANwAg ADAALgA4ADQANAAyADEAIABMACAAMAAuADcAMAA5ADIAIAAwAC4ANAA1ADUAMwAyACAAAAAPACrx ugAAAAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8APvEqAAAAAABC8Q0AAAADcABwAHQAXwB4AAAA AABC8Q0AAAADcABwAHQAXwB5AAAADwA98UQAAAAwAELxAgAAAAAAoABC8QsAAAADQQBBAEEAQQAA AHAAQvEFAAAAAgAAAACAAELxBQAAAAJ90oM+kABC8QUAAAACob1EPg8APPEcAAAAAAD7KhQAAAAA AAAAAQAAAB/cAAD//////////x8ARPE/AgAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAA AAAAAAAAAQAAAA8APfEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAP////8fAETx5wEA AAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xAAAAAB8AJfEYAAAA AAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8Y8BAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAA AAAAAAAAAAAAAAABAAAADwA98UEAAABAAULxBQAAAAEBAAAAkABC8QUAAAABAQAAAKAAQvEFAAAA AQAAAACwAELxBQAAAAECAAAAMAFC8QUAAAABAQAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAA AAAAAAAAHwBE8fYAAAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAAEAAAAZAAAADwA9 8QAAAAAPADHxngAAAAAAOvEIAAAAAQAAAAEAAAAQAELxDwAAAANoAGkAZABkAGUAbgAAAA8AKvFv AAAAAAAz8RAAAAAEAAAAAAAAAAAAAAAAAAAAHwA+8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2 AGkAcwBpAGIAaQBsAGkAdAB5AAAADwA88RwAAAAAAPsqFAAAAAAAAAABAAAAH9wAAP////////// HwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETxHAUAAAAAJ/EgAAAAAAAAAAAAAAAA AAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAA AAD/////HwBE8dwBAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA9 8QAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPGEAQAAAAAn8SAAAAAAAAAA AAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfE0AAAAQAFC8QUAAAABAQAAAJAAQvEFAAAA AQEAAACgAELxBQAAAAEAAAAAsABC8QUAAAABAQAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAA AAAAAAAAHwBE8fgAAAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAAEAAAAZAAAADwA9 8QAAAAAPADHxoAAAAAAAOvEIAAAAAQAAAAEAAAAQAELxEQAAAAN2AGkAcwBpAGIAbABlAAAADwAq 8W8AAAAAADPxEAAAAAQAAAAAAAAAAAAAAAAAAAAfAD7xKwAAAAAAQvEjAAAAA3MAdAB5AGwAZQAu AHYAaQBzAGkAYgBpAGwAaQB0AHkAAAAPADzxHAAAAAAA+yoUAAAAAgAAAAEAAAAh3AAAZAAAAJYA AAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPHgAgAAAAAn8SAAAAAAAAAAAAAA AAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAA AAAAAAAAAAAfAETxiAIAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAP AD3xQQAAAEABQvEFAAAAAQMAAACQAELxBQAAAAEAAAAAoABC8QUAAAABAAAAALAAQvEFAAAAAQQA AAAwAULxBQAAAAEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAAACnxCAAAAAMA AAAAAAA/AAAp8QgAAAAEAAAAAAAAPx8ARPHPAQAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAA AAAAAAC4CwAAGQAAAA8APfEAAAAADwAu8YcBAAAAADfxIAAAANgAAAAAAMhCAADIQgAAAAAAAAAA AADIQgAAyEICAAAAEABC8ZUAAAADTQAgAC0AMAAuADEANQA1ADkAMQAgADAALgA0ADUANwA4ADYA IABMACAALQAwAC4AMQA1ADUAOQAxACAAMAAuADgANAA0ADYANwAgAEwAIAAwAC4AMwA1ADYANwA3 ACAAMAAuADgANAA0ADQANAAgAEwAIAAwAC4AMwA1ADkAMgAgADAALgA0ADUANQA1ADUAIAAAAA8A KvG6AAAAAAAz8RAAAAAEAAAAAAAAAAAAAAAAAAAAHwA+8SoAAAAAAELxDQAAAANwAHAAdABfAHgA AAAAAELxDQAAAANwAHAAdABfAHkAAAAPAD3xRAAAADAAQvECAAAAAACgAELxCwAAAANBAEEAQQBB AAAAcABC8QUAAAACAAAAAIAAQvEFAAAAAn3Sgz6QAELxBQAAAAKhvUQ+DwA88RwAAAAAAPsqFAAA AAAAAAABAAAAJNwAAP//////////AAAp8QgAAAACAAAAAACAvw8AAiuoAAAADwAIKzAAAAAAAAMr EAAAAAEAAAAAAAAAH9wAAAEAATABAAkrEAAAAAMAAAABAAAAAQAAAAAAAAAPAAgrMAAAAAAAAysQ AAAAAQAAAAEAAAAf3AAAAQABMAEACSsQAAAAAwAAAAEAAAABAAAAAAAAAA8ACCswAAAAAAADKxAA AAABAAAAAAAAACTcAAABAQEwAQAJKxAAAAADAAAAAQAAAAEAAAAAAAAADwDuA65GAAACAO8DGAAA AAEAAAANDgAAAAAAAAAAAIAFAQAABwAUMA8ADARnFwAADwAC8F8XAACQAwjwCAAAACYAAAAq5AAA DwAD8PcWAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAOQAAAUAAAAP AATweAAAABIACvAIAAAAAuQAACACAABjAAvwJAAAAH8AAAAEAIAA4JFlDr8BAAABAP8BAAABAAED AgQAAIgDAAAAAAAAEPAIAAAAAAAgAWAV0AIPABHwEAAAAAAAwwsIAAAAAAAAAA0AZQ4PAA3wDAAA AAAAng8EAAAAAAAAAA8ABPBYAAAAEgAK8AgAAAAD5AAAAAoAAIMAC/AwAAAAhQACAAAAhwABAAAA gQEEAAAIgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIAAAQ8AgAAADQBcAD8AawBw8ABPBY AAAAEgAK8AgAAAAE5AAAAAoAAIMAC/AwAAAAhQACAAAAhwABAAAAgQEEAAAIgwEAAAAIvwEQABAA wAEBAAAI/wEIAAgAAQICAAAIAAAQ8AgAAADQBWAPkBKwBw8ABPBYAAAAEgAK8AgAAAAF5AAAAAoA AIMAC/AwAAAAhQACAAAAhwABAAAAgQEEAAAIgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAI AAAQ8AgAAABgDGAPkBIADw8ABPBMAAAAQgEK8AgAAAAG5AAAAAoAAGMAC/AkAAAARAEEAAAAfwEA AAEAvwEAABAAwAEBAAAI/wEYABgAAQICAAAIAAAQ8AgAAACwB0AFQAUwCQ8ABPBMAAAAQgEK8AgA AAAH5AAAAAoAAGMAC/AkAAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI/wEYABgAAQICAAAIAAAQ 8AgAAACwB+AQ4BAwCQ8ABPBMAAAAQgEK8AgAAAAI5AAAAAoAAGMAC/AkAAAARAEEAAAAfwEAAAEA vwEAABAAwAEBAAAI/wEYABgAAQICAAAIAAAQ8AgAAAAQC0AFQAWQDA8ABPBMAAAAQgEK8AgAAAAJ 5AAAAAoAAGMAC/AkAAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI/wEYABgAAQICAAAIAAAQ8AgA AAAQC+AQ4BBgDA8ABPCyAAAAogwK8AgAAAAK5AAAAAoAAKMAC/A8AAAAgAC84GUOhQACAAAAhwAG AAAAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAAAgBiAE TQZmBw8ADfBGAAAAAACfDwQAAAAEAAAAAACoDxIAAABTZWN1cml0eQ1Db2xsZWN0b3IAAKEPGAAA ABMAAAAAAAAIAAABABMAAAAAACIAAAAOAA8ABPDUAAAAogwK8AgAAAAL5AAAAAoAAKMAC/A8AAAA gADYlmUOhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQIC AAAIAAAQ8AgAAAAgBpAPvRFmBw8ADfBoAAAAAACfDwQAAAAEAAAAAACoDxIAAABTZWN1cml0eQ1W YWxpZGF0b3IAAKEPGAAAABMAAAAAAAAIAAABABMAAAAAACIAAAAOAAAAqg8aAAAACQAAAAAAAAAJ AAAAAQAAAAEAAQAAAAAAAAAPAATwtAAAAKIMCvAIAAAADOQAAAAKAACjAAvwPAAAAIAAHJxlDoUA AgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAI AAAAkAxgDzwS0Q4PAA3wSAAAAAAAnw8EAAAABAAAAAAAqA8YAAAAUG9zdHVyZQ1UcmFuc3BvcnQN U2VydmVyAAChDxQAAAAZAAAAAAAAAAAAGQAAAAAAIAAAAA8AA/CIAQAADwAE8EYAAAABAAnwEAAA APAGAAAQBQAAYA8AAPcFAAACAArwCAAAAA3kAAABAgAAEwAL8AYAAACIAwAAAAAAABDwCAAAAAAG 8AZgD+cGDwAE8GYAAABCAQrwCAAAAA7kAAACCgAAkwAL8DYAAABEAQQAAAB/AQAAAQC/AQAAEADA AQEAAAjLAZ9vAADQAQEAAADRAQEAAAD/ARgAGAABAgIAAAgAAA/wEAAAAPAGAADQBQAAYA8AANAF AAAPAATwxAAAAKIMCvAIAAAAD+QAAAIKAACjAAvwPAAAAIAAeJ1lDoUAAgAAAIcABgAAAL8AAgAC AIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAD/AQAAAAIAcAABAFAABcDwAA 9wUAAA8ADfBQAAAAAACfDwQAAAAEAAAAAACoDyAAAABQb3N0dXJlIEF0dHJpYnV0ZSAoUEEpIHBy b3RvY29sIAAAoQ8UAAAAIQAAAAAAAAAAACEAAAAAACAAAAAPAAPwhAEAAA8ABPBGAAAAAQAJ8BAA AADwBgAAEAgAAGAPAAAACQAAAgAK8AgAAAAQ5AAAAQIAABMAC/AGAAAAiAMAAAAAAAAQ8AgAAABg CfAGYA9QCg8ABPBmAAAAQgEK8AgAAAAR5AAAAgoAAJMAC/A2AAAARAEEAAAAfwEAAAEAvwEAABAA wAEBAAAIywGfbwAA0AEBAAAA0QEBAAAA/wEYABgAAQICAAAIAAAP8BAAAADwBgAAAAkAAGAPAAAA CQAADwAE8MAAAACiDArwCAAAABLkAAACCgAAowAL8DwAAACAAPCpZQ6FAAIAAACHAAYAAAC/AAIA AgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAAA/wEAAAACwHAAAQCAAA0A4A APcIAAAPAA3wTAAAAAAAnw8EAAAABAAAAAAAqA8cAAAAUG9zdHVyZSBCcm9rZXIgKFBCKSBwcm90 b2NvbAAAoQ8UAAAAHQAAAAAAAAAAAB0AAAAAACAAAAAPAATwqgAAAKIMCvAIAAAAE+QAAAAKAACj AAvwPAAAAIAAaK5lDoUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8B AAAIAAECAgAACAAAEPAIAAAAsARxAyAHqgUPAA3wPgAAAAAAnw8EAAAABAAAAAAAqA8KAAAATkVB IENsaWVudAAAoQ8YAAAACwAAAAAAAAAAAAsAAAABACIAAQAAABQADwAE8KoAAACiDArwCAAAABTk AAAACgAAowAL8DwAAACAAByyZQ6FAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADA AQEAAAj/AQAACAABAgIAAAgAABDwCAAAALAEMA8VE6oFDwAN8D4AAAAAAJ8PBAAAAAQAAAAAAKgP CgAAAE5FQSBTZXJ2ZXIAAKEPGAAAAAsAAAAAAAAAAAALAAAAAQAiAAEAAAAUAA8AA/CIAQAADwAE 8EYAAAABAAnwEAAAAMAGAADQCwAAZA8AAMAMAAACAArwCAAAABXkAAABAgAAEwAL8AYAAACIAwAA AAAAABDwCAAAAMAMwAZkD7ANDwAE8GYAAABCAQrwCAAAABbkAAACCgAAkwAL8DYAAABEAQQAAAB/ AQAAAQC/AQAAEADAAQEAAAjLAZ9vAADQAQEAAADRAQEAAAD/ARgAGAABAgIAAAgAAA/wEAAAAPAG AADADAAAYA8AAMAMAAAPAATwxAAAAKIMCvAIAAAAF+QAAAIKAACjAAvwPAAAAIAAgKRlDoUAAgAA AIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAD/AQAAAA wAYAANALAABkDwAAtwwAAA8ADfBQAAAAAACfDwQAAAAEAAAAAACoDyAAAABQb3N0dXJlIFRyYW5z cG9ydCAoUFQpIHByb3RvY29scwAAoQ8UAAAAIQAAAAAAAAAAACEAAAAAACAAAAAPAATwWAAAABIA CvAIAAAAGOQAAAAKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEBBAAACIMBAAAACL8BEAAQAMABAQAA CP8BCAAIAAECAgAACAAAEPAIAAAAYAzAA/AG0A4PAATwtAAAAKIMCvAIAAAAGeQAAAAKAACjAAvw PAAAAIAAaLllDoUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAI AAECAgAACAAAEPAIAAAAYAzwA8wGoQ4PAA3wSAAAAAAAnw8EAAAABAAAAAAAqA8YAAAAUG9zdHVy ZQ1UcmFuc3BvcnQNQ2xpZW50AAChDxQAAAAZAAAAAAAAAAAAGQAAAAAAIAAAAA8ABPBYAAAAEgAK 8AgAAAAa5AAAAAoAAIMAC/AwAAAAhQACAAAAhwABAAAAgQEEAAAIgwEAAAAIvwEQABAAwAEBAAAI /wEIAAgAAQICAAAIAAAQ8AgAAAAwCcAD8AZwCw8ABPCxAAAAogwK8AgAAAAb5AAAAAoAAKMAC/A8 AAAAgACQDWUOhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgA AQICAAAIAAAQ8AgAAAAwCVAEtAZxCw8ADfBFAAAAAACfDwQAAAAEAAAAAACoDxUAAABQb3N0dXJl DUJyb2tlcg1DbGllbnQAAKEPFAAAABYAAAAAAAAAAAAWAAAAAAAgAAAADwAE8FgAAAASAArwCAAA ABzkAAAACgAAgwAL8DAAAACFAAIAAACHAAEAAACBAQQAAAiDAQAAAAi/ARAAEADAAQEAAAj/AQgA CAABAgIAAAgAABDwCAAAADAJYA+QEnALDwAE8LEAAACiDArwCAAAAB3kAAAACgAAowAL8DwAAACA AHgLZQ6FAAIAAACHAAYAAAC/AAIAAgCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIA AAgAABDwCAAAADAJwA8kEnELDwAN8EUAAAAAAJ8PBAAAAAQAAAAAAKgPFQAAAFBvc3R1cmUNQnJv a2VyDVNlcnZlcgAAoQ8UAAAAFgAAAAAAAAAAABYAAAAAACAAAAAPAATwrAAAABIACvAIAAAAHuQA AAAKAACjAAvwPAAAAH8AAAAEAIAAbO9lDoUAAgAAAIcAAQAAAIEB/1tbAIMBAAAACL8BEAAQAMAB AQAACP8BCAAIAAECAgAACAAAEPAIAAAAgP4AALABoP8PAA3wQAAAAAAAnw8EAAAABAAAAAAAqA8O AAAAQ2hhbmdlC01lc3NhZ2UAAKEPFgAAAA8AAAAAAAAIAAABAA8AAAAAAAIADAAPAATw0AEAAKIM CvAIAAAAH+QAAAAKAACjAAvwPAAAAIAAZIVlDoUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAA CL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAA4AG0AoANHAUPABHwfAAAAA8AFBAkAAAA AQDxDxwAAAAAAAAHAEQAAAAAAAAAAAAAAgABAAEAAAAAABQwDwCIE0gAAAAPAIoTQAAAAAAAug8O AAAAXwBfAF8AUABQAFQAOQAAAIsTIgAAAAAArA8aAAAAAAAAAAAAAAAAAAAAAAAAAgEAAAAAAAAA AAAPAA3w4AAAAAAAnw8EAAAABAAAAAAAqA+CAAAAMC4JQ29uc3RhbnQgTW9uaXRvcmluZyBpbiBQ bGFjZQ1TZWN1cml0eSBDb2xsZWN0b3IgRGV0ZWN0cyBQb3N0dXJlIENoYW5nZQ1TZWN1cml0eSBD b2xsZWN0b3IgVHJpZ2dlcnMgUmVhc3Nlc3NtZW50DUFjY2VzcyBMaW1pdGVkDQAAoQ8sAAAAIAAA AAAAAAAAAGMAAAAAAAEAAAABACAAAAAAAAIAEABjAAAAAAQCAAAEEAAAAKYPDgAAAPgAAADYAPgB GAM4BFgFDwAE8MYAAAASAArwCAAAACLkAAAACgAAowAL8DwAAAB/AAAABACAAHh6NA6FAAIAAACH AAEAAACBAf9bWwCDAQAAAAi/ARAAEADAAQEAAAj/AQgACAABAgIAAAgAABDwCAAAAID+QAjwCaD/ DwAN8FoAAAAAAJ8PBAAAAAQAAAAAAKgPDgAAAFJlbWVkbgtNZXNzYWdlAAChDxYAAAAPAAAAAAAA CAAAAQAPAAAAAAACAAwAAACqDxIAAAAGAAAAAQAAAAEACQAAAAAAAAAPAATwZwEAAKIMCvAIAAAA JOQAAAAKAACjAAvwPAAAAIAAKL00DoUAAgAAAIcABgAAAL8AAgACAIEBBAAACIMBAAAACL8BAAAQ AMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAA6gFoDRAUjAQPABHwdAAAAA8AFBAkAAAAAQDxDxwA AAAAAAAHAEQAAAAAAAAAAAAACwABAAEAAAAAABQwDwCIE0AAAAAPAIoTOAAAAAAAug8OAAAAXwBf AF8AUABQAFQAOQAAAIsTGgAAAAAArA8SAAAAAAAAAwEAAwAEAAAAAAAAAAAADwAN8H8AAAAAAJ8P BAAAAAQAAAAAAKgPMwAAAEF1dG9tYXRlZCBSZW1lZGlhdGlvbg1SZWFzc2Vzc21lbnQNQWNjZXNz IFJlc3RvcmVkDQAAoQ8aAAAANAAAAAAAIQAAAAEAAAAAATQAAAAAAAIAEAAAAKYPDgAAAPgAAADY APgBGAM4BFgFDwAE8IwAAACCBArwCAAAACXkAAAACgAAgwAL8DAAAACFAAIAAACHAAEAAACBAf9b WwCDAQAAAAi/ARAAEADAAQEAAAj/AQgACAABAgIAAAgAABDwCAAAAHAFAAOABJAGDwAR8CwAAAAP ABQQJAAAAAEA8Q8cAAAAAAAABwBEAAAAAAAAAAAAAAQAAQABAAAAAAAUMA8ABPCMAAAAggQK8AgA AAAm5AAAAAoAAIMAC/AwAAAAhQACAAAAhwABAAAAgQEHAAAIgwEAAAAIvwEQABAAwAEBAAAI/wEI AAgAAQICAAAIAAAQ8AgAAABwBQADgASQBg8AEfAsAAAADwAUECQAAAABAPEPHAAAAAAAAAcARAAA AAAAAAAAAAAOAAEAAQAAAAAAFDAPAATwrwAAABIACvAIAAAAJ+QAAAAKAACjAAvwPAAAAH8AAAAE AIAAGBo0DoUAAgAAAIcAAQAAAIEB/1tbAIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACAAA EPAIAAAAgP4QAsADoP8PAA3wQwAAAAAAnw8EAAAABAAAAAAAqA8RAAAAQWxsIENsZWFyC01lc3Nh Z2UAAKEPFgAAABIAAAAAAAAIAAABABIAAAAAAAIADAAPAATw6QAAABIACvAIAAAAKOQAAAAKAACj AAvwPAAAAH8AAAAEAIAAeB00DoUAAgAAAIcAAQAAAIEBwMDAAIMBAAAACL8BEAAQAMABAQAACP8B CAAIAAECAgAACBMAIvEGAAAAvwEAAGAAAAAQ8AgAAABADjAJgA0ADw8AEfAsAAAADwAUECQAAAAB APEPHAAAAAAAAAcERAAAAAAAAAAAAAAKAAEAAQAAAAAAFDAPAA3wOwAAAAAAnw8EAAAABAAAAAAA qA8LAAAARW5mb3JjZW1lbnQAAKEPFAAAAAwAAAAAAAAIAAABAAwAAAAAAAAADwAE8IYAAABCAQrw CAAAACnkAABACgAAcwAL8CoAAABEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAjRAQEAAAD/ARgAGAAB AgIAAAgAABDwCAAAAHAOgA1gD3AODwAR8CwAAAAPABQQJAAAAAEA8Q8cAAAAAAAABwBAAAAAAAAA AAAAAAkAAQABAAAAAAAUMA8ABPBIAAAAEgAK8AgAAAAB5AAAAAwAAIMAC/AwAAAAgQEAAAAIgwEF AAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICA gAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBPvLgAADwCKE+cuAAAAALoPEAAAAF8AXwBfAFAAUABU ADEAMAAAAIsTxy4AAAAA6y4IAAAAFkPGAVADVR0AAAArBAAAAC7Q5hsfAETx2ywAAAAAJ/EgAAAA AAAAAAMAAAAAAAAAAAAAAAAAAAAAejQO/////xIAAAAPAD3xDQAAAEABQvEFAAAAAQkAAAAfAETx liwAAAAAJ/EgAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAghMA/////xgAAAAPAD3xDQAAAEABQvEF AAAAAQQAAAAAAEHxFAAAAAEAAAABAAAAAAAAAAAAAAADAAAAPwAl8SwAAAAAACjxEAAAAAEAAAAJ AAAAAAAAAAAAAAAPADzxDAAAAAAAASsEAAAAAQAAAE8AJfEsAAAAAAAo8RAAAAABAAAACgAAAAAA AAAAAAAADwA88QwAAAAAAAErBAAAAAEAAAAfAETxNAIAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAA AAAAAAAAAAAAAAAAAAEAAAAPAD3xAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAD///// HwBE8dwBAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98QAAAAAf ACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPGEAQAAAAAn8SAAAAAAAAAAAAAAAAAA AAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfE0AAAAQAFC8QUAAAABAQAAAJAAQvEFAAAAAQEAAACg AELxBQAAAAEAAAAAsABC8QUAAAABAQAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAA HwBE8fgAAAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAAEAAAAZAAAADwA98QAAAAAP ADHxoAAAAAAAOvEIAAAAAQAAAAEAAAAQAELxEQAAAAN2AGkAcwBpAGIAbABlAAAADwAq8W8AAAAA ADPxEAAAAAQAAAAAAAAAAAAAAAAAAAAfAD7xKwAAAAAAQvEjAAAAA3MAdAB5AGwAZQAuAHYAaQBz AGkAYgBpAGwAaQB0AHkAAAAPADzxHAAAAAAA+yoUAAAAAgAAAAEAAAAf5AAAAAAAACAAAAAfACXx GAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPE0AgAAAAAn8SAAAAAAAAAAAAAAAAAAAAAD AAAAAAAAAAAAAAAAAAAAAQAAAA8APfEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAP// //8fAETx3AEAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xAAAA AB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8YQBAAAAACfxIAAAAAAAAAAAAAAA AAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98TQAAABAAULxBQAAAAEBAAAAkABC8QUAAAABAQAA AKAAQvEFAAAAAQAAAACwAELxBQAAAAEBAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAA AAAfAETx+AAAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAAAQAAABkAAAAPAD3xAAAA AA8AMfGgAAAAAAA68QgAAAABAAAAAQAAABAAQvERAAAAA3YAaQBzAGkAYgBsAGUAAAAPACrxbwAA AAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8APvErAAAAAABC8SMAAAADcwB0AHkAbABlAC4AdgBp AHMAaQBiAGkAbABpAHQAeQAAAA8APPEcAAAAAAD7KhQAAAACAAAAAQAAAB/kAAAgAAAASgAAAB8A JfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8TQCAAAAACfxIAAAAAAAAAAAAAAAAAAA AAMAAAAAAAAAAAAAAAAAAAABAAAADwA98QAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAA /////x8ARPHcAQAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfEA AAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETxhAEAAAAAJ/EgAAAAAAAAAAAA AAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xNAAAAEABQvEFAAAAAQEAAACQAELxBQAAAAEB AAAAoABC8QUAAAABAAAAALAAQvEFAAAAAQEAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAA AAAAAB8ARPH4AAAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAABAAAAGQAAAA8APfEA AAAADwAx8aAAAAAAADrxCAAAAAEAAAABAAAAEABC8REAAAADdgBpAHMAaQBiAGwAZQAAAA8AKvFv AAAAAAAz8RAAAAAEAAAAAAAAAAAAAAAAAAAAHwA+8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2 AGkAcwBpAGIAaQBsAGkAdAB5AAAADwA88RwAAAAAAPsqFAAAAAAAAAABAAAAJeQAAP////////// HwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETxNAIAAAAAJ/EgAAAAAAAAAAAAAAAA AAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAA AAD/////HwBE8dwBAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA9 8QAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPGEAQAAAAAn8SAAAAAAAAAA AAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfE0AAAAQAFC8QUAAAABAQAAAJAAQvEFAAAA AQEAAACgAELxBQAAAAEAAAAAsABC8QUAAAABAQAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAA AAAAAAAAHwBE8fgAAAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAAEAAAAZAAAADwA9 8QAAAAAPADHxoAAAAAAAOvEIAAAAAQAAAAEAAAAQAELxEQAAAAN2AGkAcwBpAGIAbABlAAAADwAq 8W8AAAAAADPxEAAAAAQAAAAAAAAAAAAAAAAAAAAfAD7xKwAAAAAAQvEjAAAAA3MAdAB5AGwAZQAu AHYAaQBzAGkAYgBpAGwAaQB0AHkAAAAPADzxHAAAAAAA+yoUAAAAAgAAAAEAAAAf5AAASgAAAHMA AAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPEgAwAAAAAn8SAAAAAAAAAAAAAA AAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAA AAAAAP////8fAETxyAIAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAP AD3xAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8XACAAAAACfxIAAAAAAA AAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98UEAAABAAULxBQAAAAEBAAAAkABC8QUA AAABAAAAAKAAQvEFAAAAAQAAAACwAELxBQAAAAEEAAAAMAFC8QUAAAABAAAAAB8AJfEYAAAAAAAo 8RAAAAAAAAAAAAAAAAAAAAAAAAAAAAAp8QgAAAADAAAAAAAAPwAAKfEIAAAABAAAAAAAAD8fAETx twEAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAAuAsAABkAAAAPAD3xAAAAAA8ALvF/ AQAAAAA38SAAAADYAAAAAADIQgAAyEIAAAAAAAAAAAAAyEIAAMhCAgAAABAAQvGNAAAAA00AIAAw AC4AMQA5ADQAMQAgADAALgA0ADUANwA2ADMAIABMACAAMAAuADEAOQA0ADEAIAAwAC4AOAA0ADQA NAA0ACAATAAgADAALgA3ADAANgA3ADcAIAAwAC4AOAA0ADQAMgAxACAATAAgADAALgA3ADAAOQAy ACAAMAAuADQANQA1ADMAMgAgAAAADwAq8boAAAAAADPxEAAAAAQAAAAAAAAAAAAAAAAAAAAfAD7x KgAAAAAAQvENAAAAA3AAcAB0AF8AeAAAAAAAQvENAAAAA3AAcAB0AF8AeQAAAA8APfFEAAAAMABC 8QIAAAAAAKAAQvELAAAAA0EAQQBBAEEAAABwAELxBQAAAAIAAAAAgABC8QUAAAACfdKDPpAAQvEF AAAAAqG9RD4PADzxHAAAAAAA+yoUAAAAAAAAAAEAAAAe5AAA//////////8fAETxPwIAAAAAJ/Eg AAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xAAAAAB8AJfEYAAAAAAAo8RAA AAAAAAAAAAAAAAAAAAD/////HwBE8ecBAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAA AAAAAAABAAAADwA98QAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPGPAQAA AAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfFBAAAAQAFC8QUAAAAB AQAAAJAAQvEFAAAAAQEAAACgAELxBQAAAAEAAAAAsABC8QUAAAABAgAAADABQvEFAAAAAQEAAAAf ACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPH2AAAAAAAn8SAAAAAAAAAAAAAAAAMA AAADAAAAAAAAAAAAAAABAAAAGQAAAA8APfEAAAAADwAx8Z4AAAAAADrxCAAAAAEAAAABAAAAEABC 8Q8AAAADaABpAGQAZABlAG4AAAAPACrxbwAAAAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8APvEr AAAAAABC8SMAAAADcwB0AHkAbABlAC4AdgBpAHMAaQBiAGkAbABpAHQAeQAAAA8APPEcAAAAAAD7 KhQAAAAAAAAAAQAAAB7kAAD//////////x8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAA HwBE8TQCAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98QAAAAAf ACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAA/////x8ARPHcAQAAAAAn8SAAAAAAAAAAAAAAAAAA AAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAA AAAAAAAfAETxhAEAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3x NAAAAEABQvEFAAAAAQEAAACQAELxBQAAAAEBAAAAoABC8QUAAAABAAAAALAAQvEFAAAAAQEAAAAf ACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPH4AAAAAAAn8SAAAAAAAAAAAAAAAAMA AAADAAAAAAAAAAAAAAABAAAAGQAAAA8APfEAAAAADwAx8aAAAAAAADrxCAAAAAEAAAABAAAAEABC 8REAAAADdgBpAHMAaQBiAGwAZQAAAA8AKvFvAAAAAAAz8RAAAAAEAAAAAAAAAAAAAAAAAAAAHwA+ 8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2AGkAcwBpAGIAaQBsAGkAdAB5AAAADwA88RwAAAAA APsqFAAAAAIAAAABAAAAH+QAAHMAAACCAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAA AAAfAETxzQMAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xAAAA AB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAD/////HwBE8XUDAAAAACfxIAAAAAAAAAAAAAAA AAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98QAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAA AAAAAAAAAB8ARPGEAQAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8A PfE0AAAAQAFC8QUAAAABAQAAAJAAQvEFAAAAAQEAAACgAELxBQAAAAEAAAAAsABC8QUAAAABAQAA AB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8fgAAAAAACfxIAAAAAAAAAAAAAAA AwAAAAMAAAAAAAAAAAAAAAEAAAAZAAAADwA98QAAAAAPADHxoAAAAAAAOvEIAAAAAQAAAAEAAAAQ AELxEQAAAAN2AGkAcwBpAGIAbABlAAAADwAq8W8AAAAAADPxEAAAAAQAAAAAAAAAAAAAAAAAAAAf AD7xKwAAAAAAQvEjAAAAA3MAdAB5AGwAZQAuAHYAaQBzAGkAYgBpAGwAaQB0AHkAAAAPADzxHAAA AAAA+yoUAAAAAAAAAAEAAAAp5AAA//////////8fACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAA AAAAAB8ARPGRAQAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfFB AAAAQAFC8QUAAAABAgAAAJAAQvEFAAAAAQEAAACgAELxBQAAAAEAAAAAsABC8QUAAAABAQAAADAB QvEFAAAAAQAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPH4AAAAAAAn8SAA AAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAABAAAAGQAAAA8APfEAAAAADwAx8aAAAAAAADrxCAAA AAEAAAABAAAAEABC8REAAAADdgBpAHMAaQBiAGwAZQAAAA8AKvFvAAAAAAAz8RAAAAAEAAAAAAAA AAAAAAAAAAAAHwA+8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2AGkAcwBpAGIAaQBsAGkAdAB5 AAAADwA88RwAAAAAAPsqFAAAAAAAAAABAAAAKOQAAP//////////HwAl8RgAAAAAACjxEAAAAAAA AAAAAAAAAAAAAAAAAAAfAETxHAUAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAA AAEAAAAPAD3xAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAD/////HwBE8dwBAAAAACfx IAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98QAAAAAfACXxGAAAAAAAKPEQ AAAAAAAAAAAAAAAAAAAAAAAAAB8ARPGEAQAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAA AAAAAAAAAQAAAA8APfE0AAAAQAFC8QUAAAABAQAAAJAAQvEFAAAAAQEAAACgAELxBQAAAAEAAAAA sABC8QUAAAABAQAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8fgAAAAAACfx IAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAAEAAAAZAAAADwA98QAAAAAPADHxoAAAAAAAOvEI AAAAAQAAAAEAAAAQAELxEQAAAAN2AGkAcwBpAGIAbABlAAAADwAq8W8AAAAAADPxEAAAAAQAAAAA AAAAAAAAAAAAAAAfAD7xKwAAAAAAQvEjAAAAA3MAdAB5AGwAZQAuAHYAaQBzAGkAYgBpAGwAaQB0 AHkAAAAPADzxHAAAAAAA+yoUAAAAAgAAAAEAAAAk5AAAAAAAABYAAAAfACXxGAAAAAAAKPEQAAAA AAAAAAAAAAAAAAAAAAAAAB8ARPHgAgAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAA AAAAAQAAAA8APfEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETxiAIAAAAA J/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xQQAAAEABQvEFAAAAAQMA AACQAELxBQAAAAEAAAAAoABC8QUAAAABAAAAALAAQvEFAAAAAQQAAAAwAULxBQAAAAEAAAAAHwAl 8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAAACnxCAAAAAMAAAAAAAA/AAAp8QgAAAAEAAAA AAAAPx8ARPHPAQAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAC4CwAAGQAAAA8APfEA AAAADwAu8YcBAAAAADfxIAAAANgAAAAAAMhCAADIQgAAAAAAAAAAAADIQgAAyEICAAAAEABC8ZUA AAADTQAgAC0AMAAuADEANQA1ADkAMQAgADAALgA0ADUANwA4ADYAIABMACAALQAwAC4AMQA1ADUA OQAxACAAMAAuADgANAA0ADYANwAgAEwAIAAwAC4AMwA1ADYANwA3ACAAMAAuADgANAA0ADQANAAg AEwAIAAwAC4AMwA1ADkAMgAgADAALgA0ADUANQA1ADUAIAAAAA8AKvG6AAAAAAAz8RAAAAAEAAAA AAAAAAAAAAAAAAAAHwA+8SoAAAAAAELxDQAAAANwAHAAdABfAHgAAAAAAELxDQAAAANwAHAAdABf AHkAAAAPAD3xRAAAADAAQvECAAAAAACgAELxCwAAAANBAEEAQQBBAAAAcABC8QUAAAACAAAAAIAA QvEFAAAAAn3Sgz6QAELxBQAAAAKhvUQ+DwA88RwAAAAAAPsqFAAAAAAAAAABAAAAIuQAAP////// ////AAAp8QgAAAACAAAAAACAvx8ARPE/AgAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAA AAAAAAAAAQAAAA8APfEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAP////8fAETx5wEA AAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xAAAAAB8AJfEYAAAA AAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8Y8BAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAA AAAAAAAAAAAAAAABAAAADwA98UEAAABAAULxBQAAAAEBAAAAkABC8QUAAAABAQAAAKAAQvEFAAAA AQAAAACwAELxBQAAAAECAAAAMAFC8QUAAAABAQAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAA AAAAAAAAHwBE8fYAAAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAAEAAAAZAAAADwA9 8QAAAAAPADHxngAAAAAAOvEIAAAAAQAAAAEAAAAQAELxDwAAAANoAGkAZABkAGUAbgAAAA8AKvFv AAAAAAAz8RAAAAAEAAAAAAAAAAAAAAAAAAAAHwA+8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2 AGkAcwBpAGIAaQBsAGkAdAB5AAAADwA88RwAAAAAAPsqFAAAAAAAAAABAAAAIuQAAP////////// HwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETxNAIAAAAAJ/EgAAAAAAAAAAAAAAAA AAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAA AAD/////HwBE8dwBAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA9 8QAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPGEAQAAAAAn8SAAAAAAAAAA AAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfE0AAAAQAFC8QUAAAABAQAAAJAAQvEFAAAA AQEAAACgAELxBQAAAAEAAAAAsABC8QUAAAABAQAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAA AAAAAAAAHwBE8fgAAAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAAEAAAAZAAAADwA9 8QAAAAAPADHxoAAAAAAAOvEIAAAAAQAAAAEAAAAQAELxEQAAAAN2AGkAcwBpAGIAbABlAAAADwAq 8W8AAAAAADPxEAAAAAQAAAAAAAAAAAAAAAAAAAAfAD7xKwAAAAAAQvEjAAAAA3MAdAB5AGwAZQAu AHYAaQBzAGkAYgBpAGwAaQB0AHkAAAAPADzxHAAAAAAA+yoUAAAAAAAAAAEAAAAm5AAA//////// //8fACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPE0AgAAAAAn8SAAAAAAAAAAAAAA AAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAA AAAAAP////8fAETx3AEAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAP AD3xAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8YQBAAAAACfxIAAAAAAA AAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98TQAAABAAULxBQAAAAEBAAAAkABC8QUA AAABAQAAAKAAQvEFAAAAAQAAAACwAELxBQAAAAEBAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAA AAAAAAAAAAAfAETx+AAAAAAAJ/EgAAAAAAAAAAAAAAADAAAAAwAAAAAAAAAAAAAAAQAAABkAAAAP AD3xAAAAAA8AMfGgAAAAAAA68QgAAAABAAAAAQAAABAAQvERAAAAA3YAaQBzAGkAYgBsAGUAAAAP ACrxbwAAAAAAM/EQAAAABAAAAAAAAAAAAAAAAAAAAB8APvErAAAAAABC8SMAAAADcwB0AHkAbABl AC4AdgBpAHMAaQBiAGkAbABpAHQAeQAAAA8APPEcAAAAAAD7KhQAAAACAAAAAQAAACTkAAAWAAAA IwAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8SYDAAAAACfxIAAAAAAAAAAA AAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98QAAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAA AAAAAAAA/////x8ARPHOAgAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAA AA8APfEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETxdgIAAAAAJ/EgAAAA AAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xQQAAAEABQvEFAAAAAQEAAACQAELx BQAAAAEAAAAAoABC8QUAAAABAAAAALAAQvEFAAAAAQQAAAAwAULxBQAAAAEAAAAAHwAl8RgAAAAA ACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAAACnxCAAAAAMAAAAAAAA/AAAp8QgAAAAEAAAAAAAAPx8A RPG9AQAAAAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAC4CwAAGQAAAA8APfEAAAAADwAu 8YUBAAAAADfxIAAAANgAAAAAAMhCAADIQgAAAAAAAAAAAADIQgAAyEICAAAAEABC8ZMAAAADTQAg ADAALgAxADAANAAxADYAIAAwAC4ANAA1ADcAOAA2ACAATAAgADAALgAxADAANAAxADYAIAAwAC4A OAA0ADQANgA3ACAATAAgADAALgA2ADEANgA4ADQAIAAwAC4AOAA0ADQANAA0ACAATAAgADAALgA2 ADEAOQAyADcAIAAwAC4ANAA1ADUANQA1ACAAAAAPACrxugAAAAAAM/EQAAAABAAAAAAAAAAAAAAA AAAAAB8APvEqAAAAAABC8Q0AAAADcABwAHQAXwB4AAAAAABC8Q0AAAADcABwAHQAXwB5AAAADwA9 8UQAAAAwAELxAgAAAAAAoABC8QsAAAADQQBBAEEAQQAAAHAAQvEFAAAAAgAAAACAAELxBQAAAAJ9 0oM+kABC8QUAAAACob1EPg8APPEcAAAAAAD7KhQAAAAAAAAAAQAAACfkAAD//////////x8ARPE/ AgAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAAAA8APfEAAAAAHwAl8RgA AAAAACjxEAAAAAAAAAAAAAAAAAAAAP////8fAETx5wEAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAA AAAAAAAAAAAAAAAAAAEAAAAPAD3xAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAA HwBE8Y8BAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98UEAAABA AULxBQAAAAEBAAAAkABC8QUAAAABAQAAAKAAQvEFAAAAAQAAAACwAELxBQAAAAECAAAAMAFC8QUA AAABAQAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8fYAAAAAACfxIAAAAAAA AAAAAAAAAwAAAAMAAAAAAAAAAAAAAAEAAAAZAAAADwA98QAAAAAPADHxngAAAAAAOvEIAAAAAQAA AAEAAAAQAELxDwAAAANoAGkAZABkAGUAbgAAAA8AKvFvAAAAAAAz8RAAAAAEAAAAAAAAAAAAAAAA AAAAHwA+8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2AGkAcwBpAGIAaQBsAGkAdAB5AAAADwA8 8RwAAAAAAPsqFAAAAAAAAAABAAAAJ+QAAP//////////HwAl8RgAAAAAACjxEAAAAAAAAAAAAAAA AAAAAAAAAAAfAETxNAIAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAP AD3xAAAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAD/////HwBE8dwBAAAAACfxIAAAAAAA AAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAABAAAADwA98QAAAAAfACXxGAAAAAAAKPEQAAAAAAAA AAAAAAAAAAAAAAAAAB8ARPGEAQAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAA AQAAAA8APfE0AAAAQAFC8QUAAAABAQAAAJAAQvEFAAAAAQEAAACgAELxBQAAAAEAAAAAsABC8QUA AAABAQAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE8fgAAAAAACfxIAAAAAAA AAAAAAAAAwAAAAMAAAAAAAAAAAAAAAEAAAAZAAAADwA98QAAAAAPADHxoAAAAAAAOvEIAAAAAQAA AAEAAAAQAELxEQAAAAN2AGkAcwBpAGIAbABlAAAADwAq8W8AAAAAADPxEAAAAAQAAAAAAAAAAAAA AAAAAAAfAD7xKwAAAAAAQvEjAAAAA3MAdAB5AGwAZQAuAHYAaQBzAGkAYgBpAGwAaQB0AHkAAAAP ADzxHAAAAAAA+yoUAAAAAgAAAAEAAAAk5AAAIwAAADMAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAA AAAAAAAAAAAAAB8ARPHJAwAAAAAn8SAAAAAAAAAAAAAAAAAAAAADAAAAAAAAAAAAAAAAAAAAAQAA AA8APfEAAAAAHwAl8RgAAAAAACjxEAAAAAAAAAAAAAAAAAAAAP////8fAETxcQMAAAAAJ/EgAAAA AAAAAAAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAEAAAAPAD3xAAAAAB8AJfEYAAAAAAAo8RAAAAAA AAAAAAAAAAAAAAAAAAAAHwBE8Y8BAAAAACfxIAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAA AAABAAAADwA98UEAAABAAULxBQAAAAEBAAAAkABC8QUAAAABAQAAAKAAQvEFAAAAAQAAAACwAELx BQAAAAECAAAAMAFC8QUAAAABAQAAAB8AJfEYAAAAAAAo8RAAAAAAAAAAAAAAAAAAAAAAAAAAHwBE 8fYAAAAAACfxIAAAAAAAAAAAAAAAAwAAAAMAAAAAAAAAAAAAAAEAAAAZAAAADwA98QAAAAAPADHx ngAAAAAAOvEIAAAAAQAAAAEAAAAQAELxDwAAAANoAGkAZABkAGUAbgAAAA8AKvFvAAAAAAAz8RAA AAAEAAAAAAAAAAAAAAAAAAAAHwA+8SsAAAAAAELxIwAAAANzAHQAeQBsAGUALgB2AGkAcwBpAGIA aQBsAGkAdAB5AAAADwA88RwAAAAAAPsqFAAAAAAAAAABAAAAKOQAAP//////////HwAl8RgAAAAA ACjxEAAAAAAAAAAAAAAAAAAAAAAAAAAfAETxggEAAAAAJ/EgAAAAAAAAAAAAAAAAAAAAAwAAAAAA AAAAAAAAAAAAAAEAAAAPAD3xNAAAAEABQvEFAAAAAQIAAACQAELxBQAAAAEBAAAAoABC8QUAAAAB AAAAALAAQvEFAAAAAQIAAAAfACXxGAAAAAAAKPEQAAAAAAAAAAAAAAAAAAAAAAAAAB8ARPH2AAAA AAAn8SAAAAAAAAAAAAAAAAMAAAADAAAAAAAAAAAAAAABAAAAGQAAAA8APfEAAAAADwAx8Z4AAAAA ADrxCAAAAAEAAAABAAAAEABC8Q8AAAADaABpAGQAZABlAG4AAAAPACrxbwAAAAAAM/EQAAAABAAA AAAAAAAAAAAAAAAAAB8APvErAAAAAABC8SMAAAADcwB0AHkAbABlAC4AdgBpAHMAaQBiAGkAbABp AHQAeQAAAA8APPEcAAAAAAD7KhQAAAAAAAAAAQAAACnkAAD//////////x8AJfEYAAAAAAAo8RAA AAAAAAAAAAAAAAAAAAAAAAAADwACK8ABAAAPAAgrMAAAAAAAAysQAAAAAQAAAAAAAAAe5AAAAQAB MAEACSsQAAAAAwAAAAEAAAABAAAAAAAAAA8ACCswAAAAAAADKxAAAAABAAAAAQAAAB7kAAABAAEw AQAJKxAAAAADAAAAAQAAAAEAAAAAAAAADwAIKzAAAAAAAAMrEAAAAAEAAAAAAAAAIuQAAAEAATAB AAkrEAAAAAMAAAABAAAAAQAAAAAAAAAPAAgrMAAAAAAAAysQAAAAAQAAAAEAAAAi5AAAAQABMAEA CSsQAAAAAwAAAAEAAAABAAAAAAAAAA8ACCswAAAAAAADKxAAAAABAAAAAAAAACfkAAABAAEwAQAJ KxAAAAADAAAAAQAAAAEAAAAAAAAADwAIKzAAAAAAAAMrEAAAAAEAAAABAAAAJ+QAAAEAATABAAkr EAAAAAMAAAABAAAAAQAAAAAAAAAPAAgrMAAAAAAAAysQAAAAAQAAAAAAAAAo5AAAAQABMAEACSsQ AAAAAwAAAAEAAAABAAAAAAAAAA8ACCswAAAAAAADKxAAAAABAAAAAQAAACjkAAABAAEwAQAJKxAA AAADAAAAAQAAAAEAAAAAAAAADwDuA30CAAACAO8DGAAAAAEAAAANDgAAAAAAAAAAAIAAAAAABwAU MA8ADASUAQAADwAC8IwBAADgAwjwCAAAAAMAAAAD+AAADwAD8CQBAAAPAATwKAAAAAEACfAQAAAA AAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAPgAAAUAAAAPAATwcgAAABIACvAIAAAAAvgAACACAABT AAvwHgAAAH8AAAAEAIAA8Og0Dr8BAAABAP8BAAABAAEDAgQAAAAAEPAIAAAArQAgAWAVfQMPABHw EAAAAAAAwwsIAAAAAAAAAA0ANA4PAA3wDAAAAAAAng8EAAAAAAAAAA8ABPByAAAAEgAK8AgAAAAD +AAAIAIAAFMAC/AeAAAAfwAAAAQAgAA8XzQOvwEAAAEA/wEAAAEAAQMDBAAAAAAQ8AgAAADwAyAB YBUTDw8AEfAQAAAAAADDCwgAAAABAAAADgA0Dg8ADfAMAAAAAACeDwQAAAABAAAADwAE8EgAAAAS AArwCAAAAAH4AAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAA CAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCI E5EAAAAPAIoTiQAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixNpAAAAAADrLggAAACaAscB MMHMMQAAACsEAAAAAAAAAB8ARPE9AAAAAAAn8SAAAAAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAcxv/ ////EgAAAA8APfENAAAAQAFC8QUAAAABCQAAAA8AAisAAAAADwDuA30CAAACAO8DGAAAAAEAAAAN DgAAAAAAAAAAAIAAAAAABwAUMA8ADASUAQAADwAC8IwBAAAQAwjwCAAAAAMAAAADxAAADwAD8CQB AAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAMQAAAUAAAAPAATwcgAA ABIACvAIAAAAAsQAACACAABTAAvwHgAAAH8AAAAEAIAAyPQ0Dr8BAAABAP8BAAABAAEDAgQAAAAA EPAIAAAArQAgAWAVfQMPABHwEAAAAAAAwwsIAAAAAAAAAA0ANA4PAA3wDAAAAAAAng8EAAAAAAAA AA8ABPByAAAAEgAK8AgAAAADxAAAIAIAAFMAC/AeAAAAfwAAAAQAgAA0zzQOvwEAAAEA/wEAAAEA AQMDBAAAAAAQ8AgAAADwAyABYBUTDw8AEfAQAAAAAADDCwgAAAABAAAADgA0Dg8ADfAMAAAAAACe DwQAAAABAAAADwAE8EgAAAASAArwCAAAAAHEAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6f iwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAC7 4OMAMzOZAACZmQCZzAAADwCIE5EAAAAPAIoTiQAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAA ixNpAAAAAADrLggAAAAOAscB8Gr+2wAAACsEAAAAAAAAAB8ARPE9AAAAAAAn8SAAAAAAAAAAAwAA AAAAAAAAAAAAAAAAAAAAcxv/////EgAAAA8APfENAAAAQAFC8QUAAAABCQAAAA8AAisAAAAADwDw AyQCAAABAPEDCAAAABcBAAAHABQwDwAMBKQBAAAPAALwnAEAANABCPAIAAAAAwAAAAN0AAAPAAPw NAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAAdAAABQAAAA8ABPBk AAAAEgAK8AgAAAACdAAAIAIAAGMAC/AkAAAABAAAAAAAfwAEAAQAvwEBAAEA/wEBAAEAAQMEQAAA iAMAAAAAAAAQ8AgAAADGARgD6A6iCg8AEfAQAAAAAADDCwgAAAAAAAAACwC3DQ8ABPCQAAAAEgAK 8AgAAAADdAAAIAIAAHMAC/AqAAAABAAAAAAAfwAAAAQAgACQHCsOvwEBAAEA/wEBAAEAAQMFQAAA iAMAAAAAAAAQ8AgAAAA5C80BMxDaFQ8AEfAQAAAAAADDCwgAAAABAAAADAC3DQ8ADfAeAAAAAACf DwQAAAACAAAAAACqDwoAAAABAAAAAQAAAAAADwAE8EgAAAASAArwCAAAAAF0AAAADAAAgwAL8DAA AACBAQAAAAiDAQUAAAiTAc63bwCUAX6ZkgC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAA AP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCIEzgAAAAPAIoTMAAAAAAAug8QAAAA XwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAADrLggAAAAjocYBMIozYg8A8AMkAgAAAQDxAwgAAAAi AQAABwAUMA8ADASkAQAADwAC8JwBAACwAgjwCAAAAAMAAAADrAAADwAD8DQBAAAPAATwKAAAAAEA CfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAKwAAAUAAAAPAATwZAAAABIACvAIAAAAAqwA ACACAABjAAvwJAAAAAQAAAAAAH8ABAAEAL8BAQABAP8BAQABAAEDBEAAAIgDAAAAAAAAEPAIAAAA xgEYA+gOogoPABHwEAAAAAAAwwsIAAAAAAAAAAsAtw0PAATwkAAAABIACvAIAAAAA6wAACACAABz AAvwKgAAAAQAAAAAAH8AAAAEAIAA/BJ3Gb8BAQABAP8BAQABAAEDBUAAAIgDAAAAAAAAEPAIAAAA OQvNATMQ2hUPABHwEAAAAAAAwwsIAAAAAQAAAAwAtw0PAA3wHgAAAAAAnw8EAAAAAgAAAAAAqg8K AAAAAQAAAAEAAAAAAA8ABPBIAAAAEgAK8AgAAAABrAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAI kwHOt28AlAF+mZIAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAICAgAAA AAAAu+DjADMzmQAAmZkAmcwAAA8AiBM4AAAADwCKEzAAAAAAALoPEAAAAF8AXwBfAFAAUABUADEA MAAAAIsTEAAAAAAA6y4IAAAAI6HGATCKM2IPAPADJAIAAAEA8QMIAAAAKAEAAAcAFDAPAAwEpAEA AA8AAvCcAQAAQAMI8AgAAAADAAAAA9AAAA8AA/A0AQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAA AAAAAAAAAAACAArwCAAAAADQAAAFAAAADwAE8GQAAAASAArwCAAAAALQAAAgAgAAYwAL8CQAAAAE AAAAAAB/AAQABAC/AQEAAQD/AQEAAQABAwRAAACIAwAAAAAAABDwCAAAAMYBGAPoDqIKDwAR8BAA AAAAAMMLCAAAAAAAAAALALcNDwAE8JAAAAASAArwCAAAAAPQAAAgAgAAcwAL8CoAAAAEAAAAAAB/ AAAABACAAGRyKw6/AQEAAQD/AQEAAQABAwVAAACIAwAAAAAAABDwCAAAADkLzQEzENoVDwAR8BAA AAAAAMMLCAAAAAEAAAAMACsODwAN8B4AAAAAAJ8PBAAAAAIAAAAAAKoPCgAAAAEAAAABAAAAAAAP AATwSAAAABIACvAIAAAAAdAAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBzrdvAJQBfpmSAL8B EgASAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAALvg4wAzM5kAAJmZ AJnMAAAPAIgTOAAAAA8AihMwAAAAAAC6DxAAAABfAF8AXwBQAFAAVAAxADAAAACLExAAAAAAAOsu CAAAACOhxgEwijNiDwDwAyQCAAABAPEDCAAAACoBAAAHABQwDwAMBKQBAAAPAALwnAEAAIADCPAI AAAAAwAAAAPgAAAPAAPwNAEAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgA AAAA4AAABQAAAA8ABPBkAAAAEgAK8AgAAAAC4AAAIAIAAGMAC/AkAAAABAAAAAAAfwAEAAQAvwEB AAEA/wEBAAEAAQMEQAAAiAMAAAAAAAAQ8AgAAADGARgD6A6iCg8AEfAQAAAAAADDCwgAAAAAAAAA CwAqDg8ABPCQAAAAEgAK8AgAAAAD4AAAIAIAAHMAC/AqAAAABAAAAAAAfwAAAAQAgADQPCoOvwEB AAEA/wEBAAEAAQMFQAAAiAMAAAAAAAAQ8AgAAAA5C80BMxDaFQ8AEfAQAAAAAADDCwgAAAABAAAA DAAqDg8ADfAeAAAAAACfDwQAAAACAAAAAACqDwoAAAABAAAAAQAAAAAADwAE8EgAAAASAArwCAAA AAHgAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAc63bwCUAX6ZkgC/ARIAEgD/AQAACAAEAwkA AAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAC74OMAMzOZAACZmQCZzAAADwCIEzgAAAAP AIoTMAAAAAAAug8QAAAAXwBfAF8AUABQAFQAMQAwAAAAixMQAAAAAADrLggAAAAjocYBMIozYg8A 8AMkAgAAAQDxAwgAAAArAQAABwAUMA8ADASkAQAADwAC8JwBAACgAwjwCAAAAAMAAAAD6AAADwAD 8DQBAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAOgAAAUAAAAPAATw ZAAAABIACvAIAAAAAugAACACAABjAAvwJAAAAAQAAAAAAH8ABAAEAL8BAQABAP8BAQABAAEDBEAA AIgDAAAAAAAAEPAIAAAAxgEYA+gOogoPABHwEAAAAAAAwwsIAAAAAAAAAAsAKg4PAATwkAAAABIA CvAIAAAAA+gAACACAABzAAvwKgAAAAQAAAAAAH8AAAAEAIAApEIqDr8BAQABAP8BAQABAAEDBUAA AIgDAAAAAAAAEPAIAAAAOQvNATMQ2hUPABHwEAAAAAAAwwsIAAAAAQAAAAwAKg4PAA3wHgAAAAAA nw8EAAAAAgAAAAAAqg8KAAAAAQAAAAEAAAAAAA8ABPBIAAAAEgAK8AgAAAAB6AAAAAwAAIMAC/Aw AAAAgQEAAAAIgwEFAAAIkwHOt28AlAF+mZIAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAA AAD///8AAAAAAICAgAAAAAAAu+DjADMzmQAAmZkAmcwAAA8AiBM4AAAADwCKEzAAAAAAALoPEAAA AF8AXwBfAFAAUABUADEAMAAAAIsTEAAAAAAA6y4IAAAAI6HGATCKM2IAAHIXlAAAAAEAUAAAAAAA PSAAAEcxAADMMwAA/j0AAAkAEAD0OAAAEAAwAG82AAA3KgAACEMAABQAEACDQAAAGwAQAI1FAAAd ABAAnwkBACYAEACqVwAAKAAwAMsLAQCGagAAC20AACwAQAAaBwEAeTsAAJxvAAD3DQEAMgBAAMmS AAAjEAEA370AAE8SAQA4ACAAAWgAAJUEAQAAAPUPHAAAAAABAABYHwADAAAAAHsUAQABAAAAOwAA AA8AxTEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAFAQIAAAAAAAAAAAAAAAAAAAAAAAEA AADghZ/y+U9oEKuRCAArJ7PZMAAAAPAKAAALAAAAAQAAAGAAAAACAAAAaAAAAAQAAAB4AAAACAAA AJQAAAAJAAAAsAAAABIAAAC8AAAACgAAAOAAAAAMAAAA7AAAAA0AAAD4AAAADwAAAAQBAAARAAAA DAEAAAIAAADkBAAAHgAAAAgAAABORUEgV0cAAB4AAAAUAAAAU3RlcGhlbiBSLiBIYW5uYQAAAAAe AAAAFAAAAFN0ZXBoZW4gUi4gSGFubmEAAAAAHgAAAAQAAAAyNDUAHgAAABwAAABNaWNyb3NvZnQg T2ZmaWNlIFBvd2VyUG9pbnQAQAAAAMAng80MAQAAQAAAAIAICf6t/sYBQAAAAOC/Nu+0AscBAwAA AJ0CAABHAAAA3AkAAP////8DAAAACACJEGcMAAABAAkAAAPmBAAABQBJAAAAAAAEAAAAAwEIAAUA AAALAgAAAAAFAAAADAJ5AKEAAwAAAB4ABwAAAPwCAAD///8AAAAEAAAALQEAAAgAAAD6AgUAAAAA AP///wAEAAAALQEBAA4AAAAkAwUA////////eACgAHgAoAD///////8IAAAA+gIAAAAAAAAAAAAA BAAAAC0BAgAEAAAALQEAAAQAAAAnAf//HAAAAPsC9v8AAAAAAACQAQAAAAAAQAAAQXJpYWwAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEDAAQAAAAuARgABAAAAAIBAQAFAAAACQIAAAAC GAAAADIKHwAwAAsAAABJRVRGIE5FQSBXRwADAAYABwAGAAMABgAHAAcAAwAJAAgABAAAAC4BAAAc AAAA+wIQAAcAAAAAALwCAAAAAAECAiJTeXN0ZW0AAAAAAAAAAAAAGAAAAAEAAADIOxUA5AQAAAQA AAAtAQQABAAAAPABAwAcAAAA+wL5/wAAAAAAAJABAAAAAABAAABBcmlhbAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAQAAAAtAQMABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAI8AAAAMgonABIA IwAAAChORUEgPSBOZXR3b3JrIEVuZHBvaW50IEFzc2Vzc21lbnQp/wIABQAFAAUAAgAEAAIABQAE AAIABQAEAAIAAwACAAUABAAEAAQABAACAAQAAgACAAUABAAEAAMABAAEAAYABAAEAAIAAgAEAAAA LgEAAAQAAAAtAQQABAAAAPABAwAcAAAA+wL5/wAAAAAAAJABAAAAAABAAABBcmlhbAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQMABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAINAAAA MgpLACwABAAAAG5lYVsEAAQABAACAAQAAAAuAQAABAAAAC0BBAAEAAAA8AEDABwAAAD7Avn/AAAA AAAAkAEAAAAAAEAAAEFyaWFsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAC0BAwAEAAAA LgEYAAQAAAACAQEABQAAAAkCAAAAAgkAAAAyCksAOgABAAAALRsCAAQAAAAuAQAABAAAAC0BBAAE AAAA8AEDABwAAAD7Avn/AAAAAAAAkAEAAAAAAEAAAEFyaWFsAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAABAAAAC0BAwAEAAAALgEYAAQAAAACAQEABQAAAAkCAAAAAiEAAAAyCksAPAARAAAAcmVx dWVzdF1AaWV0Zi5vcmdtAgAEAAQABAAEAAQAAgACAAcAAgAEAAIAAgACAAQAAgAEAAQAAAAuAQAA BAAAAC0BBAAEAAAA8AEDABwAAAD7Avz/AAAAAAAAkAEAAAAAAEAAAEFyaWFsAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAABAAAAC0BAwAEAAAALgEYAAQAAAACAQEABQAAAAkCAAAAAhIAAAAyClAA FAAHAAAAQ2hhaXJzOgADAAIAAgACAAEAAgACAAQAAAAuAQAABAAAAC0BBAAEAAAA8AEDABwAAAD7 Avz/AAAAAAAAkAEAAAAAAEAAAEFyaWFsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAC0B AwAEAAAALgEYAAQAAAACAQEABQAAAAkCAAAAAiUAAAAyClAAJAAUAAAAU3RldmUgSGFubmEsIEp1 bmlwZXIDAAEAAgACAAMAAQADAAMAAgADAAIAAQABAAMAAgACAAIAAgADAAIABAAAAC4BAAAEAAAA LQEEAAQAAADwAQMAHAAAAPsC/P8AAAAAAACQAQAAAAAAQAAAQXJpYWwAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAEAAAALQEDAAQAAAAuARgABAAAAAIBAQAFAAAACQIAAAACIgAAADIKUABUABIA AABzaGFubmFAanVuaXBlci5uZXQCAAIAAwACAAMAAgAEAAIAAgACAAEAAwACAAIAAQADAAIAAQAE AAAALgEAAAQAAAAtAQQABAAAAPABAwAcAAAA+wL8/wAAAAAAAJABAAAAAABAAABBcmlhbAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQMABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAAAAIl AAAAMgpVACQAFAAAAFN1c2FuIFRob21zb24sIENpc2NvAwACAAIAAwACAAIAAgACAAMAAwADAAIA AwABAAEAAwABAAIAAwADAAQAAAAuAQAABAAAAC0BBAAEAAAA8AEDABwAAAD7Avz/AAAAAAAAkAEA AAAAAEAAAEFyaWFsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAC0BAwAEAAAALgEYAAQA AAACAQEABQAAAAkCAAAAAiIAAAAyClUAVAASAAAAc2V0aG9tc29AY2lzY28uY29tAgACAAEAAwAD AAMAAgADAAQAAgABAAIAAwACAAEAAwACAAMABAAAAC4BAAAEAAAALQEEAAQAAADwAQMAHAAAAPsC /P8AAAAAAACQAQAAAAAAQAAAQXJpYWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQED AAQAAAAuARgABAAAAAIBAQAFAAAACQIAAAACSQAAADIKYAAWACwAAABJRVRGIDY3LCBUdWVzZGF5 LCBOb3ZlbWJlciA3LCAyMDA2LCAzOjIwIFBNIAEAAwADAAIAAQADAAIAAQACAAIAAwACAAMAAgAC AAMAAQABAAMAAwACAAMAAwADAAIAAQACAAIAAQACAAIAAwACAAIAAgABAAIAAgACAAMAAQADAAMA AgAEAAAALgEAAAQAAAAtAQQABAAAAPABAwAcAAAA+wL8/wAAAAAAAJABAAAAAABAAABBcmlhbAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQMABAAAAC4BGAAEAAAAAgEBAAUAAAAJAgAA AAIJAAAAMgpgAHQAAQAAAJYbAgAEAAAALgEAAAQAAAAtAQQABAAAAPABAwAcAAAA+wL8/wAAAAAA AJABAAAAAABAAABBcmlhbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAAtAQMABAAAAC4B GAAEAAAAAgEBAAUAAAAJAgAAAAISAAAAMgpgAHgABwAAADU6MjAgUE0AAgABAAMAAgABAAQAAwAE AAAALgEAAAQAAAAtAQQABAAAAPABAwADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABQECAAAAAAAAAAAAAAAAAAAAAAABAAAAAtXN1Zwu GxCTlwgAKyz5rjAAAABIAwAAEAAAAAEAAACIAAAAAwAAAJAAAAAPAAAAqAAAAAQAAADIAAAABgAA ANAAAAAHAAAA2AAAAAgAAADgAAAACQAAAOgAAAAKAAAA8AAAABcAAAD4AAAACwAAAAABAAAQAAAA CAEAABMAAAAQAQAAFgAAABgBAAANAAAAIAEAAAwAAADoAgAAAgAAAOQEAAAeAAAAEAAAAE9uLXNj cmVlbiBTaG93AAAeAAAAGAAAAEp1bmlwZXIgTmV0d29ya3MsIEluYy4AAAMAAAA7FQEAAwAAAP8A AAADAAAAEgAAAAMAAAAFAAAAAwAAAAAAAAADAAAAAAAAAAMAAABkHwsACwAAAAAAAAALAAAAAAAA AAsAAAAAAAAACwAAAAAAAAAeEAAAFAAAAAYAAABBcmlhbAAPAAAARGVmYXVsdCBEZXNpZ24AMAAA AElFVEYgTkVBIFdHIChORUEgPSBOZXR3b3JrIEVuZHBvaW50IEFzc2Vzc21lbnQpAA4AAABBZ2Vu ZGEgUmV2aWV3AA8AAABORUEgTWlsZXN0b25lcwAfAAAATkVBIFJvbGVzIGFuZCBSZXNwb25zaWJp bGl0aWVzABAAAABHb2FscyBmb3IgVG9kYXkAGQAAAFJlcXVpcmVtZW50cyBJLUQgT3V0bGluZQAM AAAAVGVybWlub2xvZ3kAEgAAAFByb2JsZW0gU3RhdGVtZW50ABQAAABORUEgUmVmZXJlbmNlIE1v ZGVsABQAAABORUEgUmVmZXJlbmNlIE1vZGVsAAoAAABVc2UgQ2FzZXMADwAAAFR5cGVzIG9mIEZs b3dzABQAAABUeXBlcyBvZiBBdHRyaWJ1dGVzABQAAABFbXBsb3llZSBKb2huIFNtaXRoABMAAABQ cm9mZXNzb3IgSmFuZSBEb2UAEAAAAENvbG9uZWwgTXVzdGFyZAARAAAAT3RoZXIgVXNlIENhc2Vz PwALAAAATmV4dCBTdGVwcwAMEAAABgAAAB4AAAALAAAARm9udHMgVXNlZAADAAAAAQAAAB4AAAAQ AAAARGVzaWduIFRlbXBsYXRlAAMAAAABAAAAHgAAAA0AAABTbGlkZSBUaXRsZXMAAwAAABIAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAD2DygAAAAUAAAAX8CR4xcVAQAQAPQDAwDaMFN0ZXBoZW4gUi4gSGFu bmEIAAAAUwB0AGUAcABoAGUAbgAgAFIALgAgAEgAYQBuAG4AYQAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0A AAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAA ABwAAAAdAAAAHgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAA KgAAACsAAAAsAAAALQAAAC4AAAAvAAAAMAAAADEAAAAyAAAAMwAAADQAAAA1AAAANgAAADcAAAA4 AAAAOQAAADoAAAA7AAAAPAAAAD0AAAA+AAAAPwAAAEAAAABBAAAAQgAAAEMAAABEAAAARQAAAEYA AABHAAAASAAAAEkAAABKAAAASwAAAEwAAABNAAAATgAAAE8AAABQAAAAUQAAAFIAAABTAAAAVAAA AFUAAABWAAAAVwAAAFgAAABZAAAAWgAAAFsAAABcAAAAXQAAAF4AAABfAAAAYAAAAGEAAABiAAAA YwAAAGQAAABlAAAAZgAAAGcAAABoAAAAaQAAAGoAAABrAAAAbAAAAG0AAABuAAAAbwAAAHAAAABx AAAAcgAAAHMAAAB0AAAAdQAAAHYAAAB3AAAAeAAAAHkAAAB6AAAAewAAAHwAAAB9AAAAfgAAAH8A AACAAAAAgQAAAIIAAACDAAAAhAAAAIUAAACGAAAAhwAAAIgAAACJAAAAigAAAP7///+MAAAAjQAA AI4AAACPAAAAkAAAAJEAAACSAAAA/v///5QAAACVAAAAlgAAAJcAAACYAAAAmQAAAJoAAAD+//// nAAAAJ0AAACeAAAAnwAAAKAAAAChAAAAogAAAP7////9/////f///6YAAAD+//////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAFgAFAf//////////AwAAABCNgWSbT88RhuoAqgC5KegAAAAAAAAAAAAAAAAA AAAAAAAAAP7///8AAAAAAAAAAEMAdQByAHIAZQBuAHQAIABVAHMAZQByAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIB////////////////AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAmwAAAAAQAAAAAAAABQBTAHUAbQBtAGEAcgB5AEkAbgBmAG8A cgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgEBAAAA//////////8A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACLAAAAABAAAAAAAABQAG8AdwBlAHIA UABvAGkAbgB0ACAARABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAC AQIAAAAEAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA7FQEA AAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBu AAAAAAAAAAAAAAA4AAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAkwAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAUgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAABYABQH//////////wMAAAAQjYFkm0/PEYbqAKoAuSnoAAAAAAAAAAAAAAAAcDuT 4LUCxwGqAAAAwAMAAAAAAABDAHUAcgByAGUAbgB0ACAAVQBzAGUAcgAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAf///////////////wAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAJsAAAAAEAAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIA bQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIBAQAAAP//////////AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiwAAAAAQAAAAAAAAUABvAHcAZQByAFAA bwBpAG4AdAAgAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgEC AAAABAAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOxUBAAAA AACBAAAAggAAAIMAAACEAAAAhQAAAIYAAACHAAAAiAAAAIkAAACKAAAA/v///4wAAACNAAAAjgAA AI8AAACQAAAAkQAAAJIAAAD+//////////////////////////////////////////////+cAAAA nQAAAJ4AAACfAAAAoAAAAKEAAACiAAAA/v////3///////////////////+sAAAA/f////7///+r AAAA/v////7///////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /wEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAAOAAAA /v////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /v8AAAUBAgAAAAAAAAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQk5cIACss+a5EAAAABdXN1ZwuGxCT lwgAKyz5rowDAABIAwAAEAAAAAEAAACIAAAAAwAAAJAAAAAPAAAAqAAAAAQAAADIAAAABgAAANAA AAAHAAAA2AAAAAgAAADgAAAACQAAAOgAAAAKAAAA8AAAABcAAAD4AAAACwAAAAABAAAQAAAACAEA ABMAAAAQAQAAFgAAABgBAAANAAAAIAEAAAwAAADoAgAAAgAAAOQEAAAeAAAAEAAAAE9uLXNjcmVl biBTaG93AAAeAAAAGAAAAEp1bmlwZXIgTmV0d29ya3MsIEluYy4AAAMAAAA7FQEAAwAAAP8AAAAD AAAAEgAAAAMAAAAFAAAAAwAAAAAAAAADAAAAAAAAAAMAAABkHwsACwAAAAAAAAALAAAAAAAAAAsA AAAAAAAACwAAAAAAAAAeEAAAFAAAAAYAAABBcmlhbAAPAAAARGVmYXVsdCBEZXNpZ24AMAAAAElF VEYgTkVBIFdHIChORUEgPSBOZXR3b3JrIEVuZHBvaW50IEFzc2Vzc21lbnQpAA4AAABBZ2VuZGEg UmV2aWV3AA8AAABORUEgTWlsZXN0b25lcwAfAAAATkVBIFJvbGVzIGFuZCBSZXNwb25zaWJpbGl0 aWVzABAAAABHb2FscyBmb3IgVG9kYXkAGQAAAFJlcXVpcmVtZW50cyBJLUQgT3V0bGluZQAMAAAA VGVybWlub2xvZ3kAEgAAAFByb2JsZW0gU3RhdGVtZW50ABQAAABORUEgUmVmZXJlbmNlIE1vZGVs ABQAAABORUEgUmVmZXJlbmNlIE1vZGVsAAoAAABVc2UgQ2FzZXMADwAAAFR5cGVzIG9mIEZsb3dz ABQAAABUeXBlcyBvZiBBdHRyaWJ1dGVzABQAAABFbXBsb3llZSBKb2huIFNtaXRoABMAAABQcm9m ZXNzb3IgSmFuZSBEb2UAEAAAAENvbG9uZWwgTXVzdGFyZAARAAAAT3RoZXIgVXNlIENhc2VzPwAL AAAATmV4dCBTdGVwcwAMEAAABgAAAB4AAAALAAAARm9udHMgVXNlZAADAAAAAQAAAB4AAAAQAAAA RGVzaWduIFRlbXBsYXRlAAMAAAABAAAAHgAAAA0AAABTbGlkZSBUaXRsZXMAAwAAABIAAAA0AAAA AwAAAAAAAAAgAAAAAQAAACQAAAAAAACALAAAAAAAAAACAAAAsAQAABMAAAAJBAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUA RABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAA AAAAAAA4AAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAMADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ------_=_NextPart_001_01C702B6.BA8AC742 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_01C702B6.BA8AC742-- From nea-bounces@ietf.org Tue Nov 07 17:57:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhZtE-0001gG-Nd; Tue, 07 Nov 2006 17:57:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhZtD-0001di-FQ for nea@ietf.org; Tue, 07 Nov 2006 17:57:55 -0500 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhZtC-0003By-6K for nea@ietf.org; Tue, 07 Nov 2006 17:57:55 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 07 Nov 2006 14:55:04 -0800 X-IronPort-AV: i="4.09,398,1157353200"; d="scan'208"; a="606276899:sNHT92958036" 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] Slides for today's NEA session Date: Tue, 7 Nov 2006 17:57:48 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Slides for today's NEA session Thread-index: AccCteCQci9AzI6MSziYK+P/mnUTgAACbf6g From: "Stephen Hanna" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Sorry for sending that large attachment. I should have sent the URL of the IETF meeting materials web site instead. The slides and agenda are there and the minutes will be posted there later this week. That URL is https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=3D6= 7 I'll try to make up for my goof by supplying some more useful information for remote participants. Streaming audio of the NEA WG session will be available at http://videolab.uoregon.edu/events/ietf during the session. Search for nea and click on the link to the left. For information about jabber (text conferencing), see http://www3.ietf.org/meetings/text_conf.html This will only work if we get a jabber scribe (hint!). Thanks, Steve -----Original Message----- From: Stephen Hanna=20 Sent: Tuesday, November 07, 2006 1:50 PM To: nea@ietf.org Subject: [Nea] Slides for today's NEA session Here are the slides for today's NEA WG session. These will probably be especially useful for remote participants. Thanks, Steve _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Nov 08 20:38:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghyru-0002pY-U6; Wed, 08 Nov 2006 20:38:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ghyrt-0002pN-Ao for nea@ietf.org; Wed, 08 Nov 2006 20:38:13 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ghyrs-0007xs-1J for nea@ietf.org; Wed, 08 Nov 2006 20:38:13 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 08 Nov 2006 17:38:11 -0800 X-IronPort-AV: i="4.09,401,1157353200"; d="scan'208"; a="449225855:sNHT46500256" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id kA91cBVD015168 for ; Wed, 8 Nov 2006 17:38:11 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA91cBAo013636 for ; Wed, 8 Nov 2006 17:38:11 -0800 (PST) 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.1830); Wed, 8 Nov 2006 20:38:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Nov 2006 20:38:16 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Call for volunteers for requirements I-D design team Thread-Index: AccDn7pl35FnEEiyTceO3cCIclkACg== From: "Susan Thomson \(sethomso\)" To: X-OriginalArrivalTime: 09 Nov 2006 01:38:10.0999 (UTC) FILETIME=[B71A5C70:01C7039F] DKIM-Signature: a=rsa-sha1; q=dns; l=548; t=1163036291; x=1163900291; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sethomso@cisco.com; z=From:=22Susan=20Thomson=20\(sethomso\)=22=20 |Subject:Call=20for=20volunteers=20for=20requirements=20I-D=20design=20team; X=v=3Dcisco.com=3B=20h=3DFa4k4fmtAA3gkoBnpaZ8066g1xY=3D; b=bjj9wWjvFsY5mTfJOXMtgD+I9Irki9pe6CIP3S2WcB602d+CnL73a4OhBsmcFYFnV3MWp3gU eUrB490d/qRwocp2rU3p9cWi/RIDpmWqxqWmBD8qyclFgMfjw5hAmJ71; Authentication-Results: sj-dkim-2.cisco.com; header.From=sethomso@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Nea] Call for volunteers for requirements I-D design team 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 the NEA WG meeting yesterday, we proposed forming a small design team to put together drafts of the NEA requirements I-D that can be reviewed by the working group on the mailing list. The effort will involve contributing text to one or more sections of the document and weekly conference calls starting by the end of the month. If you are interested in being a contributor on the design team and have not done so already, please let the chairs know by Nov 16 (shanna@juniper.net, sethomso@cisco.com). Thanks Steve and Susan _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Nov 09 13:32:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiEh6-0003Mc-Ow; Thu, 09 Nov 2006 13:32:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiEh4-0003MV-Tu for nea@ietf.org; Thu, 09 Nov 2006 13:32:06 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiEh3-0002On-MZ for nea@ietf.org; Thu, 09 Nov 2006 13:32:06 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 09 Nov 2006 13:32:04 -0500 X-IronPort-AV: i="4.09,406,1157342400"; d="scan'208"; a="109225705:sNHT5361822086" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id kA9IW3Ru017271; Thu, 9 Nov 2006 13:32:03 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id kA9IW3YJ006703; Thu, 9 Nov 2006 13:32:03 -0500 (EST) 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.1830); Thu, 9 Nov 2006 13:32:03 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 9 Nov 2006 13:32:00 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF67 NEA WG Meeting summary Thread-Index: AccELVhWTnx+V+0kT4GwhokPC5/jug== From: "Susan Thomson \(sethomso\)" To: "Russ Housley" , X-OriginalArrivalTime: 09 Nov 2006 18:32:03.0091 (UTC) FILETIME=[59DAF630:01C7042D] DKIM-Signature: a=rsa-sha1; q=dns; l=949; t=1163097123; x=1163961123; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sethomso@cisco.com; z=From:=22Susan=20Thomson=20\(sethomso\)=22=20 |Subject:IETF67=20NEA=20WG=20Meeting=20summary=20 |Sender: |To:=22Russ=20Housley=22=20, =20; X=v=3Dcisco.com=3B=20h=3D4M5c5dK24rKbzwJTvxLYUGjlKsI=3D; b=QXOXvd3GmSug6G8KrVRKlH71LApiQ7RsMiO2kdvt5jUYWkLT9z75jY3mOqOC5YzS+Zm50EuU qhn4TJMlDVY5MhImqEGyFdZTsZiCIvlnlnhP1iQuWFa2pmTO/xO5JtVH; Authentication-Results: rtp-dkim-2; header.From=sethomso@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: secdir@mit.edu, nea@ietf.org Subject: [Nea] IETF67 NEA WG 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 NEA WG Meeting Summary=20 Tuesday Nov 7 15.20-17.20 1. Discuss formation of NEA WG Requirements I-D The first milestone of the WG is formation of the requirements I-D. To this end, the contents that need to be covered in the Requirements I-D were reviewed along with the proposed reference model. Several use cases were introduced with the goal of driving protocol requirements. =20 The WG also reviewed an individual submission on NEA requirements that had been submitted prior to chartering of the WG. Some material in this document may be used as a start for the WG document with appropriate changes to reflect the approved charter. 2. Next Steps: WG chairs to send call for requirements I-D "design team" volunteers to mailing list (done) Volunteers to send names to WG chairs by Nov 16 WG chairs to select design team by Nov 22 Design team to start con calls week of Nov 27 Post first draft of requirements I-D=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Nov 09 14:02:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiF9x-0004as-Fm; Thu, 09 Nov 2006 14:01:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiF2j-0002HS-DI for nea@ietf.org; Thu, 09 Nov 2006 13:54:29 -0500 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiF2d-0005r1-0q for nea@ietf.org; Thu, 09 Nov 2006 13:54:29 -0500 Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server id 8.0.685.15; Thu, 9 Nov 2006 10:54:22 -0800 Received: from IGT-HUB-01.redmond.corp.microsoft.com ([157.54.69.154]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2786); Thu, 9 Nov 2006 10:54:13 -0800 Received: from TK5-EXHUB-C102.redmond.corp.microsoft.com ([157.54.70.72]) by IGT-HUB-01.redmond.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2786); Thu, 9 Nov 2006 10:54:13 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by TK5-EXHUB-C102.redmond.corp.microsoft.com (157.54.70.72) with Microsoft SMTP Server id 8.0.685.15; Thu, 9 Nov 2006 10:54:12 -0800 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.2786); Thu, 9 Nov 2006 10:54:12 -0800 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] IETF67 NEA WG Meeting summary Date: Thu, 9 Nov 2006 10:53:54 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] IETF67 NEA WG Meeting summary Thread-Index: AccELVhWTnx+V+0kT4GwhokPC5/jugAASznw From: Khaja Ahmed To: "Susan Thomson (sethomso)" , Russ Housley , X-OriginalArrivalTime: 09 Nov 2006 18:54:12.0422 (UTC) FILETIME=[7232C660:01C70430] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 X-Mailman-Approved-At: Thu, 09 Nov 2006 14:01:55 -0500 Cc: secdir@mit.edu, 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 To reiterate a point I made in the meeting, and to prompt some discussion on it... I am not sure what the value is of restricting the charter to solving the problem for enterprises only. The internet includes home networks. Why leave them out? In fact, as the 'Internet' engineering task force, we should ensure that all of the internet can benefit from whatever protocols / solutions we design. =20 I recommend that we add a home user scenario as well. =20 Having discussed this with ISPs like Verizon, SBC, etc, they want to provide nea as a value-add, optional, service to consumers. Consumers benefit, the internet benefits and I suspect the enterprise benefit. It doesn't help to ensure that the enterprise networks are healthy if the internet is slammed because of larger numbers of home users have poorly managed / administered systems. =20 It may be the case what works for enterprises will happen to work for home users getting such services from ISPs but I'd prefer that we make it easier to accomplish this by making it an explicit goal. =20 Khaja -----Original Message----- From: Susan Thomson (sethomso) [mailto:sethomso@cisco.com]=20 Sent: Thursday, November 09, 2006 10:32 AM To: Russ Housley; hartmans-ietf@mit.edu Cc: secdir@mit.edu; nea@ietf.org Subject: [Nea] IETF67 NEA WG Meeting summary=20 NEA WG Meeting Summary=20 Tuesday Nov 7 15.20-17.20 1. Discuss formation of NEA WG Requirements I-D The first milestone of the WG is formation of the requirements I-D. To this end, the contents that need to be covered in the Requirements I-D were reviewed along with the proposed reference model. Several use cases were introduced with the goal of driving protocol requirements. =20 The WG also reviewed an individual submission on NEA requirements that had been submitted prior to chartering of the WG. Some material in this document may be used as a start for the WG document with appropriate changes to reflect the approved charter. 2. Next Steps: WG chairs to send call for requirements I-D "design team" volunteers to mailing list (done) Volunteers to send names to WG chairs by Nov 16 WG chairs to select design team by Nov 22 Design team to start con calls week of Nov 27 Post first draft of requirements I-D=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 Nov 09 14:11:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiFJK-0004CB-15; Thu, 09 Nov 2006 14:11:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiFJJ-0004A8-1G for nea@ietf.org; Thu, 09 Nov 2006 14:11:37 -0500 Received: from outbound-mail.lax.untd.com ([64.136.28.164]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GiFJH-0008LC-Iv for nea@ietf.org; Thu, 09 Nov 2006 14:11:37 -0500 Received: from webmail53.lax.untd.com (webmail53.lax.untd.com [10.131.27.193]) by smtpout08.lax.untd.com with SMTP id AABCXG9LZAAVFM72 for (sender ); Thu, 9 Nov 2006 11:11:19 -0800 (PDT) X-UNTD-OriginStamp: AcganUYbgVGZ0C6nm/9IPatablCmMCeKBq5tWwWNtBusb4qMY6ZWwQ== Received: (from fergdawg@netzero.net) by webmail53.lax.untd.com (jqueuemail) id L6RQ5H5D; Thu, 09 Nov 2006 11:10:44 PST Received: from [130.129.69.175] by webmail53.lax.untd.com with HTTP: Thu, 9 Nov 2006 19:10:17 GMT X-Originating-IP: [130.129.69.175] Mime-Version: 1.0 From: "Fergie" Date: Thu, 9 Nov 2006 19:10:17 GMT To: khaja@windows.microsoft.com Subject: RE: [Nea] IETF67 NEA WG Meeting summary X-Mailer: Webmail Version 4.0 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain Message-Id: <20061109.111044.717.937043@webmail53.lax.untd.com> X-ContentStamp: 18:9:1055186682 X-MAIL-INFO: 2274e08179207095793d1d70595479a4c1f9c93ddda4c54d817999dd1dd1a1259dd0c4d1b985fd71cdc5f4e46510e4cdad25cd0551bda5f9555165e5e9e0c9e5158d592969591471bd0db5e9e940ede4fdd930694961b12064451154d04040e11dd95900c1eda9013195a131411d5079 X-UNTD-Peer-Info: 10.131.27.193|webmail53.lax.untd.com|webmail53.lax.untd.com|fergdawg@netzero.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: hartmans-ietf@mit.edu, secdir@mit.edu, 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 Agreed -- overlooking the consumer market would be a serious oversight, methinks. - ferg -- Khaja Ahmed wrote: To reiterate a point I made in the meeting, and to prompt some discussion on it... I am not sure what the value is of restricting the charter to solving the problem for enterprises only. The internet includes home networks. Why leave them out? In fact, as the 'Internet' engineering task force, we should ensure that all of the internet can benefit from whatever protocols / solutions we design. = I recommend that we add a home user scenario as well. = Having discussed this with ISPs like Verizon, SBC, etc, they want to provide nea as a value-add, optional, service to consumers. Consumers benefit, the internet benefits and I suspect the enterprise benefit. It= doesn't help to ensure that the enterprise networks are healthy if the internet is slammed because of larger numbers of home users have poorly managed / administered systems. = It may be the case what works for enterprises will happen to work for home users getting such services from ISPs but I'd prefer that we make it easier to accomplish this by making it an explicit goal. = Khaja -----Original Message----- From: Susan Thomson (sethomso) [mailto:sethomso@cisco.com] = Sent: Thursday, November 09, 2006 10:32 AM To: Russ Housley; hartmans-ietf@mit.edu Cc: secdir@mit.edu; nea@ietf.org Subject: [Nea] IETF67 NEA WG Meeting summary = NEA WG Meeting Summary = Tuesday Nov 7 15.20-17.20 1. Discuss formation of NEA WG Requirements I-D The first milestone of the WG is formation of the requirements I-D. To this end, the contents that need to be covered in the Requirements I-D were reviewed along with the proposed reference model. Several use cases were introduced with the goal of driving protocol requirements. = The WG also reviewed an individual submission on NEA requirements that had been submitted prior to chartering of the WG. Some material in this document may be used as a start for the WG document with appropriate changes to reflect the approved charter. 2. Next Steps: WG chairs to send call for requirements I-D "design team" volunteers to= mailing list (done) Volunteers to send names to WG chairs by Nov 16 WG chairs to select design team by Nov 22 Design team to start con calls week of Nov 27 Post first draft of requirements I-D = _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Nov 09 15:05:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiG8i-0004iZ-Gv; Thu, 09 Nov 2006 15:04:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiG8h-0004iP-Lc for nea@ietf.org; Thu, 09 Nov 2006 15:04:43 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiG8f-0007tr-Q0 for nea@ietf.org; Thu, 09 Nov 2006 15:04:43 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-1.cisco.com with ESMTP; 09 Nov 2006 12:04:41 -0800 X-IronPort-AV: i="4.09,406,1157353200"; d="scan'208"; a="755517770:sNHT51906636" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id kA9K4eH0019315; Thu, 9 Nov 2006 15:04:40 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id kA9K4eDM019479; Thu, 9 Nov 2006 15:04:40 -0500 (EST) Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Nov 2006 15:04:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] IETF67 NEA WG Meeting summary Date: Thu, 9 Nov 2006 15:04:38 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] IETF67 NEA WG Meeting summary Thread-Index: AccEOD4Bc3nWPvkbQdqElvFqK2kX9AAAF+BA From: "Susan Thomson \(sethomso\)" To: "Fergie" , X-OriginalArrivalTime: 09 Nov 2006 20:04:40.0079 (UTC) FILETIME=[4A1409F0:01C7043A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3197; t=1163102680; x=1163966680; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sethomso@cisco.com; z=From:=20=22Susan=20Thomson=20\(sethomso\)=22=20 |Subject:=20RE=3A=20[Nea]=20IETF67=20NEA=20WG=20Meeting=20summary=20 |Sender:=20 |To:=20=22Fergie=22=20, =20; bh=6lElyS1wol53i3Jhn4/WBy9GXGqUXy9J3AnCyTBvCJo=; b=PERPtbr5qEEaCqpwP8FEmGZ58Tn1kjWRueAa3dJQz9xQ6YYvTDTCYu91MnsjMJ3XPZhiEqUK sRtCYtM1wUWJJryoREke95gkhpzG8lt081yR4XZaUOow8RvnnyqBYc4Y; Authentication-Results: rtp-dkim-1; header.From=sethomso@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: hartmans-ietf@mit.edu, 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 I am removing secdir mailing list from the thread since they should not have been cc'ed in the first place. My mistake. Please keep discussions to this mailing list. Thanks Susan > -----Original Message----- > From: Fergie [mailto:fergdawg@netzero.net]=20 > Sent: Thursday, November 09, 2006 2:10 PM > To: khaja@windows.microsoft.com > Cc: Susan Thomson (sethomso); housley@vigilsec.com;=20 > hartmans-ietf@mit.edu; secdir@mit.edu; nea@ietf.org > Subject: RE: [Nea] IETF67 NEA WG Meeting summary=20 >=20 > Agreed -- overlooking the consumer market would be a serious > oversight, methinks. >=20 > - ferg >=20 >=20 > -- Khaja Ahmed wrote: >=20 > To reiterate a point I made in the meeting, and to prompt some > discussion on it... >=20 > I am not sure what the value is of restricting the charter to solving > the problem for enterprises only. The internet includes home=20 > networks. > Why leave them out? In fact, as the 'Internet' engineering=20 > task force, > we should ensure that all of the internet can benefit from whatever > protocols / solutions we design. =20 >=20 > I recommend that we add a home user scenario as well. =20 >=20 > Having discussed this with ISPs like Verizon, SBC, etc, they want to > provide nea as a value-add, optional, service to consumers. Consumers > benefit, the internet benefits and I suspect the enterprise=20 > benefit. It > doesn't help to ensure that the enterprise networks are healthy if the > internet is slammed because of larger numbers of home users=20 > have poorly > managed / administered systems. =20 >=20 > It may be the case what works for enterprises will happen to work for > home users getting such services from ISPs but I'd prefer that we make > it easier to accomplish this by making it an explicit goal. =20 >=20 >=20 > Khaja >=20 > -----Original Message----- > From: Susan Thomson (sethomso) [mailto:sethomso@cisco.com]=20 > Sent: Thursday, November 09, 2006 10:32 AM > To: Russ Housley; hartmans-ietf@mit.edu > Cc: secdir@mit.edu; nea@ietf.org > Subject: [Nea] IETF67 NEA WG Meeting summary=20 >=20 > NEA WG Meeting Summary=20 > Tuesday Nov 7 15.20-17.20 >=20 > 1. Discuss formation of NEA WG Requirements I-D >=20 > The first milestone of the WG is formation of the requirements I-D. To > this end, the contents that need to be covered in the Requirements I-D > were reviewed along with the proposed reference model. Several use > cases were introduced with the goal of driving protocol=20 > requirements. =20 >=20 > The WG also reviewed an individual submission on NEA requirements that > had been submitted prior to chartering of the WG. Some=20 > material in this > document may be used as a start for the WG document with appropriate > changes to reflect the approved charter. >=20 > 2. Next Steps: >=20 > WG chairs to send call for requirements I-D "design team"=20 > volunteers to > mailing list (done) > Volunteers to send names to WG chairs by Nov 16 > WG chairs to select design team by Nov 22 > Design team to start con calls week of Nov 27 > Post first draft of requirements I-D=20 >=20 >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Nov 09 16:13:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiHDR-0003Wh-KV; Thu, 09 Nov 2006 16:13:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiHCB-0002iQ-IS for nea@ietf.org; Thu, 09 Nov 2006 16:12:23 -0500 Received: from dhcp68-116.ietf67.org ([130.129.68.116] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiHC8-0003Zf-9t for nea@ietf.org; Thu, 09 Nov 2006 16:12:23 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 91753E0035; Thu, 9 Nov 2006 16:12:15 -0500 (EST) From: Sam Hartman To: Khaja Ahmed Subject: Re: [Nea] IETF67 NEA WG Meeting summary References: Date: Thu, 09 Nov 2006 16:12:15 -0500 In-Reply-To: (Khaja Ahmed's message of "Thu, 9 Nov 2006 10:53:54 -0800") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 X-Mailman-Approved-At: Thu, 09 Nov 2006 16:13:40 -0500 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 >>>>> "Khaja" == Khaja Ahmed writes: Khaja> To reiterate a point I made in the meeting, and to prompt Khaja> some discussion on it... Khaja> I am not sure what the value is of restricting the charter Khaja> to solving the problem for enterprises only. The internet Khaja> includes home networks. Why leave them out? In fact, as Khaja> the 'Internet' engineering task force, we should ensure Khaja> that all of the internet can benefit from whatever Khaja> protocols / solutions we design. It seems rather early in the nea working group to be discussing rechartering. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Nov 09 16:21:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiHLK-0000fg-5n; Thu, 09 Nov 2006 16:21:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiHLJ-0000eY-4f for nea@ietf.org; Thu, 09 Nov 2006 16:21:49 -0500 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiHLH-0005LU-S9 for nea@ietf.org; Thu, 09 Nov 2006 16:21:49 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 09 Nov 2006 13:18:56 -0800 X-IronPort-AV: i="4.09,407,1157353200"; d="scan'208"; a="616903188:sNHT41018156" 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] IETF67 NEA WG Meeting summary Date: Thu, 9 Nov 2006 16:21:45 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] IETF67 NEA WG Meeting summary Thread-index: AccEQ/weMJHQG7rbTBWl3Td2dNVJ7gAAFi7Q From: "Stephen Hanna" To: "Sam Hartman" , "Khaja Ahmed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 Agreed. We have an approved charter. That charter explicitly restricts our scope to enterprise environments. There was a lot of discussion on this topic during the chartering of the WG just a few weeks ago. We should not revisit this now. We should focus on our first milestones and work on developing the NEA Requirements I-D. So I'm going to rule further discussion of this topic on the NEA list out of scope at this time. Thanks, Steve -----Original Message----- From: Sam Hartman [mailto:hartmans-ietf@mit.edu]=20 Sent: Thursday, November 09, 2006 1:12 PM To: Khaja Ahmed Cc: nea@ietf.org Subject: Re: [Nea] IETF67 NEA WG Meeting summary >>>>> "Khaja" =3D=3D Khaja Ahmed writes: Khaja> To reiterate a point I made in the meeting, and to prompt Khaja> some discussion on it... Khaja> I am not sure what the value is of restricting the charter Khaja> to solving the problem for enterprises only. The internet Khaja> includes home networks. Why leave them out? In fact, as Khaja> the 'Internet' engineering task force, we should ensure Khaja> that all of the internet can benefit from whatever Khaja> protocols / solutions we design. It seems rather early in the nea working group to be discussing rechartering. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Nov 13 10:00:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjdHW-00083r-PF; Mon, 13 Nov 2006 09:59:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GicbH-0005lz-0a for nea@ietf.org; Fri, 10 Nov 2006 15:03:43 -0500 Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GicbC-00010H-Kl for nea@ietf.org; Fri, 10 Nov 2006 15:03:42 -0500 Received: from tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.685.15; Fri, 10 Nov 2006 12:03:38 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) with Microsoft SMTP Server id 8.0.685.15; Fri, 10 Nov 2006 12:03:37 -0800 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.2786); Fri, 10 Nov 2006 12:03:37 -0800 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] IETF67 NEA WG Meeting summary Date: Fri, 10 Nov 2006 12:02:51 -0800 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] IETF67 NEA WG Meeting summary Thread-Index: AccEQ/weMJHQG7rbTBWl3Td2dNVJ7gAAFi7QAC+zA4A= References: From: Khaja Ahmed To: Stephen Hanna , Sam Hartman X-OriginalArrivalTime: 10 Nov 2006 20:03:37.0150 (UTC) FILETIME=[4EFB95E0:01C70503] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 X-Mailman-Approved-At: Mon, 13 Nov 2006 09:59:29 -0500 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 OK. As we go into the work of defining the actual protocol if we feel that the solutions is hobbled because of the charter we can reconsider then. I am fine with wait and see if is necessary. I do have a question for the ADs: In your experience is it better to revise charter later in the game, when there is a tangible evidence that the limits of the charter are causing design decisions that are sub-optimal? ...or it better to do it early in the game when not too much has been done and we are starting on a relatively clean slate? I am hoping it is the former - that is why I am agreeable to the wait and see if necessary approach, but I'd like to know. =20 Khaja -----Original Message----- From: Stephen Hanna [mailto:shanna@juniper.net]=20 Sent: Thursday, November 09, 2006 1:22 PM To: Sam Hartman; Khaja Ahmed Cc: nea@ietf.org Subject: RE: [Nea] IETF67 NEA WG Meeting summary Agreed. We have an approved charter. That charter explicitly restricts our scope to enterprise environments. There was a lot of discussion on this topic during the chartering of the WG just a few weeks ago. We should not revisit this now. We should focus on our first milestones and work on developing the NEA Requirements I-D. So I'm going to rule further discussion of this topic on the NEA list out of scope at this time. Thanks, Steve -----Original Message----- From: Sam Hartman [mailto:hartmans-ietf@mit.edu]=20 Sent: Thursday, November 09, 2006 1:12 PM To: Khaja Ahmed Cc: nea@ietf.org Subject: Re: [Nea] IETF67 NEA WG Meeting summary >>>>> "Khaja" =3D=3D Khaja Ahmed writes: Khaja> To reiterate a point I made in the meeting, and to prompt Khaja> some discussion on it... Khaja> I am not sure what the value is of restricting the charter Khaja> to solving the problem for enterprises only. The internet Khaja> includes home networks. Why leave them out? In fact, as Khaja> the 'Internet' engineering task force, we should ensure Khaja> that all of the internet can benefit from whatever Khaja> protocols / solutions we design. It seems rather early in the nea working group to be discussing rechartering. _______________________________________________ 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 Mon Nov 13 16:20:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjjEP-0008UZ-6V; Mon, 13 Nov 2006 16:20:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjjEN-0008UR-Pb for nea@ietf.org; Mon, 13 Nov 2006 16:20:40 -0500 Received: from woodstock.binhost.com ([66.150.120.2]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GjjEM-0002VJ-H7 for nea@ietf.org; Mon, 13 Nov 2006 16:20:39 -0500 Received: (qmail 11032 invoked by uid 0); 13 Nov 2006 21:20:31 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.246.224.121) by woodstock.binhost.com with SMTP; 13 Nov 2006 21:20:31 -0000 Message-Id: <7.0.0.16.2.20061113155728.08426410@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Mon, 13 Nov 2006 15:59:03 -0500 To: Khaja Ahmed , Stephen Hanna , Sam Hartman From: Russ Housley Subject: RE: [Nea] IETF67 NEA WG Meeting summary In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 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 At this point, only bad things can happen by asking for a charter revision. In my opinion, you need to deliver on the existing charter milestones before asking for any additional latitude. Russ At 03:02 PM 11/10/2006, Khaja Ahmed wrote: >OK. As we go into the work of defining the actual protocol if we feel >that the solutions is hobbled because of the charter we can reconsider >then. I am fine with wait and see if is necessary. > >I do have a question for the ADs: In your experience is it better to >revise charter later in the game, when there is a tangible evidence that >the limits of the charter are causing design decisions that are >sub-optimal? ...or it better to do it early in the game when not too >much has been done and we are starting on a relatively clean slate? I >am hoping it is the former - that is why I am agreeable to the wait and >see if necessary approach, but I'd like to know. > >Khaja > > >-----Original Message----- >From: Stephen Hanna [mailto:shanna@juniper.net] >Sent: Thursday, November 09, 2006 1:22 PM >To: Sam Hartman; Khaja Ahmed >Cc: nea@ietf.org >Subject: RE: [Nea] IETF67 NEA WG Meeting summary > >Agreed. We have an approved charter. That charter explicitly restricts >our scope to enterprise environments. There was a lot of discussion on >this topic during the chartering of the WG just a few weeks ago. We >should >not revisit this now. We should focus on our first milestones and work >on >developing the NEA Requirements I-D. So I'm going to rule further >discussion >of this topic on the NEA list out of scope at this time. > >Thanks, > >Steve > >-----Original Message----- >From: Sam Hartman [mailto:hartmans-ietf@mit.edu] >Sent: Thursday, November 09, 2006 1:12 PM >To: Khaja Ahmed >Cc: nea@ietf.org >Subject: Re: [Nea] IETF67 NEA WG Meeting summary > > >>>>> "Khaja" == Khaja Ahmed writes: > > Khaja> To reiterate a point I made in the meeting, and to prompt > Khaja> some discussion on it... > > Khaja> I am not sure what the value is of restricting the charter > Khaja> to solving the problem for enterprises only. The internet > Khaja> includes home networks. Why leave them out? In fact, as > Khaja> the 'Internet' engineering task force, we should ensure > Khaja> that all of the internet can benefit from whatever > Khaja> protocols / solutions we design. > >It seems rather early in the nea working group to be discussing >rechartering. > >_______________________________________________ >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 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Nov 13 16:53:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjjk6-000502-Nz; Mon, 13 Nov 2006 16:53:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjjk5-0004zv-Bv for nea@ietf.org; Mon, 13 Nov 2006 16:53:25 -0500 Received: from ka.cs.utk.edu ([160.36.56.221]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjjk4-0006h9-1S for nea@ietf.org; Mon, 13 Nov 2006 16:53:25 -0500 Received: from localhost (localhost [127.0.0.1]) by ka.cs.utk.edu (Postfix) with ESMTP id 9D2752F257; Mon, 13 Nov 2006 16:54:24 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from ka.cs.utk.edu ([127.0.0.1]) by localhost (ka.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnOdG-iPlyXA; Mon, 13 Nov 2006 16:54:16 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by ka.cs.utk.edu (Postfix) with ESMTP id 33B692F260; Mon, 13 Nov 2006 16:54:14 -0500 (EST) Message-ID: <4558E94C.4000203@cs.utk.edu> Date: Mon, 13 Nov 2006 16:53:16 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Russ Housley Subject: Re: [Nea] IETF67 NEA WG Meeting summary References: <7.0.0.16.2.20061113155728.08426410@vigilsec.com> In-Reply-To: <7.0.0.16.2.20061113155728.08426410@vigilsec.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: nea@ietf.org, Khaja Ahmed , Sam Hartman 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 my opinion, you need to deliver on the existing charter milestones > before asking for any additional latitude. my opinion is somewhat stronger than that. IMHO, you're going to need to resolve the conflict between the user's desire for privacy and the network operator's desire to spy on end systems, before you can accomplish much in this area. depending on how you interpret the charter, that might or might not fit, but I think it would be reasonable to do this work as part of developing requirements and security considerations. (however, I don't claim to be able to interpret the charter authoritatively, that's up to the ADs.) if it can't take place as part of this WG's discussion, so be it, but it needs to be done somehow regardless. for lots of reasons, it's not sufficient to say that this technology is only for use by enterprise networks where they own all of the computers that attach to them. one reason is that this is an increasingly small corner case, as very many employees and visitors need to attach to enterprise networks. another is that there are too many incentives for other kinds of networks to spy on end systems and to demand the ability to do so if the tools become commonly available. I honestly don't see why this work is any different in principle than wiretapping, and why RFC 1984 doesn't apply here to some extent. leaf networks aren't inherently more benign than governments. Keith p.s. I think it might actually be possible to resolve this conflict, though I can't quite see how to do it. Offhand the best idea I have looks something like this: - networks cannot query hosts for fine-grained attributes. instead, networks can advertise their policies in detail. the most that the network gets back when querying a host is a yes (does conform), no (does not conform), or "no answer" (not willing to tell you whether it conforms). - hosts report any details of policy conflicts to their owners, according to the software configuration. hosts must not report any details in response to the query by the network. it should be up to the owner to take corrective action. of course, the owner might be the same as the network administrator, but then again, it might not be. - the protocol limits the frequency with which policies can be changed and policy queries can be made, to prevent this being used as a probing mechanism to find out details of the host's configuration. either that or the protocol specification has other mechanisms to limit the ability of the network to use the protocol to probe host configuration. - predicates that are part of network-specified policies probably do have to be standardized. either that or the network has to be able to specify separate policies for each NEA host software package, which pretty much defeats the purpose of standardization. - it should be possible for a host to reconfigure itself to suit the whims of the network to which it attaches. so rather than saying "I don't conform to your policy" because it has software X installed, it should be able to say "I do conform to your policy" as long as software X is not part of the virtual host image that talks to that network interface. Like I say, this is a rough idea, thrown out in the hope that it can be improved on rather than shot down. It's easy to shoot things down, harder to take a rough idea and make it a good one. Of course if it's totally unworkable it does need to be shot down. But offhand it looks more promising as a path to a compromise than saying (for instance) "hosts can lie". Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Nov 13 17:15:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjk5e-00079X-Dz; Mon, 13 Nov 2006 17:15:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjk5d-00078w-Oy for nea@ietf.org; Mon, 13 Nov 2006 17:15:41 -0500 Received: from newgiles.striker.ottawa.on.ca ([205.150.200.131] helo=mail.nitros9.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjk5b-00019B-Fi for nea@ietf.org; Mon, 13 Nov 2006 17:15:41 -0500 Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 674AE16CBC; Mon, 13 Nov 2006 17:05:43 -0500 (EST) From: "Alan DeKok" To: Keith Moore Subject: Re: [Nea] IETF67 NEA WG Meeting summary In-Reply-To: Your message of "Mon, 13 Nov 2006 16:53:16 EST." <4558E94C.4000203@cs.utk.edu> Date: Mon, 13 Nov 2006 17:05:43 -0500 Message-Id: <20061113220543.674AE16CBC@mail.nitros9.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 Keith Moore wrote: > I honestly don't see why this work is any different in principle than > wiretapping, and why RFC 1984 doesn't apply here to some extent. leaf > networks aren't inherently more benign than governments. Pretty much, yes. > p.s. I think it might actually be possible to resolve this conflict, > though I can't quite see how to do it. Offhand the best idea I have > looks something like this: I think there are many ways to approach the NEA requirements without implementing the full set of NEA protocols on all of the NEA actors. Since we assume that pretty much anything can be spoofed or duplicated, many of the attacks on non-intrusive posture assesment methods are also applicable to NEA. And those non-intrusive methods can be implemented using existing software, without requiring new protocols. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Nov 14 01:16:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjras-00062E-I5; Tue, 14 Nov 2006 01:16:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjrap-0005pp-0n for nea@ietf.org; Tue, 14 Nov 2006 01:16:23 -0500 Received: from bes.cs.utk.edu ([160.36.56.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjram-00028b-Q6 for nea@ietf.org; Tue, 14 Nov 2006 01:16:23 -0500 Received: from localhost (localhost [127.0.0.1]) by bes.cs.utk.edu (Postfix) with ESMTP id DB707FD68; Tue, 14 Nov 2006 01:16:19 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from bes.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wzWtVr03rmKV; Tue, 14 Nov 2006 01:16:14 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by bes.cs.utk.edu (Postfix) with ESMTP id 9A008FD65; Tue, 14 Nov 2006 01:16:12 -0500 (EST) Message-ID: <45595F33.3070707@cs.utk.edu> Date: Tue, 14 Nov 2006 01:16:19 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Alan DeKok Subject: Re: [Nea] IETF67 NEA WG Meeting summary References: <20061113220543.674AE16CBC@mail.nitros9.org> In-Reply-To: <20061113220543.674AE16CBC@mail.nitros9.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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 > I think there are many ways to approach the NEA requirements without > implementing the full set of NEA protocols on all of the NEA actors. > Since we assume that pretty much anything can be spoofed or > duplicated, many of the attacks on non-intrusive posture assesment > methods are also applicable to NEA. And those non-intrusive methods > can be implemented using existing software, without requiring new > protocols. to me NEA seems pointless unless the responses are signed. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Nov 14 01:37:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjruj-0006yX-62; Tue, 14 Nov 2006 01:36:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjruh-0006yN-6e for nea@ietf.org; Tue, 14 Nov 2006 01:36:55 -0500 Received: from a.mail.sonic.net ([64.142.16.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjruf-0004oP-RP for nea@ietf.org; Tue, 14 Nov 2006 01:36:55 -0500 Received: from [192.168.2.11] (64-142-13-68.dsl.static.sonic.net [64.142.13.68]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id kAE6aj43016767 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 13 Nov 2006 22:36:45 -0800 Subject: Re: [Nea] IETF67 NEA WG Meeting summary From: Douglas Otis To: Keith Moore In-Reply-To: <45595F33.3070707@cs.utk.edu> References: <20061113220543.674AE16CBC@mail.nitros9.org> <45595F33.3070707@cs.utk.edu> Content-Type: text/plain Date: Mon, 13 Nov 2006 22:36:44 -0800 Message-Id: <1163486205.24789.148.camel@bash.adsl-64-142-13-68> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 On Tue, 2006-11-14 at 01:16 -0500, Keith Moore wrote: > > I think there are many ways to approach the NEA requirements without > > implementing the full set of NEA protocols on all of the NEA actors. > > Since we assume that pretty much anything can be spoofed or > > duplicated, many of the attacks on non-intrusive posture assesment > > methods are also applicable to NEA. And those non-intrusive methods > > can be implemented using existing software, without requiring new > > protocols. > > to me NEA seems pointless unless the responses are signed. The responses could be certificates signed by a third-party service. The affirmative answer would be a time-stamp of the service event still considered valid by the server. This service might have a certificate exchange layer wrapped around an update mechanism, for example. The NEA server could indicate required services by exchanging sets of certificates using a hostmaster identifier. The client would need to offer one certificate with their identifier for each set. There could also be a set of optional services, that the client may wish to make use of when recommended by their provider. Each certificate would indicate the provider of the service and the required resources needed for the service. This resource information could enable the relaxation of network rules designed to protect both the client and the network itself. -Doug _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Nov 14 01:42:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjs0S-0002zW-9L; Tue, 14 Nov 2006 01:42:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjs0R-0002zR-4x for nea@ietf.org; Tue, 14 Nov 2006 01:42:51 -0500 Received: from bes.cs.utk.edu ([160.36.56.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjs0O-0005eg-U2 for nea@ietf.org; Tue, 14 Nov 2006 01:42:51 -0500 Received: from localhost (localhost [127.0.0.1]) by bes.cs.utk.edu (Postfix) with ESMTP id 0AB38FD49; Tue, 14 Nov 2006 01:42:48 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from bes.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTja6Xj9Us1T; Tue, 14 Nov 2006 01:42:42 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by bes.cs.utk.edu (Postfix) with ESMTP id 6F0CFFD3C; Tue, 14 Nov 2006 01:42:42 -0500 (EST) Message-ID: <45596568.2020401@cs.utk.edu> Date: Tue, 14 Nov 2006 01:42:48 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Douglas Otis Subject: Re: [Nea] IETF67 NEA WG Meeting summary References: <20061113220543.674AE16CBC@mail.nitros9.org> <45595F33.3070707@cs.utk.edu> <1163486205.24789.148.camel@bash.adsl-64-142-13-68> In-Reply-To: <1163486205.24789.148.camel@bash.adsl-64-142-13-68> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 >> to me NEA seems pointless unless the responses are signed. > > The responses could be certificates signed by a third-party service. > The affirmative answer would be a time-stamp of the service event still > considered valid by the server. This service might have a certificate > exchange layer wrapped around an update mechanism, for example. the third-party service is an interesting idea if it can be used to hide details of my configuration from the network while still certifying to the network that my configuration is (within broad terms) okay. still, I'm not sure I'd trust any third-party to know precisely what is on my machine and not misuse that information or disclose it to parties with whom I don't want to share it. I'm certain that I wouldn't trust an antivirus software vendor, for instance, with that information - because widespread investment of this kind of trust in a few such vendors would make them very tempting targets for some kinds of espionage. > The NEA server could indicate required services by exchanging sets of > certificates using a hostmaster identifier. The client would need to > offer one certificate with their identifier for each set. this seems too intrusive to me. I don't want a network to know precisely which services I have installed on my machine. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Nov 14 01:58:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjsFx-0002qU-Pp; Tue, 14 Nov 2006 01:58:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjsFw-0002p0-6g for nea@ietf.org; Tue, 14 Nov 2006 01:58:52 -0500 Received: from 124-254-74-144-static-dsl.ispone.net.au ([124.254.74.144] helo=oscar.sleepycat.com.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjsFt-00085s-Cv for nea@ietf.org; Tue, 14 Nov 2006 01:58:52 -0500 Received: from 124-254-82-173-static-dsl.ispone.net.au ([124.254.82.173] helo=dhs) by oscar.sleepycat.com.au with smtp (Exim 4.62) (envelope-from ) id 1GjsFf-00024i-5h for nea@ietf.org; Tue, 14 Nov 2006 17:58:37 +1100 Received: (qmail 7147 invoked by uid 453); 14 Nov 2006 06:58:23 -0000 X-Spam-Status: No, hits=0.0 required=5.0 tests= X-Spam-Check-By: dhs Received: from pc-00008.dhs (HELO speedy) (192.168.0.8) by dhs (qpsmtpd/0.31.1) with ESMTP; Tue, 14 Nov 2006 17:58:09 +1100 From: "Darryl \(Dassa\) Lynch" To: Subject: RE: [Nea] IETF67 NEA WG Meeting summary Date: Tue, 14 Nov 2006 17:58:07 +1100 Organization: DHS International Pty Ltd MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <45596568.2020401@cs.utk.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 thread-index: AccHuB55HZkkCBM+Qy2gUgjpQaXhoQAAaHVw X-Spam-Score: 0.5 (/) X-Spam-Report: Spam detection software, running on the system "oscar.sleepycat.com.au", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Keith Moore wrote: >>>> to me NEA seems pointless unless the responses are signed. >>> >>> The responses could be certificates signed by a third-party service. >>> The affirmative answer would be a time-stamp of the service event >>> still considered valid by the server. This service might have a >>> certificate exchange layer wrapped around an update mechanism, for >>> example. >> >> the third-party service is an interesting idea if it can be >> used to hide details of my configuration from the network >> while still certifying to the network that my configuration >> is (within broad terms) okay. still, I'm not sure I'd trust >> any third-party to know precisely what is on my machine and >> not misuse that information or disclose it to parties with >> whom I don't want to share it. I'm certain that I wouldn't >> trust an antivirus software vendor, for instance, with that >> information - because widespread investment of this kind of >> trust in a few such vendors would make them very tempting >> targets for some kinds of espionage. >> >>> The NEA server could indicate required services by exchanging sets >>> of certificates using a hostmaster identifier. The client would >>> need to offer one certificate with their identifier for each set. >> >> this seems too intrusive to me. I don't want a network to >> know precisely which services I have installed on my machine. [...] Content analysis details: (0.5 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.5 DNS_FROM_RFC_ABUSE RBL: Envelope sender in abuse.rfc-ignorant.org 1.4 DNS_FROM_RFC_POST RBL: Envelope sender in postmaster.rfc-ignorant.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dassa@dhs.org List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Message-Id: Keith Moore wrote: >>>> to me NEA seems pointless unless the responses are signed. >>> >>> The responses could be certificates signed by a third-party service. >>> The affirmative answer would be a time-stamp of the service event >>> still considered valid by the server. This service might have a >>> certificate exchange layer wrapped around an update mechanism, for >>> example. >> >> the third-party service is an interesting idea if it can be >> used to hide details of my configuration from the network >> while still certifying to the network that my configuration >> is (within broad terms) okay. still, I'm not sure I'd trust >> any third-party to know precisely what is on my machine and >> not misuse that information or disclose it to parties with >> whom I don't want to share it. I'm certain that I wouldn't >> trust an antivirus software vendor, for instance, with that >> information - because widespread investment of this kind of >> trust in a few such vendors would make them very tempting >> targets for some kinds of espionage. >> >>> The NEA server could indicate required services by exchanging sets >>> of certificates using a hostmaster identifier. The client would >>> need to offer one certificate with their identifier for each set. >> >> this seems too intrusive to me. I don't want a network to >> know precisely which services I have installed on my machine. Couldn't the solution be as simple as allowing the client nodes the option of deciding what information they are prepared to make available and the network then using what is available to decide how they should be treated? If not enough information is provided the node can be shunted off for some form of remediation, if the network deems it has enough information then the node can be allowed in. Both parties have choices then, what information to provide and what is required to be accepted. Darryl (Dassa) Lynch _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Nov 14 02:15:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjsVR-0002Cf-MU; Tue, 14 Nov 2006 02:14:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjsVQ-0002CH-Li for nea@ietf.org; Tue, 14 Nov 2006 02:14:52 -0500 Received: from outbound-mail.lax.untd.com ([64.136.28.164]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GjsVM-00024T-BO for nea@ietf.org; Tue, 14 Nov 2006 02:14:50 -0500 Received: from webmail45.lax.untd.com (webmail45.lax.untd.com [10.131.27.185]) by smtpout03.lax.untd.com with SMTP id AABCXU5GCAGCZ39A for (sender ); Mon, 13 Nov 2006 23:14:10 -0800 (PDT) X-UNTD-OriginStamp: AcganUYbgVGZ0C6nm/9IPatablCmMCeK2ZK475VEEPXAc/7i5tjqUQ== Received: (from fergdawg@netzero.net) by webmail45.lax.untd.com (jqueuemail) id L65B27KQ; Mon, 13 Nov 2006 23:13:09 PST Received: from [24.23.201.115] by webmail45.lax.untd.com with HTTP: Tue, 14 Nov 2006 07:12:54 GMT X-Originating-IP: [24.23.201.115] Mime-Version: 1.0 From: "Fergie" Date: Tue, 14 Nov 2006 07:12:54 GMT To: dassa@dhs.org Subject: RE: [Nea] IETF67 NEA WG Meeting summary X-Mailer: Webmail Version 4.0 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain Message-Id: <20061113.231309.16672.1448311@webmail45.lax.untd.com> X-ContentStamp: 13:6:2402448978 X-MAIL-INFO: 1634d1a5d494d19494cd34446484b1f5f579b4edf5f989648d091d3ddd5050d151b599a5 X-UNTD-Peer-Info: 10.131.27.185|webmail45.lax.untd.com|webmail45.lax.untd.com|fergdawg@netzero.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 -- "Darryl \(Dassa\) Lynch" wrote: >Couldn't the solution be as simple as allowing the client nodes the opt= ion >of deciding what information they are prepared to make available and th= e >network then using what is available to decide how they should be treat= ed? >If not enough information is provided the node can be shunted off for s= ome >form of remediation, if the network deems it has enough information then the >node can be allowed in. > >Both parties have choices then, what information to provide and what is= >required to be accepted. = > It is my understanding from the WG charter that a primary benefit of NEA is that an administrative entity should be able to determine the posture of an end-system without the end-systems consent (of course, there may indeed be reasons why the opposite would be true, too). It would seem to me that if the end-system has the ability to nullify that ability, then NEA would be pretty worthless. In any event, the charter says: "The PB (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." Having read that, it would appear the issue of assessing posture is one that is done between the the Posture Validator(s) and the Posture Broker (where Posture attributes are aggregated), not the NEA end-system (client) directly. - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Nov 14 08:07:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjy0M-0002lF-H6; Tue, 14 Nov 2006 08:07:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjsxr-0000EY-18 for nea@ietf.org; Tue, 14 Nov 2006 02:44:15 -0500 Received: from mail3.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjsuh-0005qP-I1 for nea@ietf.org; Tue, 14 Nov 2006 02:41:02 -0500 Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.685.15; Mon, 13 Nov 2006 23:40:58 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) with Microsoft SMTP Server id 8.0.685.15; Mon, 13 Nov 2006 23:40:58 -0800 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.2786); Mon, 13 Nov 2006 23:40:58 -0800 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] IETF67 NEA WG Meeting summary Date: Mon, 13 Nov 2006 23:40:04 -0800 Message-ID: In-Reply-To: <20061113.231309.16672.1448311@webmail45.lax.untd.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] IETF67 NEA WG Meeting summary Thread-Index: AccHvK9B3oyXaHvAT2KT21jXJapsQgAAKioA From: Khaja Ahmed To: Fergie , X-OriginalArrivalTime: 14 Nov 2006 07:40:58.0682 (UTC) FILETIME=[39B7F1A0:01C707C0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 X-Mailman-Approved-At: Tue, 14 Nov 2006 08:07:08 -0500 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 It seems certain that access to the network, at least from some ISPs, will be conditional upon providing health information. That is the prerogative of the ISP. =20 Users who do not want to provide ISPs information about their OS, patch level, AV used, etc. will have to use ISPs who do not require this. =20 Khaja -----Original Message----- From: Fergie [mailto:fergdawg@netzero.net]=20 Sent: Monday, November 13, 2006 11:13 PM To: dassa@dhs.org Cc: nea@ietf.org Subject: RE: [Nea] IETF67 NEA WG Meeting summary -- "Darryl \(Dassa\) Lynch" wrote: >Couldn't the solution be as simple as allowing the client nodes the option >of deciding what information they are prepared to make available and the >network then using what is available to decide how they should be treated? >If not enough information is provided the node can be shunted off for some >form of remediation, if the network deems it has enough information then the >node can be allowed in. > >Both parties have choices then, what information to provide and what is >required to be accepted. =20 > It is my understanding from the WG charter that a primary benefit of NEA is that an administrative entity should be able to determine the posture of an end-system without the end-systems consent (of course, there may indeed be reasons why the opposite would be true, too). It would seem to me that if the end-system has the ability to nullify that ability, then NEA would be pretty worthless. In any event, the charter says: "The PB (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." Having read that, it would appear the issue of assessing posture is one that is done between the the Posture Validator(s) and the Posture Broker (where Posture attributes are aggregated), not the NEA end-system (client) directly. - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ _______________________________________________ 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 Tue Nov 14 08:07:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjy0M-0002lA-CE; Tue, 14 Nov 2006 08:07:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjsxh-00005F-O5 for nea@ietf.org; Tue, 14 Nov 2006 02:44:05 -0500 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjswh-00061W-P9 for nea@ietf.org; Tue, 14 Nov 2006 02:43:05 -0500 Received: from tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.0.685.15; Mon, 13 Nov 2006 23:43:03 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk1-exhub-c101.redmond.corp.microsoft.com (157.56.116.111) with Microsoft SMTP Server id 8.0.685.15; Mon, 13 Nov 2006 23:43:02 -0800 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.2786); Mon, 13 Nov 2006 23:43:02 -0800 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: FW: [Nea] IETF67 NEA WG Meeting summary Date: Mon, 13 Nov 2006 23:42:45 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] IETF67 NEA WG Meeting summary Thread-Index: AccHvK9B3oyXaHvAT2KT21jXJapsQgAAKioAAADF3VA= From: Khaja Ahmed To: X-OriginalArrivalTime: 14 Nov 2006 07:43:02.0368 (UTC) FILETIME=[8370EE00:01C707C0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 X-Mailman-Approved-At: Tue, 14 Nov 2006 08:07:08 -0500 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 -----Original Message----- From: Khaja Ahmed=20 Sent: Monday, November 13, 2006 11:40 PM To: Fergie; dassa@dhs.org Cc: nea@ietf.org Subject: RE: [Nea] IETF67 NEA WG Meeting summary It seems certain that access to the network, at least from some ISPs, will be conditional upon providing health information. That is the prerogative of the ISP. =20 Users who do not want to provide ISPs information about their OS, patch level, AV used, etc. will have to use ISPs who do not require this. =20 Khaja -----Original Message----- From: Fergie [mailto:fergdawg@netzero.net]=20 Sent: Monday, November 13, 2006 11:13 PM To: dassa@dhs.org Cc: nea@ietf.org Subject: RE: [Nea] IETF67 NEA WG Meeting summary -- "Darryl \(Dassa\) Lynch" wrote: >Couldn't the solution be as simple as allowing the client nodes the option >of deciding what information they are prepared to make available and the >network then using what is available to decide how they should be treated? >If not enough information is provided the node can be shunted off for some >form of remediation, if the network deems it has enough information then the >node can be allowed in. > >Both parties have choices then, what information to provide and what is >required to be accepted. =20 > It is my understanding from the WG charter that a primary benefit of NEA is that an administrative entity should be able to determine the posture of an end-system without the end-systems consent (of course, there may indeed be reasons why the opposite would be true, too). It would seem to me that if the end-system has the ability to nullify that ability, then NEA would be pretty worthless. In any event, the charter says: "The PB (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." Having read that, it would appear the issue of assessing posture is one that is done between the the Posture Validator(s) and the Posture Broker (where Posture attributes are aggregated), not the NEA end-system (client) directly. - ferg -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ _______________________________________________ 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 Tue Nov 14 08:55:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjyl0-000361-4S; Tue, 14 Nov 2006 08:55:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjykz-00035w-F5 for nea@ietf.org; Tue, 14 Nov 2006 08:55:21 -0500 Received: from mga03.intel.com ([143.182.124.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjyky-00066w-08 for nea@ietf.org; Tue, 14 Nov 2006 08:55:21 -0500 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by mga03.intel.com with ESMTP; 14 Nov 2006 05:55:17 -0800 Received: from fmsmsx333.amr.corp.intel.com ([132.233.42.2]) by azsmga001.ch.intel.com with ESMTP; 14 Nov 2006 05:55:16 -0800 X-ExtLoop1: 1 X-IronPort-AV: i="4.09,420,1157353200"; d="scan'208"; a="145974970:sNHT20512317" Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx333.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 05:55:17 -0800 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] IETF67 NEA WG Meeting summary Date: Tue, 14 Nov 2006 08:55:08 -0500 Message-ID: <279DDDAFA85EC74C9300A0598E704056F32DA5@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] IETF67 NEA WG Meeting summary thread-index: AccHuCBafjWtV4OhTEuHYSQ6NQTabwAOpjyA From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 14 Nov 2006 13:55:17.0309 (UTC) FILETIME=[841A76D0:01C707F4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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 >>> to me NEA seems pointless unless the responses are signed. In one word - yes. =20 >> The responses could be certificates signed by a third-party service. >> The affirmative answer would be a time-stamp of the service event still >> considered valid by the server. This service might have a certificate >> exchange layer wrapped around an update mechanism, for example. > >the third-party service is an interesting idea if it can be used to hide=20 >details of my configuration from the network while still certifying to=20 >the network that my configuration is (within broad terms) okay. =20 It certainly can. However if it's an enterprise-belongin computer that seeks a network admission - why would you prefer to disclose your configuration to a third party over your "native" corporate IT? Understanding that if ever such a third party evolves, it will certainly be bound by legal agreements to disclose whatever "violations" of whatever policy it discovers? >still,=20 >I'm not sure I'd trust any third-party to know precisely what is on my=20 >machine and not misuse that information or disclose it to parties with=20 >whom I don't want to share it. =20 That's a good question. Who is it that you know you don't want to share the info with? Your employer? Your government? Your ISP? And who is it that you don't mind sharing your "internal details" with? Somebody like VeriSign? IRS? In a corporate environment, it's a reasonably clear cut. IT "o3ns" the machines, and has both the legal right and the burning desire to know what exactly is going on on them. NEA will help them know more prior to even letting the machine on the intranet. Outside of the corporate - it becomes really interesting. >I'm certain that I wouldn't trust an antivirus software vendor, >for instance, with that information - because widespread=20 >investment of this kind of trust in a few such vendors would=20 >make them very tempting targets for some kinds of espionage. OK, OK - but much more important question is who you WOULD trust! Can you think of such a party? >> The NEA server could indicate required services by exchanging sets of >> certificates using a hostmaster identifier. The client would need to >> offer one certificate with their identifier for each set. > >this seems too intrusive to me. I don't want a network to know=20 >precisely which services I have installed on my machine. I can reasonably imagine a set of "prohibited" services and a set of "required" services, whose corresponding absence and presence is to be ascertained. I'm sure that corporate IT would indeed want to know more - like "all the installed services". _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Nov 14 08:58:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjyoP-00045H-4Z; Tue, 14 Nov 2006 08:58:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjyoN-00045C-Io for nea@ietf.org; Tue, 14 Nov 2006 08:58:51 -0500 Received: from mga02.intel.com ([134.134.136.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjyoM-0006Uj-7M for nea@ietf.org; Tue, 14 Nov 2006 08:58:51 -0500 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by mga02.intel.com with ESMTP; 14 Nov 2006 05:58:47 -0800 Received: from fmsmsx334.amr.corp.intel.com ([132.233.42.1]) by orsmga001.jf.intel.com with ESMTP; 14 Nov 2006 05:58:46 -0800 X-ExtLoop1: 1 X-IronPort-AV: i="4.09,420,1157353200"; d="scan'208"; a="161242630:sNHT19695459" Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx334.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 05:58:46 -0800 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] IETF67 NEA WG Meeting summary Date: Tue, 14 Nov 2006 08:58:36 -0500 Message-ID: <279DDDAFA85EC74C9300A0598E704056F32DB0@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] IETF67 NEA WG Meeting summary thread-index: AccHvK0rWXSKZ9KbSVqorTOoNUGCwQAN/FQA From: "Blumenthal, Uri" To: "Fergie" , X-OriginalArrivalTime: 14 Nov 2006 13:58:46.0491 (UTC) FILETIME=[00C91AB0:01C707F5] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 >>Both parties have choices then, what information to provide and what is >>required to be accepted. =20 > > >It is my understanding from the WG charter that a primary benefit >of NEA is that an administrative entity should be able to determine >the posture of an end-system without the end-systems consent (of >course, there may indeed be reasons why the opposite would be true, >too). > >It would seem to me that if the end-system has the ability to >nullify that ability, then NEA would be pretty worthless. It's like Social Security numbers in USA. You may withhold your SSN when you request a loan from a bank. In which case the bank will exercise its rigth to reject your loan application. :-) _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Nov 14 09:25:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjzEY-0008B8-S4; Tue, 14 Nov 2006 09:25:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjzEX-00087i-3t for nea@ietf.org; Tue, 14 Nov 2006 09:25:53 -0500 Received: from zcars04f.nortel.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjzEU-0001dm-Qc for nea@ietf.org; Tue, 14 Nov 2006 09:25:53 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id kAEEP9E09566; Tue, 14 Nov 2006 09:25:09 -0500 (EST) Received: from [47.248.126.240] ([47.248.126.240] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 09:24:51 -0500 Message-ID: <4559D1C0.6030604@nortel.com> Date: Tue, 14 Nov 2006 08:25:04 -0600 From: "Marcus Leech" User-Agent: Thunderbird 1.5.0.8 (X11/20061107) MIME-Version: 1.0 To: Khaja Ahmed Subject: Re: [Nea] IETF67 NEA WG Meeting summary References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Nov 2006 14:24:51.0669 (UTC) FILETIME=[A5B45050:01C707F8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 Khaja Ahmed wrote: > It seems certain that access to the network, at least from some ISPs, > will be conditional upon providing health information. That is the > prerogative of the ISP. > > Users who do not want to provide ISPs information about their OS, patch > level, AV used, etc. will have to use ISPs who do not require this. > > Khaja > > For any such ISP, I'd simply assert to them that I'm running whatever OS it is that doesn't require "anti virus configuration". I imagine that ISPs that adopt such policy will let various Linux and Unix machines to "sail right through", which means there'll be tools for Windows boxes to make them appear to be Linux machines, precisely to get around draconian and ill-considered policies of the ISPs. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Nov 14 09:30:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjzJC-0003Ks-EY; Tue, 14 Nov 2006 09:30:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjzJB-0003Km-0e for nea@ietf.org; Tue, 14 Nov 2006 09:30:41 -0500 Received: from zcars04e.nortel.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjzJ9-00029i-Ny for nea@ietf.org; Tue, 14 Nov 2006 09:30:40 -0500 Received: from zcarhxs1.corp.nortel.com (zcarhxs1.corp.nortel.com [47.129.230.89]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id kAEENOq14655; Tue, 14 Nov 2006 09:23:25 -0500 (EST) Received: from [47.248.126.240] ([47.248.126.240] RDNS failed) by zcarhxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 09:30:15 -0500 Message-ID: <4559D30D.8050407@nortel.com> Date: Tue, 14 Nov 2006 08:30:37 -0600 From: "Marcus Leech" User-Agent: Thunderbird 1.5.0.8 (X11/20061107) MIME-Version: 1.0 To: "Blumenthal, Uri" , nea@ietf.org Subject: Re: [Nea] IETF67 NEA WG Meeting summary References: <279DDDAFA85EC74C9300A0598E704056F32DA5@hdsmsx412.amr.corp.intel.com> In-Reply-To: <279DDDAFA85EC74C9300A0598E704056F32DA5@hdsmsx412.amr.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Nov 2006 14:30:15.0596 (UTC) FILETIME=[66C7A6C0:01C707F9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 Blumenthal, Uri wrote: > > I can reasonably imagine a set of "prohibited" services and a set of > "required" services, whose corresponding absence and presence is to be > ascertained. I'm sure that corporate IT would indeed want to know more - > like "all the installed services". > > Services like "make" and "gcc" would be considered "prohibited" in some environments. Dangerous tools, those... The problem is that as the draconian measures become more intrusive, the motivation to get around them becomes greater and greater. I expect this to turn into a "spy vs spy" game, in the same way that SPAM and DRM have grown into a "spy vs spy" game. There's no endgame. Turing Completeness is the enemy of all NEA/TCG-like efforts. I would assert that useful computing devices that are without Turing Completeness, are not useful computing devices. But removing TC-ness is the only conceivable way of short-circuiting the "spy vs spy" nature of the problem at hand... _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Nov 14 09:33:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjzLO-0005Dr-Pb; Tue, 14 Nov 2006 09:32:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjzLN-0005Dm-Ls for nea@ietf.org; Tue, 14 Nov 2006 09:32:57 -0500 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjzLM-0002Uk-DE for nea@ietf.org; Tue, 14 Nov 2006 09:32:57 -0500 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 8D767564BA; Tue, 14 Nov 2006 09:32:55 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+0eUmv6opBy; Tue, 14 Nov 2006 09:32:46 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 01A29564B3; Tue, 14 Nov 2006 09:32:41 -0500 (EST) Message-ID: <4559D390.9080405@cs.utk.edu> Date: Tue, 14 Nov 2006 09:32:48 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: dassa@dhs.org Subject: Re: [Nea] IETF67 NEA WG Meeting summary References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 > Couldn't the solution be as simple as allowing the client nodes the option > of deciding what information they are prepared to make available and the > network then using what is available to decide how they should be treated? I really don't think so. The problem is with giving the network a way to interrogate the host in detail. > If not enough information is provided the node can be shunted off for some > form of remediation, if the network deems it has enough information then the > node can be allowed in. > > Both parties have choices then, what information to provide and what is > required to be accepted. say you want to attend a conference, like IETF. but before we let you in the building where the conference is held we want to make sure you're okay. so we're going to lock you in a room with an interrogator and he's going to ask you an arbitrary number of arbitrary questions - maybe about your sex life, drug use, whatever. you're free to refuse to answer any question, but your failure to answer might determine whether we let you in or shunt you off for some form of remediation. after all, you have nothing to hide, right? while we're at it, maybe we should examine your laptop too. maybe you have kiddie porn on there somewhere, maybe you have illegal mp3 files (despite the fact that we can't tell whether or not you have a license for such files - we'll decide for ourselves whether they're illegal or not). maybe you have open source software. that's bad enough - you never know what those guys will put in there. maybe you have p2p file sharing software - you must be a pirate! maybe you've even written some software of your own. we certainly don't want to trust that. I'm not joking. there are people who would use this mechanism to do all kinds of invasive searches. there are people in the us congress who would see nothing wrong with having networks search computers for "illegal" or "subversive" content if the mechanisms to do so were already in place. it's simply not acceptable to standardize a mechanism that can be used to do invasive searches of a computer. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Nov 14 09:34:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjzMP-0005bX-FO; Tue, 14 Nov 2006 09:34:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjzMO-0005bQ-Cf for nea@ietf.org; Tue, 14 Nov 2006 09:34:00 -0500 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjzMM-0002cR-69 for nea@ietf.org; Tue, 14 Nov 2006 09:34:00 -0500 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 52430564BE; Tue, 14 Nov 2006 09:33:57 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YP0AetPgQPQc; Tue, 14 Nov 2006 09:33:46 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 37695564A9; Tue, 14 Nov 2006 09:33:46 -0500 (EST) Message-ID: <4559D3D0.6070104@cs.utk.edu> Date: Tue, 14 Nov 2006 09:33:52 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Fergie Subject: Re: [Nea] IETF67 NEA WG Meeting summary References: <20061113.231309.16672.1448311@webmail45.lax.untd.com> In-Reply-To: <20061113.231309.16672.1448311@webmail45.lax.untd.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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 > It is my understanding from the WG charter that a primary benefit > of NEA is that an administrative entity should be able to determine > the posture of an end-system without the end-systems consent (of > course, there may indeed be reasons why the opposite would be true, > too). well, that's completely unacceptable. affirmative consent is a necessary condition, though not a sufficient one. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Nov 14 09:35:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjzNe-0006HP-Ge; Tue, 14 Nov 2006 09:35:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjzNd-0006H7-8H for nea@ietf.org; Tue, 14 Nov 2006 09:35:17 -0500 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjzNc-0002oe-1x for nea@ietf.org; Tue, 14 Nov 2006 09:35:17 -0500 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 6B00D564BD; Tue, 14 Nov 2006 09:35:15 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-pYrsqnjbRO; Tue, 14 Nov 2006 09:35:08 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 23EB8564BA; Tue, 14 Nov 2006 09:35:07 -0500 (EST) Message-ID: <4559D422.60206@cs.utk.edu> Date: Tue, 14 Nov 2006 09:35:14 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Khaja Ahmed Subject: Re: [Nea] IETF67 NEA WG Meeting summary References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 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 > It seems certain that access to the network, at least from some ISPs, > will be conditional upon providing health information. That is the > prerogative of the ISP. perhaps, but nothing says that IETF has to be a party to such nonsense by standardizing a mechanism to let them do so. remember, in IETF we're required to make decisions as to what is best for the internet as a whole, not to give ISPs whatever they want. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Nov 14 09:53:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjzfS-0004kv-96; Tue, 14 Nov 2006 09:53:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjzfQ-0004kF-Fr for nea@ietf.org; Tue, 14 Nov 2006 09:53:40 -0500 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjzfP-0005Z7-6j for nea@ietf.org; Tue, 14 Nov 2006 09:53:40 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 14 Nov 2006 06:50:43 -0800 X-IronPort-AV: i="4.09,421,1157353200"; d="scan'208"; a="619515415:sNHT42021248" 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] IETF67 NEA WG Meeting summary Date: Tue, 14 Nov 2006 09:53:36 -0500 Message-ID: In-Reply-To: <4559D422.60206@cs.utk.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] IETF67 NEA WG Meeting summary Thread-index: AccH+idfvnAIZilVTjaE24qC5EwnsgAAJasQ From: "Stephen Hanna" To: "Keith Moore" , "Khaja Ahmed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 I think we're drifting back into charter discussion. The IETF has already chartered a group to standardize a mechanism to "assess the "posture" of endpoint devices for the purposes of monitoring compliance to an organization's posture policy and optionally restricting access until the endpoint has been updated to satisfy the posture requirements". That's NEA. Instead of debating whether IETF should do this, let's redirect the discussion to how the assessment can address privacy and other concerns. For instance, I think it is better for the NEA server to request specific attributes than for the NEA client to simply send all the info it has. Also, the NEA server should authenticate itself to the NEA client before the NEA client is asked to send attributes. Keith, would such a system address your concerns at all? If not, can you suggest some approaches that would? Thanks, Steve -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu]=20 Sent: Tuesday, November 14, 2006 8:35 AM To: Khaja Ahmed Cc: nea@ietf.org Subject: Re: [Nea] IETF67 NEA WG Meeting summary > It seems certain that access to the network, at least from some ISPs, > will be conditional upon providing health information. That is the > prerogative of the ISP. =20 perhaps, but nothing says that IETF has to be a party to such nonsense=20 by standardizing a mechanism to let them do so. remember, in IETF we're required to make decisions as to what is best=20 for the internet as a whole, not to give ISPs whatever they want. _______________________________________________ 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 Tue Nov 14 09:56:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjziR-0005wh-PK; Tue, 14 Nov 2006 09:56:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjziQ-0005sg-I8 for nea@ietf.org; Tue, 14 Nov 2006 09:56:46 -0500 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjziP-00061n-97 for nea@ietf.org; Tue, 14 Nov 2006 09:56:46 -0500 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id D84DB564A0; Tue, 14 Nov 2006 09:56:44 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FeXO2rlvRBy; Tue, 14 Nov 2006 09:56:37 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 35D3056476; Tue, 14 Nov 2006 09:56:36 -0500 (EST) Message-ID: <4559D92A.20507@cs.utk.edu> Date: Tue, 14 Nov 2006 09:56:42 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: "Blumenthal, Uri" Subject: Re: [Nea] IETF67 NEA WG Meeting summary References: <279DDDAFA85EC74C9300A0598E704056F32DA5@hdsmsx412.amr.corp.intel.com> In-Reply-To: <279DDDAFA85EC74C9300A0598E704056F32DA5@hdsmsx412.amr.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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 >> the third-party service is an interesting idea if it can be used to hide >> details of my configuration from the network while still certifying to >> the network that my configuration is (within broad terms) okay. > > It certainly can. However if it's an enterprise-belongin computer that > seeks a network admission - why would you prefer to disclose your > configuration to a third party over your "native" corporate IT? that's a corner case. a more general case is that the computer belongs to someone (maybe an enterprise, maybe not) and it probably connects to multiple networks, only one or two of which are owned by the same party that owns the computer. the protocol has to do the right thing no matter which network the computer is connected to. > Understanding that if ever such a third party evolves, it will certainly > be bound by legal agreements to disclose whatever "violations" of > whatever policy it discovers? right - the third party might be required by a government, for instance, to look for things it considers illegal and subversive. that's why I'm skeptical of the viability of third parties. > That's a good question. Who is it that you know you don't want to share > the info with? Your employer? Your government? Your ISP? And who is it > that you don't mind sharing your "internal details" with? Somebody like > VeriSign? IRS? all good examples. > In a corporate environment, it's a reasonably clear cut. IT "o3ns" the > machines not necessarily. I know of companies that require their employees to buy their own laptops, but they still insist on controlling the configurations of those machines if they attach to the network. >> I'm certain that I wouldn't trust an antivirus software vendor, >> for instance, with that information - because widespread >> investment of this kind of trust in a few such vendors would >> make them very tempting targets for some kinds of espionage. > > OK, OK - but much more important question is who you WOULD trust! Can > you think of such a party? offhand, no. >>> The NEA server could indicate required services by exchanging sets of >>> certificates using a hostmaster identifier. The client would need to >>> offer one certificate with their identifier for each set. >> this seems too intrusive to me. I don't want a network to know >> precisely which services I have installed on my machine. > > I can reasonably imagine a set of "prohibited" services and a set of > "required" services, whose corresponding absence and presence is to be > ascertained. I'm sure that corporate IT would indeed want to know more - > like "all the installed services". I'm sure they would. I'm also sure that it's not acceptable to give it to them. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Nov 14 10:01:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjzn4-0007zg-UP; Tue, 14 Nov 2006 10:01:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjzn3-0007za-OQ for nea@ietf.org; Tue, 14 Nov 2006 10:01:33 -0500 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjzn2-00075A-Er for nea@ietf.org; Tue, 14 Nov 2006 10:01:33 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 14 Nov 2006 06:58:36 -0800 X-IronPort-AV: i="4.09,421,1157353200"; d="scan'208"; a="609499432:sNHT44990272" 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] IETF67 NEA WG Meeting summary Date: Tue, 14 Nov 2006 10:01:28 -0500 Message-ID: In-Reply-To: <4559D30D.8050407@nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] IETF67 NEA WG Meeting summary Thread-index: AccH+YZUyDvlGmNETZuZ3Woqi9fwSwAAz3pQ From: "Stephen Hanna" To: "Marcus Leech" , "Blumenthal, Uri" , 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 I'm afraid that our charter says "Detecting or handling [lying] endpoints is out of scope of the NEA WG." A brief mention of this topic is OK but we shouldn't spend too much time on it, especially since the topic was thrashed over only last month during our chartering discussion. Clearly, there are differing opinions about whether technology for detecting or handling lying endpoints is feasible or desirable. But in either case, it's out of scope for NEA. We are supposed to "focus on attributes useful for assessing posture of those endpoints reporting accurate information." That is, we're supposed to focus on helping healthy endpoints stay healthy. Thanks, Steve -----Original Message----- From: Marcus Leech [mailto:mleech@nortel.com]=20 Sent: Tuesday, November 14, 2006 8:31 AM To: Blumenthal, Uri; nea@ietf.org Subject: Re: [Nea] IETF67 NEA WG Meeting summary Blumenthal, Uri wrote: > > I can reasonably imagine a set of "prohibited" services and a set of > "required" services, whose corresponding absence and presence is to be > ascertained. I'm sure that corporate IT would indeed want to know more - > like "all the installed services". > > =20 Services like "make" and "gcc" would be considered "prohibited" in some=20 environments. Dangerous tools, those... The problem is that as the draconian measures become more intrusive, the motivation to get around them becomes greater and greater. I expect this to turn into a "spy=20 vs spy" game, in the same way that SPAM and DRM have grown into a "spy vs spy" game. There's no=20 endgame. Turing Completeness is the enemy of all NEA/TCG-like efforts. I would=20 assert that useful computing devices that are without Turing Completeness, are not useful computing devices. But removing TC-ness is the only conceivable way of short-circuiting the "spy vs=20 spy" nature of the problem at hand... _______________________________________________ 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 Tue Nov 14 10:01:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjzmw-0007xP-Pi; Tue, 14 Nov 2006 10:01:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjzmu-0007xH-NJ for nea@ietf.org; Tue, 14 Nov 2006 10:01:24 -0500 Received: from is1.enterasys.com ([63.160.138.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjzmp-00072u-Fc for nea@ietf.org; Tue, 14 Nov 2006 10:01:24 -0500 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe2.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 10:01:18 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] IETF67 NEA WG Meeting summary Date: Tue, 14 Nov 2006 10:01:18 -0500 Message-ID: <3CFB564E055A594B82C4FE89D21565605A49B4@MABOSEVS2.ets.enterasys.com> In-Reply-To: <4559D422.60206@cs.utk.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] IETF67 NEA WG Meeting summary Thread-Index: AccH+iZz7b+5zccWTdmokLmotq2/+wAAdmZw From: "Nelson, David" To: X-OriginalArrivalTime: 14 Nov 2006 15:01:18.0667 (UTC) FILETIME=[BD41B9B0:01C707FD] X-imss-version: 2.043 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 Keith Moore writes... > remember, in IETF we're required to make decisions as to > what is best for the internet as a whole, not to give ISPs=20 > whatever they want. This thread seems to be a "Layer 9" discussion about the threat that NEA might pose to personal freedom. Interesting, on a philosophical level, but not helpful in moving the WG toward its charter goals, I think. There is a reason why NEA was targeted at enterprise environments. In the workplace your personal freedoms are somewhat limited. What you do with corporate assets, on the corporate premises, on corporate time and in contact with fellow employees, is much more subject to regulation by your employer than your behavior in public or at home. I infer from your e-mail address that you may possibly work in an environment in which "academic freedom" is at play. Such notions don't translate very well to the commercial work place. In terms of the intrusiveness of NEA protocols and agents, I can only say that they are no more intrusive than SMS (MS System Management Services) the IT "Big Brother" application that my company uses to keep tabs on my laptop. So, I think we should understand that there *is* a valid set of use cases for NEA, within the scope defined by the charter, and get on with the business of the WG. The fact that ISPs might "abuse" these protocols is not a reason to abstain from standardizing them, IMHO. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Nov 14 10:02:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjzoE-0008NF-0j; Tue, 14 Nov 2006 10:02:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjzoC-0008MA-Ls for nea@ietf.org; Tue, 14 Nov 2006 10:02:44 -0500 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjzoB-0007Gc-Eo for nea@ietf.org; Tue, 14 Nov 2006 10:02:44 -0500 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 4865456482; Tue, 14 Nov 2006 10:02:42 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGzmHn5nEiDD; Tue, 14 Nov 2006 10:02:36 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id A36BA564B3; Tue, 14 Nov 2006 10:02:34 -0500 (EST) Message-ID: <4559DA90.6090507@cs.utk.edu> Date: Tue, 14 Nov 2006 10:02:40 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Stephen Hanna Subject: Re: [Nea] IETF67 NEA WG Meeting summary References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Khaja Ahmed , 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 > I think we're drifting back into charter discussion. > The IETF has already chartered a group to standardize > a mechanism to "assess the "posture" of endpoint devices > for the purposes of monitoring compliance to an organization's > posture policy and optionally restricting access until the > endpoint has been updated to satisfy the posture requirements". > That's NEA. uh, no.. the IETF has chartered a group to develop requirements for such a mechanism, not the mechanism itself. the current discussion is entirely relevant to developing requirements. > Instead of debating whether IETF should do this, let's > redirect the discussion to how the assessment can address > privacy and other concerns. For instance, I think it is > better for the NEA server to request specific attributes than > for the NEA client to simply send all the info it has. Also, > the NEA server should authenticate itself to the NEA client > before the NEA client is asked to send attributes. > > Keith, would such a system address your concerns at all? for reasons already given, no. > If not, can you suggest some approaches that would? I don't actually know if there is a reasonable way to do what NEA wants to do, but I've already suggested one alternative that might be worthy of exploration - which is to NOT let the network ask questions about multiple specific attributes, but to only let it present a set of requirements and let the host tell it whether it meets those requirements. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Nov 14 10:05:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjzqq-0000Pj-4H; Tue, 14 Nov 2006 10:05:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjzqp-0000Pb-3X for nea@ietf.org; Tue, 14 Nov 2006 10:05:27 -0500 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gjzqn-0007dF-P7 for nea@ietf.org; Tue, 14 Nov 2006 10:05:27 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 14 Nov 2006 07:02:29 -0800 X-IronPort-AV: i="4.09,421,1157353200"; d="scan'208"; a="609500849:sNHT50844616" 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] IETF67 NEA WG Meeting summary Date: Tue, 14 Nov 2006 10:05:17 -0500 Message-ID: In-Reply-To: <4559D92A.20507@cs.utk.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] IETF67 NEA WG Meeting summary Thread-index: AccH/SZdNDF0FktJRmKZ2fvQE9RpUAAANLeQ From: "Stephen Hanna" To: "Keith Moore" , "Blumenthal, Uri" X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 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 I seem to be Mr. Charter these days. Our charter says "NEA is applicable to computing enterprise environments, where endpoints accessing the enterprise's network are owned and/or expected to conform to the policies set forth by the organization that owns and operates the network. All other cases are outside the scope of the NEA charter, since we do not know that NEA would be useful in such cases." So the corporate environment described by Uri is not a corner case. It's the only case we're allowed to consider. Let's stop talking about fascist governments and such. We must focus on a corporate environment where endpoints are owned by or expect to conform to the policies set forth by the network owner. Thanks, Steve -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu]=20 Sent: Tuesday, November 14, 2006 8:57 AM To: Blumenthal, Uri Cc: nea@ietf.org Subject: Re: [Nea] IETF67 NEA WG Meeting summary >> the third-party service is an interesting idea if it can be used to hide=20 >> details of my configuration from the network while still certifying to=20 >> the network that my configuration is (within broad terms) okay. =20 >=20 > It certainly can. However if it's an enterprise-belongin computer that > seeks a network admission - why would you prefer to disclose your > configuration to a third party over your "native" corporate IT? that's a corner case. a more general case is that the computer belongs=20 to someone (maybe an enterprise, maybe not) and it probably connects to=20 multiple networks, only one or two of which are owned by the same party=20 that owns the computer. the protocol has to do the right thing no=20 matter which network the computer is connected to. > Understanding that if ever such a third party evolves, it will certainly > be bound by legal agreements to disclose whatever "violations" of > whatever policy it discovers? right - the third party might be required by a government, for instance, to look for things it considers illegal and subversive. that's why I'm=20 skeptical of the viability of third parties. > That's a good question. Who is it that you know you don't want to share > the info with? Your employer? Your government? Your ISP? And who is it > that you don't mind sharing your "internal details" with? Somebody like > VeriSign? IRS? all good examples. > In a corporate environment, it's a reasonably clear cut. IT "o3ns" the > machines not necessarily. I know of companies that require their employees to=20 buy their own laptops, but they still insist on controlling the=20 configurations of those machines if they attach to the network. >> I'm certain that I wouldn't trust an antivirus software vendor, >> for instance, with that information - because widespread=20 >> investment of this kind of trust in a few such vendors would=20 >> make them very tempting targets for some kinds of espionage. >=20 > OK, OK - but much more important question is who you WOULD trust! Can > you think of such a party? offhand, no. >>> The NEA server could indicate required services by exchanging sets of >>> certificates using a hostmaster identifier. The client would need to >>> offer one certificate with their identifier for each set. >> this seems too intrusive to me. I don't want a network to know=20 >> precisely which services I have installed on my machine. >=20 > I can reasonably imagine a set of "prohibited" services and a set of > "required" services, whose corresponding absence and presence is to be > ascertained. I'm sure that corporate IT would indeed want to know more - > like "all the installed services". I'm sure they would. I'm also sure that it's not acceptable to give it=20 to them. Keith _______________________________________________ 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 Tue Nov 14 10:11:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjzwH-0004Et-QX; Tue, 14 Nov 2006 10:11:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GjzwG-0004EO-9e for nea@ietf.org; Tue, 14 Nov 2006 10:11:04 -0500 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjzwF-0008Si-0j for nea@ietf.org; Tue, 14 Nov 2006 10:11:04 -0500 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id B54AF564A9; Tue, 14 Nov 2006 10:11:02 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8t9MB3xT791N; Tue, 14 Nov 2006 10:10:55 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id E1F83564A0; Tue, 14 Nov 2006 10:10:50 -0500 (EST) Message-ID: <4559DC81.9000305@cs.utk.edu> Date: Tue, 14 Nov 2006 10:10:57 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: "Nelson, David" Subject: Re: [Nea] IETF67 NEA WG Meeting summary References: <3CFB564E055A594B82C4FE89D21565605A49B4@MABOSEVS2.ets.enterasys.com> In-Reply-To: <3CFB564E055A594B82C4FE89D21565605A49B4@MABOSEVS2.ets.enterasys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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 >> remember, in IETF we're required to make decisions as to >> what is best for the internet as a whole, not to give ISPs >> whatever they want. > > This thread seems to be a "Layer 9" discussion about the threat that NEA > might pose to personal freedom. Interesting, on a philosophical level, > but not helpful in moving the WG toward its charter goals, I think. strongly disagree. the charter is for the WG to develop requirements for the NEA protocol. those requirements necessarily include security considerations. and the discussion has to be conducted according to IETF rules. > There is a reason why NEA was targeted at enterprise environments. In > the workplace your personal freedoms are somewhat limited. What you do > with corporate assets, on the corporate premises, on corporate time and > in contact with fellow employees, is much more subject to regulation by > your employer than your behavior in public or at home. when the same computers are plugged into multiple environments, it hardly matters. even if you accept that the enterprise network can ask anything it wants of its own computers, it is necessary that the NEA protocol not be a security risk to the host when that host connects to other networks. > I infer from your e-mail address that you may possibly work in an > environment in which "academic freedom" is at play. Such notions don't > translate very well to the commercial work place. IETF protocols need to work for the whole internet, not just corner cases. > In terms of the intrusiveness of NEA protocols and agents, I can only > say that they are no more intrusive than SMS (MS System Management > Services) the IT "Big Brother" application that my company uses to keep > tabs on my laptop. yes there are lots of bad things in the world. the fact that they exist does not compel IETF to standardize them. > So, I think we should understand that there *is* a valid set of use > cases for NEA, within the scope defined by the charter, and get on with > the business of the WG. The fact that ISPs might "abuse" these > protocols is not a reason to abstain from standardizing them, IMHO. again, strongly disagree. the introduction of NEA to a host presents a security risk to that host and to its owner. it's entirely appropriate and necessary to discuss ways of ameliorating those security risks, and to evaluate whether NEA can be done at all in such a way that does not create greater risks than the risks it is itself trying to ameliorate. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Nov 14 10:12:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjzxc-0004dJ-2c; Tue, 14 Nov 2006 10:12:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gjzxb-0004bt-5o for nea@ietf.org; Tue, 14 Nov 2006 10:12:27 -0500 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GjzxZ-0000Fq-Vw for nea@ietf.org; Tue, 14 Nov 2006 10:12:27 -0500 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id D9EDC56498; Tue, 14 Nov 2006 10:12:24 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvO0E6pMoC1f; Tue, 14 Nov 2006 10:12:15 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id B7620564A8; Tue, 14 Nov 2006 10:12:11 -0500 (EST) Message-ID: <4559DCD2.3070103@cs.utk.edu> Date: Tue, 14 Nov 2006 10:12:18 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Stephen Hanna Subject: Re: [Nea] IETF67 NEA WG Meeting summary References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db 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 > I'm afraid that our charter says "Detecting or handling [lying] > endpoints is out of scope of the NEA WG." I fail to see what this has to do with Uri's message. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Nov 14 10:20:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk05P-00074p-61; Tue, 14 Nov 2006 10:20:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk05O-000725-A7 for nea@ietf.org; Tue, 14 Nov 2006 10:20:30 -0500 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk05N-0001Bk-2i for nea@ietf.org; Tue, 14 Nov 2006 10:20:30 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 14 Nov 2006 07:17:33 -0800 X-IronPort-AV: i="4.09,421,1157353200"; d="scan'208"; a="609507088:sNHT35829024" 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] IETF67 NEA WG Meeting summary Date: Tue, 14 Nov 2006 10:20:23 -0500 Message-ID: In-Reply-To: <4559DCD2.3070103@cs.utk.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] IETF67 NEA WG Meeting summary Thread-index: AccH/1cT/np21lVUTNKR1mJ+xIV9twAALyMg From: "Stephen Hanna" To: "Keith Moore" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 My email was a response to Marcus' email not Uri's. You have removed the text I was responding to, which talked about the "spy vs spy" nature of the problem, where endpoints may lie about their configuration and NEA servers might want to detect such lies. Thanks, Steve -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu]=20 Sent: Tuesday, November 14, 2006 9:12 AM To: Stephen Hanna Cc: Marcus Leech; Blumenthal, Uri; nea@ietf.org Subject: Re: [Nea] IETF67 NEA WG Meeting summary > I'm afraid that our charter says "Detecting or handling [lying] > endpoints is out of scope of the NEA WG."=20 I fail to see what this has to do with Uri's message. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Nov 14 10:23:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk08W-0000me-PO; Tue, 14 Nov 2006 10:23:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk08W-0000mX-3f for nea@ietf.org; Tue, 14 Nov 2006 10:23:44 -0500 Received: from is1.enterasys.com ([63.160.138.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk08P-0001du-Nx for nea@ietf.org; Tue, 14 Nov 2006 10:23:44 -0500 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe2.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 10:23:36 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] IETF67 NEA WG Meeting summary Date: Tue, 14 Nov 2006 10:23:29 -0500 Message-ID: <3CFB564E055A594B82C4FE89D21565605A49B5@MABOSEVS2.ets.enterasys.com> In-Reply-To: <4559DC81.9000305@cs.utk.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] IETF67 NEA WG Meeting summary Thread-Index: AccH/xscwlDEIVAIRZad+nZD/Jg1/wAAF7VQ From: "Nelson, David" To: X-OriginalArrivalTime: 14 Nov 2006 15:23:36.0554 (UTC) FILETIME=[DAB314A0:01C70800] X-imss-version: 2.043 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com 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 Keith Moore writes... =20 > again, strongly disagree. the introduction of NEA to a host=20 > presents a security risk to that host and to its owner. Ah, but the charter scope applies to hosts *owned* by enterprises. I concede that there may be legitimate personal privacy considerations were one to take one's personally owned host to work and attempt to connect to the enterprise network. There is a simple remedy to that security concern: don't do it. Keep your personal machine at home and use your work machine at work, or for working while at home or on the road. As to your concerns about how your ISP (or some other public or quasi-public service provider) may abuse the NEA work product to intrude on your personal privacy, on your personal host, that is beyond the scope of NEA. Yes, the protocol may contain elements to address personal privacy concerns. As has been stated previously in this thread (most clearly be Uri Blumenthal), your host may refuse to participate in NEA, in which case the network provider may refuse to grant your host network access, or may restrict network access in some way. Anything beyond this level of protection for personal privacy is beyond the scope of NEA. It may be fodder for consumer protection legislation, but that is certainly not the concern of the IETF. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Nov 14 10:24:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk09i-00011Q-3G; Tue, 14 Nov 2006 10:24:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk09h-00011H-Pf for nea@ietf.org; Tue, 14 Nov 2006 10:24:57 -0500 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk09g-0001xQ-0U for nea@ietf.org; Tue, 14 Nov 2006 10:24:57 -0500 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 03340564A8; Tue, 14 Nov 2006 10:24:53 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2R728+ZDXYsv; Tue, 14 Nov 2006 10:24:35 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id C7D20564B3; Tue, 14 Nov 2006 10:24:34 -0500 (EST) Message-ID: <4559DFB8.3030502@cs.utk.edu> Date: Tue, 14 Nov 2006 10:24:40 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Stephen Hanna Subject: Re: [Nea] IETF67 NEA WG Meeting summary References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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 > I seem to be Mr. Charter these days. > > Our charter says "NEA is applicable to computing > enterprise environments, where endpoints accessing the enterprise's > network are owned and/or expected to conform to the policies set forth > by the organization that owns and operates the network. All other > cases are outside the scope of the NEA charter, since we do not know > that NEA would be useful in such cases." > > So the corporate environment described by Uri is not > a corner case. It's the only case we're allowed to consider. wrong. it _is_ a corner case. it might be the anticipated use case for NEA but it's not the only case that NEA will have to deal with, because many hosts that have NEA installed will be used to connect to multiple networks. the security risks associated with installing an NEA server on your machine and connecting to other networks have to be considered in a discussion of NEA requirements. I'll give you an example of how this impacts the protocol. let's say that we declare that a machine has only one owner and that any particular interface on the machine is either connecting to a network owned by the same party or a different party. NEA should only come into play if the two parties are the same. we can design a protocol to enforce those constraints. the protocol could require that NEA requests be signed with a private key, and that NEA server implementations only respond to requests that are signed with a private key that matches the public key of the owner as configured on the machine, and furthermore than NEA server implementations MUST NOT support more than one owner. that _might_ solve the problem. (though I doubt it because there will generally be a need to support multiple key pairs at any one time so that the single owner can do rollover from old to new keys. but maybe there's a way around this) > Let's stop talking about fascist governments and such. I strongly object to your attempt to discourage this group from considering valid risks associated with NEA, and sincerely believe that by doing so you are violating IETF policy. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Nov 14 10:26:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0Am-0001Gu-F9; Tue, 14 Nov 2006 10:26:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0Al-0001Gm-Bl for nea@ietf.org; Tue, 14 Nov 2006 10:26:03 -0500 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk0Ak-00028F-32 for nea@ietf.org; Tue, 14 Nov 2006 10:26:03 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 14 Nov 2006 07:23:06 -0800 X-IronPort-AV: i="4.09,421,1157353200"; d="scan'208"; a="609508829:sNHT45012336" 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] IETF67 NEA WG Meeting summary Date: Tue, 14 Nov 2006 10:25:55 -0500 Message-ID: In-Reply-To: <4559DA90.6090507@cs.utk.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] IETF67 NEA WG Meeting summary Thread-index: AccH/h6p3tpEjNaATLqmlgwwSbKAGwAAV6Ng From: "Stephen Hanna" To: "Keith Moore" X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: Khaja Ahmed , 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 Discussion of NEA requirements is certainly in scope. Discussion of whether IETF should work on NEA is not. Discussion of concerns about NEA are certainly in scope, especially if we can translate them into specific requirements. Thanks for your concrete suggestion. Maybe you should try to translate your concerns into specific requirements. For instance, NEA clients should not be required to disclose attributes about their own configuration. Sorry to be a pain here. I'm just trying to turn our conversation in a more fruitful direction. Thanks, Steve -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu]=20 Sent: Tuesday, November 14, 2006 9:03 AM To: Stephen Hanna Cc: Khaja Ahmed; nea@ietf.org Subject: Re: [Nea] IETF67 NEA WG Meeting summary > I think we're drifting back into charter discussion. > The IETF has already chartered a group to standardize > a mechanism to "assess the "posture" of endpoint devices > for the purposes of monitoring compliance to an organization's > posture policy and optionally restricting access until the > endpoint has been updated to satisfy the posture requirements". > That's NEA. uh, no.. the IETF has chartered a group to develop requirements for=20 such a mechanism, not the mechanism itself. the current discussion is entirely relevant to developing requirements. > Instead of debating whether IETF should do this, let's > redirect the discussion to how the assessment can address > privacy and other concerns. For instance, I think it is > better for the NEA server to request specific attributes than > for the NEA client to simply send all the info it has. Also, > the NEA server should authenticate itself to the NEA client > before the NEA client is asked to send attributes. >=20 > Keith, would such a system address your concerns at all? for reasons already given, no. > If not, can you suggest some approaches that would? I don't actually know if there is a reasonable way to do what NEA wants=20 to do, but I've already suggested one alternative that might be worthy=20 of exploration - which is to NOT let the network ask questions about=20 multiple specific attributes, but to only let it present a set of=20 requirements and let the host tell it whether it meets those requirements. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Nov 14 10:26:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0BH-0001In-MG; Tue, 14 Nov 2006 10:26:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0BF-0001Ig-Uf for nea@ietf.org; Tue, 14 Nov 2006 10:26:33 -0500 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk0BE-0002Bw-OK for nea@ietf.org; Tue, 14 Nov 2006 10:26:33 -0500 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 580A7564A8; Tue, 14 Nov 2006 10:26:32 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deRvEMmpvy6n; Tue, 14 Nov 2006 10:26:24 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id A6ED7564AE; Tue, 14 Nov 2006 10:26:20 -0500 (EST) Message-ID: <4559E022.5050206@cs.utk.edu> Date: Tue, 14 Nov 2006 10:26:26 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: "Nelson, David" Subject: Re: [Nea] IETF67 NEA WG Meeting summary References: <3CFB564E055A594B82C4FE89D21565605A49B5@MABOSEVS2.ets.enterasys.com> In-Reply-To: <3CFB564E055A594B82C4FE89D21565605A49B5@MABOSEVS2.ets.enterasys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 -------- Original Message -------- > Keith Moore writes... > >> again, strongly disagree. the introduction of NEA to a host >> presents a security risk to that host and to its owner. > > Ah, but the charter scope applies to hosts *owned* by enterprises. I've addressed this topic in a reply to someone else's message, so I won't repeat it here except to say that I strongly disagree for reasons given elsewhere. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Nov 14 10:29:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0EK-0002L2-1w; Tue, 14 Nov 2006 10:29:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0EI-0002Kx-Ss for nea@ietf.org; Tue, 14 Nov 2006 10:29:42 -0500 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk0EG-0002lu-Lf for nea@ietf.org; Tue, 14 Nov 2006 10:29:42 -0500 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 1C94D564BE; Tue, 14 Nov 2006 10:29:40 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YG7SX1tJNxDi; Tue, 14 Nov 2006 10:29:35 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 5E7B2564BA; Tue, 14 Nov 2006 10:29:34 -0500 (EST) Message-ID: <4559E0E4.8050608@cs.utk.edu> Date: Tue, 14 Nov 2006 10:29:40 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Stephen Hanna Subject: Re: [Nea] IETF67 NEA WG Meeting summary References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Khaja Ahmed , 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 > Discussion of NEA requirements is certainly in scope. > Discussion of whether IETF should work on NEA is not.\ disagree. one possible output of a requirements discussion is that there is no way to meet the requirements - that the solution space for the requirements is the null set. a requirements discussion that does not admit that possibility is dishonest and useless. > Sorry to be a pain here. I'm just trying to turn our > conversation in a more fruitful direction. me too. but maybe we have different ideas as to what is fruitful? Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Nov 14 10:32:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0H7-0003JL-0L; Tue, 14 Nov 2006 10:32:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0H5-0003JA-F0 for nea@ietf.org; Tue, 14 Nov 2006 10:32:35 -0500 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk0H4-0003Ms-5L for nea@ietf.org; Tue, 14 Nov 2006 10:32:35 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 14 Nov 2006 07:29:38 -0800 X-IronPort-AV: i="4.09,421,1157353200"; d="scan'208"; a="619532204:sNHT45772372" 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] IETF67 NEA WG Meeting summary Date: Tue, 14 Nov 2006 10:32:28 -0500 Message-ID: In-Reply-To: <4559DFB8.3030502@cs.utk.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] IETF67 NEA WG Meeting summary Thread-index: AccIARcsW6EYL9K6QiOoJ92bbeZfmgAADeVg From: "Stephen Hanna" To: "Keith Moore" X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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 If there are legitimate risks to deploying NEA protocols, then I'm perfectly OK with discussing those. But I think those discussions must happen in the proper context. We should not be debating whether IETF should do NEA. Instead, we should be discussing what risks arise from the use of NEA protocols and how those risks can be addressed. Your discussion below about the need for NEA clients to authenticate NEA servers before revealing configuration information is a great example of a constructive idea for addressing the risks of NEA protocols. Would it be best to step back and try to enumerate the risks that can arise from the use of NEA protocols? Thanks, Steve -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu]=20 Sent: Tuesday, November 14, 2006 9:25 AM To: Stephen Hanna Cc: Blumenthal, Uri; nea@ietf.org Subject: Re: [Nea] IETF67 NEA WG Meeting summary > I seem to be Mr. Charter these days. >=20 > Our charter says "NEA is applicable to computing > enterprise environments, where endpoints accessing the enterprise's > network are owned and/or expected to conform to the policies set forth > by the organization that owns and operates the network. All other > cases are outside the scope of the NEA charter, since we do not know > that NEA would be useful in such cases." >=20 > So the corporate environment described by Uri is not > a corner case. It's the only case we're allowed to consider. wrong. it _is_ a corner case. it might be the anticipated use case for NEA but it's not the only case that NEA will have to deal with, because=20 many hosts that have NEA installed will be used to connect to multiple networks. the security risks associated with installing an NEA server=20 on your machine and connecting to other networks have to be considered=20 in a discussion of NEA requirements. I'll give you an example of how this impacts the protocol. let's say=20 that we declare that a machine has only one owner and that any=20 particular interface on the machine is either connecting to a network=20 owned by the same party or a different party. NEA should only come into play if the two parties are the same. we can design a protocol to=20 enforce those constraints. the protocol could require that NEA requests be signed with a private key, and that NEA server implementations only=20 respond to requests that are signed with a private key that matches the=20 public key of the owner as configured on the machine, and furthermore=20 than NEA server implementations MUST NOT support more than one owner.=20 that _might_ solve the problem. (though I doubt it because there will generally be a need to support=20 multiple key pairs at any one time so that the single owner can do=20 rollover from old to new keys. but maybe there's a way around this) > Let's stop talking about fascist governments and such. I strongly object to your attempt to discourage this group from=20 considering valid risks associated with NEA, and sincerely believe that=20 by doing so you are violating IETF policy. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Nov 14 10:34:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0Il-0003wJ-Ms; Tue, 14 Nov 2006 10:34:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0Il-0003vG-5g for nea@ietf.org; Tue, 14 Nov 2006 10:34:19 -0500 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk0Ij-0003ae-Gm for nea@ietf.org; Tue, 14 Nov 2006 10:34:19 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 14 Nov 2006 07:31:22 -0800 X-IronPort-AV: i="4.09,421,1157353200"; d="scan'208"; a="619532850:sNHT42563444" 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] IETF67 NEA WG Meeting summary Date: Tue, 14 Nov 2006 10:34:12 -0500 Message-ID: In-Reply-To: <4559E0E4.8050608@cs.utk.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] IETF67 NEA WG Meeting summary Thread-index: AccIAb4OqAeRpx5FQVe6JL5vkL0vJQAAGm0w From: "Stephen Hanna" To: "Keith Moore" X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Khaja Ahmed , 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 > disagree. one possible output of a requirements discussion is that=20 > there is no way to meet the requirements - that the solution space for > the requirements is the null set. a requirements discussion that does > not admit that possibility is dishonest and useless. That could be an output of the requirements discussion. But we need to have the requirements discussion first. I think that would be fruitful. And it's the only thing that's in scope for us at the moment. So let's talk about requirements. Do you agree that would be fruitful? Thanks, Steve -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu]=20 Sent: Tuesday, November 14, 2006 9:30 AM To: Stephen Hanna Cc: Khaja Ahmed; nea@ietf.org Subject: Re: [Nea] IETF67 NEA WG Meeting summary > Discussion of NEA requirements is certainly in scope. > Discussion of whether IETF should work on NEA is not.\ disagree. one possible output of a requirements discussion is that=20 there is no way to meet the requirements - that the solution space for=20 the requirements is the null set. a requirements discussion that does=20 not admit that possibility is dishonest and useless. > Sorry to be a pain here. I'm just trying to turn our > conversation in a more fruitful direction. me too. but maybe we have different ideas as to what is fruitful? Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Nov 14 10:38:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0Mu-00075Z-0y; Tue, 14 Nov 2006 10:38:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0Mt-00072R-7o for nea@ietf.org; Tue, 14 Nov 2006 10:38:35 -0500 Received: from is1.enterasys.com ([63.160.138.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk0Mm-0004DF-Hw for nea@ietf.org; Tue, 14 Nov 2006 10:38:35 -0500 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe2.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 10:38:27 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] IETF67 NEA WG Meeting summary Date: Tue, 14 Nov 2006 10:38:27 -0500 Message-ID: <3CFB564E055A594B82C4FE89D21565605A49B6@MABOSEVS2.ets.enterasys.com> In-Reply-To: <4559E0E4.8050608@cs.utk.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] IETF67 NEA WG Meeting summary Thread-Index: AccIAcF+7z7c61oITNGxqmuf3rXxFwAADCMw From: "Nelson, David" To: X-OriginalArrivalTime: 14 Nov 2006 15:38:27.0500 (UTC) FILETIME=[EDBEA6C0:01C70802] X-imss-version: 2.043 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 Keith Moore ... > disagree. one possible output of a requirements discussion is > that there is no way to meet the requirements - that the solution > space for the requirements is the null set. Well, from a pedantic perspective this is certainly true. However, this is the IETF. "E" is for "Engineering". Engineering is about producing useful solutions to problems. It is clear to me that NEA is addressing a valid problem. I think that attempting to "rig" the requirements so as to admit no feasible solution is effectively an attempt to subvert the WG chartering decision, and to be obstructive. Let's accept that there *is* a valid problem, and work to devise a reasonable set of requirements to solve the problem and provide generally acceptable security and privacy protection. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Nov 14 10:45:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0Tf-00013c-H8; Tue, 14 Nov 2006 10:45:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0Td-00013P-Vd for nea@ietf.org; Tue, 14 Nov 2006 10:45:33 -0500 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk0Tb-0005bp-KC for nea@ietf.org; Tue, 14 Nov 2006 10:45:33 -0500 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id ECF6F564C0; Tue, 14 Nov 2006 10:45:30 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-3xRvZb8NZI; Tue, 14 Nov 2006 10:45:24 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 317BD5649C; Tue, 14 Nov 2006 10:45:21 -0500 (EST) Message-ID: <4559E497.70806@cs.utk.edu> Date: Tue, 14 Nov 2006 10:45:27 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Stephen Hanna Subject: Re: [Nea] IETF67 NEA WG Meeting summary References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 > If there are legitimate risks to deploying NEA protocols, > then I'm perfectly OK with discussing those. But I think > those discussions must happen in the proper context. > We should not be debating whether IETF should do NEA. > Instead, we should be discussing what risks arise from > the use of NEA protocols and how those risks can be addressed. at some point it is necessary to assess whether NEA can be designed and implemented in such a way that it ameliorates more risks than it introduces. balance of risk is the right way to assess this, I think. though there's sort of a problem in that NEA might ameliorate risks for the network while introducing new risks for the user. again, I think it's impossible to have a constructive discussion about requirements without honestly considering the possibility that a reasonable set of requirements results in a null solution space. artificially relaxing the requirements (in other words, overlooking known problems) so that the solution space is non-null is dishonest and doesn't serve the interests of the internet. so I don't accept the constraint on debate that we shouldn't consider whether IETF should do NEA. and my guess is that the reason we're only chartered to do requirements at this stage is that IESG hasn't yet decided whether we should do NEA. our primary concern is to to do what's best for the Internet as a whole, not to justify NEA if after analysis it doesn't turn out to make sense. that said, I do believe that the greatest risk to access networks is from the hosts that connect to them, and I am interested in understanding what mechanisms can be devised to ameliorate those risks. I want to have an open mind about NEA, not to shoot it down preemptively. but I want NEA proponents to have open minds also. > Would it be best to step back and try to enumerate the > risks that can arise from the use of NEA protocols? that might be useful. though I also think we need to have some less structured discussion so that everyone understands that these risks are real. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Nov 14 11:07:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0ol-0002WN-9D; Tue, 14 Nov 2006 11:07:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0oj-0002Tu-Ud for nea@ietf.org; Tue, 14 Nov 2006 11:07:21 -0500 Received: from newgiles.striker.ottawa.on.ca ([205.150.200.131] helo=mail.nitros9.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk0oV-0000EY-3J for nea@ietf.org; Tue, 14 Nov 2006 11:07:08 -0500 Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 8496816DDE; Tue, 14 Nov 2006 10:57:15 -0500 (EST) From: "Alan DeKok" To: Keith Moore In-Reply-To: Your message of "Tue, 14 Nov 2006 09:32:48 EST." <4559D390.9080405@cs.utk.edu> Date: Tue, 14 Nov 2006 10:57:15 -0500 Message-Id: <20061114155715.8496816DDE@mail.nitros9.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: nea@ietf.org Subject: [Nea] Requirements specifications 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 Keith Moore wrote: > I'm not joking. there are people who would use this mechanism to do all > kinds of invasive searches. there are people in the us congress who > would see nothing wrong with having networks search computers for > "illegal" or "subversive" content if the mechanisms to do so were > already in place. it's simply not acceptable to standardize a mechanism > that can be used to do invasive searches of a computer. To re-phrase that, NEA can permit such searches only with the consent of the end host. And the party assessing posture has to prove its identity to the end host, before the end host even admits it knows about NEA. And all of that has to happen before the end host gains full network access. Remediation can be done later, but the initial assessment of identities and consent has to be done before the end host is allowed on the network, and before the end host accepts a connection to an unknown network. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Nov 14 11:10:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0rW-0003vq-RA; Tue, 14 Nov 2006 11:10:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0rW-0003vl-HL for nea@ietf.org; Tue, 14 Nov 2006 11:10:14 -0500 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk0rV-0001kD-AK for nea@ietf.org; Tue, 14 Nov 2006 11:10:14 -0500 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 0E47E564A4; Tue, 14 Nov 2006 11:10:12 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fu7quLd7itch; Tue, 14 Nov 2006 11:09:58 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id D248F564C0; Tue, 14 Nov 2006 11:09:51 -0500 (EST) Message-ID: <4559EA50.5090206@cs.utk.edu> Date: Tue, 14 Nov 2006 11:09:52 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Stephen Hanna Subject: Re: [Nea] IETF67 NEA WG Meeting summary References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 > OK, good. Let's talk about requirements. In the end, if we find > (or the IESG finds) that our requirements cannot be met then > it won't make sense to do any more NEA work in IETF. In the context > of a requirements discussion, I have no problem with having an > open discussion about risks introduced by NEA. okay, here are concrete suggestions for the first couple of requirements. my guess is that this is too much precision too soon, but we'll see how it goes. 1. NEA MUST NOT expose information about a host to any party other than the owner of that host. (and a host has at most one owner) (an alternative would be that NEA can only expose details about a host's configuration to host's owner, but that it could expose yes/no information in the sense of "I do/don't meet the requirements of your network" to parties other than the host's owner. which might make NEA more broadly applicable, but might also open up a big can of worms and/or be out of scope for this WG's current charter.) 2. The NEA protocol MUST take reasonable action to ensure that information about the host being transmitted via the NEA protocol is not disclosed to third parties who have access to the information presented on the wire. (e.g. the NEA protocol exchange must be encrypted) _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Nov 14 11:12:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0tt-0005Iu-Ig; Tue, 14 Nov 2006 11:12:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0ts-0005IY-It for nea@ietf.org; Tue, 14 Nov 2006 11:12:40 -0500 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk0th-00023H-IS for nea@ietf.org; Tue, 14 Nov 2006 11:12:40 -0500 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 3DEA2564BA; Tue, 14 Nov 2006 11:12:29 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3rLAqswMsxF; Tue, 14 Nov 2006 11:12:24 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id DCEC45649A; Tue, 14 Nov 2006 11:12:23 -0500 (EST) Message-ID: <4559EAED.2050908@cs.utk.edu> Date: Tue, 14 Nov 2006 11:12:29 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Alan DeKok References: <20061114155715.8496816DDE@mail.nitros9.org> In-Reply-To: <20061114155715.8496816DDE@mail.nitros9.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: nea@ietf.org Subject: [Nea] Re: Requirements specifications 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 > Keith Moore wrote: >> I'm not joking. there are people who would use this mechanism to do all >> kinds of invasive searches. there are people in the us congress who >> would see nothing wrong with having networks search computers for >> "illegal" or "subversive" content if the mechanisms to do so were >> already in place. it's simply not acceptable to standardize a mechanism >> that can be used to do invasive searches of a computer. > > To re-phrase that, NEA can permit such searches only with the > consent of the end host. that's not equivalent to what I was saying, and I'd have reservations about stretching things that far. I'm very concerned about user privacy, and I don't accept as an axiom that the host can consent to searches that impact the user. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Nov 14 11:15:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0wZ-0006Q9-GL; Tue, 14 Nov 2006 11:15:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0pF-000304-Jw for nea@ietf.org; Tue, 14 Nov 2006 11:07:53 -0500 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk0eF-0007LP-4U for nea@ietf.org; Tue, 14 Nov 2006 10:56:33 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 14 Nov 2006 07:53:35 -0800 X-IronPort-AV: i="4.09,421,1157353200"; d="scan'208"; a="619543167:sNHT44639598" 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] IETF67 NEA WG Meeting summary Date: Tue, 14 Nov 2006 10:56:30 -0500 Message-ID: In-Reply-To: <4559E497.70806@cs.utk.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] IETF67 NEA WG Meeting summary Thread-index: AccIA/QhLDj1c46JQL26vabDB/QqhwAALRyg From: "Stephen Hanna" To: "Keith Moore" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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 OK, good. Let's talk about requirements. In the end, if we find (or the IESG finds) that our requirements cannot be met then it won't make sense to do any more NEA work in IETF. In the context of a requirements discussion, I have no problem with having an open discussion about risks introduced by NEA. Thanks, Steve -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu]=20 Sent: Tuesday, November 14, 2006 9:45 AM To: Stephen Hanna Cc: Blumenthal, Uri; nea@ietf.org Subject: Re: [Nea] IETF67 NEA WG Meeting summary > If there are legitimate risks to deploying NEA protocols, > then I'm perfectly OK with discussing those. But I think > those discussions must happen in the proper context. > We should not be debating whether IETF should do NEA. > Instead, we should be discussing what risks arise from > the use of NEA protocols and how those risks can be addressed. at some point it is necessary to assess whether NEA can be designed and=20 implemented in such a way that it ameliorates more risks than it=20 introduces. balance of risk is the right way to assess this, I think.=20 though there's sort of a problem in that NEA might ameliorate risks for=20 the network while introducing new risks for the user. again, I think it's impossible to have a constructive discussion about=20 requirements without honestly considering the possibility that a=20 reasonable set of requirements results in a null solution space.=20 artificially relaxing the requirements (in other words, overlooking=20 known problems) so that the solution space is non-null is dishonest and=20 doesn't serve the interests of the internet. so I don't accept the constraint on debate that we shouldn't consider=20 whether IETF should do NEA. and my guess is that the reason we're only=20 chartered to do requirements at this stage is that IESG hasn't yet=20 decided whether we should do NEA. our primary concern is to to do what's best for the Internet as a whole, not to justify NEA if after analysis it doesn't turn out to make sense.=20 that said, I do believe that the greatest risk to access networks is=20 from the hosts that connect to them, and I am interested in=20 understanding what mechanisms can be devised to ameliorate those risks.=20 I want to have an open mind about NEA, not to shoot it down=20 preemptively. but I want NEA proponents to have open minds also. > Would it be best to step back and try to enumerate the > risks that can arise from the use of NEA protocols? that might be useful. though I also think we need to have some less=20 structured discussion so that everyone understands that these risks are=20 real. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Nov 14 11:17:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0y8-00073P-84; Tue, 14 Nov 2006 11:17:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0pP-00034z-SR for nea@ietf.org; Tue, 14 Nov 2006 11:08:03 -0500 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk0as-0006re-UX for nea@ietf.org; Tue, 14 Nov 2006 10:53:04 -0500 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 9966F564B9; Tue, 14 Nov 2006 10:53:02 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yAZcuQRdYyRR; Tue, 14 Nov 2006 10:52:56 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 3028F56498; Tue, 14 Nov 2006 10:52:55 -0500 (EST) Message-ID: <4559E658.3020303@cs.utk.edu> Date: Tue, 14 Nov 2006 10:52:56 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: "Nelson, David" Subject: Re: [Nea] IETF67 NEA WG Meeting summary References: <3CFB564E055A594B82C4FE89D21565605A49B6@MABOSEVS2.ets.enterasys.com> In-Reply-To: <3CFB564E055A594B82C4FE89D21565605A49B6@MABOSEVS2.ets.enterasys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 >> disagree. one possible output of a requirements discussion is >> that there is no way to meet the requirements - that the solution >> space for the requirements is the null set. > > Well, from a pedantic perspective this is certainly true. > > However, this is the IETF. "E" is for "Engineering". Engineering is > about producing useful solutions to problems. It is clear to me that > NEA is addressing a valid problem. "the problem" is valid. whether NEA is a valid solution is a different question. of course, the NEA WG isn't chartered to solve "the problem", it's chartered to develop requirements for one possible kind of solution to "the problem". (IIRC, the first step in the engineering process is stating the problem. so maybe we should start there before even discussing requirements?) > I think that attempting to "rig" the requirements so as to admit no feasible solution is effectively an > attempt to subvert the WG chartering decision, and to be obstructive. I'd agree, if anyone were doing that. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Nov 14 11:18:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0zp-0007oh-Q2; Tue, 14 Nov 2006 11:18:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk0zo-0007ob-HP for nea@ietf.org; Tue, 14 Nov 2006 11:18:48 -0500 Received: from is1.enterasys.com ([63.160.138.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk0zj-00034B-9y for nea@ietf.org; Tue, 14 Nov 2006 11:18:48 -0500 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe2.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Nov 2006 11:18:41 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] Re: Requirements specifications Date: Tue, 14 Nov 2006 11:18:41 -0500 Message-ID: <3CFB564E055A594B82C4FE89D21565605A49B8@MABOSEVS2.ets.enterasys.com> In-Reply-To: <4559EAED.2050908@cs.utk.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Re: Requirements specifications Thread-Index: AccIB7z25Q/UpbbFRW+wRNSiOdI8NgAABoiQ From: "Nelson, David" To: X-OriginalArrivalTime: 14 Nov 2006 16:18:42.0001 (UTC) FILETIME=[8CE64410:01C70808] X-imss-version: 2.043 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 Keith Moore writes ... > I'm very concerned about user privacy, and I don't accept as an axiom > that the host can consent to searches that impact the user. But you just now suggested as a requirement: > 1. NEA MUST NOT expose information about a host to any party=20 > other than the owner of that host. (and a host has at most one owner) Are we conflating owner and user? I agree that it is the owner that should be making the decision to provide information. In the enterprise environment the owner is almost always the IT department and the user is an individual employee. Are you suggesting that, in an enterprise environment, the owner (IT) or the user (employee) should be setting the information export policy for the host? _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Nov 14 11:27:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk18P-0006bj-KD; Tue, 14 Nov 2006 11:27:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk18O-0006be-Lu for nea@ietf.org; Tue, 14 Nov 2006 11:27:40 -0500 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk18N-0004tG-F7 for nea@ietf.org; Tue, 14 Nov 2006 11:27:40 -0500 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 2E310564B6; Tue, 14 Nov 2006 11:27:39 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGR8zx+qjgpB; Tue, 14 Nov 2006 11:27:33 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id D17DB5649A; Tue, 14 Nov 2006 11:27:32 -0500 (EST) Message-ID: <4559EE7B.8050104@cs.utk.edu> Date: Tue, 14 Nov 2006 11:27:39 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: "Nelson, David" Subject: Re: [Nea] Re: Requirements specifications References: <3CFB564E055A594B82C4FE89D21565605A49B8@MABOSEVS2.ets.enterasys.com> In-Reply-To: <3CFB564E055A594B82C4FE89D21565605A49B8@MABOSEVS2.ets.enterasys.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 >> I'm very concerned about user privacy, and I don't accept as an axiom >> that the host can consent to searches that impact the user. > > But you just now suggested as a requirement: > >> 1. NEA MUST NOT expose information about a host to any party >> other than the owner of that host. (and a host has at most one owner) note that I didn't suggest a requirement that NEA MUST give whatever information the owner asks for. > Are we conflating owner and user? I'm trying not to do so. > I agree that it is the owner that should be making the decision to > provide information. In the enterprise environment the owner is almost > always the IT department and the user is an individual employee. I don't agree with this a priori. I think it might be useful to treat the owner and user as separate for the purpose of requirements discussion. And I think we should avoid making assumptions like "the owner is the IT department" or "the user is an employee of the owner", or for that matter "a host has only one user". Even in enterprise environments I can find exceptions to all of these. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Nov 14 14:00:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk3UK-00068S-8M; Tue, 14 Nov 2006 13:58:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk3UI-000677-Fp for nea@ietf.org; Tue, 14 Nov 2006 13:58:26 -0500 Received: from newgiles.striker.ottawa.on.ca ([205.150.200.131] helo=mail.nitros9.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk3FU-0007DT-Mu for nea@ietf.org; Tue, 14 Nov 2006 13:43:10 -0500 Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 5615716DDE; Tue, 14 Nov 2006 13:33:18 -0500 (EST) From: "Alan DeKok" To: Keith Moore In-Reply-To: Your message of "Tue, 14 Nov 2006 11:12:29 EST." <4559EAED.2050908@cs.utk.edu> Date: Tue, 14 Nov 2006 13:33:18 -0500 Message-Id: <20061114183318.5615716DDE@mail.nitros9.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: nea@ietf.org Subject: [Nea] Re: Requirements specifications 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 Keith Moore wrote: > > To re-phrase that, NEA can permit such searches only with the > > consent of the end host. ... > I'm very concerned about user privacy, and I don't accept as an axiom > that the host can consent to searches that impact the user. To be pedantic, the user doesn't consent to anything. The user naively belives that the information the host presents to him is accurate, and the the host is doing something related to what he instructs it to do. Users don't take actions on networks. Computers do. The end host decides if the user has consented to something, usually by asking for input. Other hosts on the network don't see users, they see hosts. For all practical network-related purposes, hosts consent to actions, users don't. It is still good to talk about users, of course, but only in so far as their relationship with the end host. Do they trust it? Do they own it? Do they control it? Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Nov 14 14:04:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk3aH-0000qQ-7m; Tue, 14 Nov 2006 14:04:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk3aG-0000nl-Nd for nea@ietf.org; Tue, 14 Nov 2006 14:04:36 -0500 Received: from bes.cs.utk.edu ([160.36.56.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk3aF-0002Pf-Eg for nea@ietf.org; Tue, 14 Nov 2006 14:04:36 -0500 Received: from localhost (localhost [127.0.0.1]) by bes.cs.utk.edu (Postfix) with ESMTP id F3BA8FD58; Tue, 14 Nov 2006 14:04:34 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from bes.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pNHvooM97vHm; Tue, 14 Nov 2006 14:04:31 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by bes.cs.utk.edu (Postfix) with ESMTP id DFF18FD4D; Tue, 14 Nov 2006 14:04:30 -0500 (EST) Date: Tue, 14 Nov 2006 14:06:00 -0500 From: Keith Moore To: "Alan DeKok" Message-Id: <20061114140600.fabf392a.moore@cs.utk.edu> In-Reply-To: <20061114183318.5615716DDE@mail.nitros9.org> References: <4559EAED.2050908@cs.utk.edu> <20061114183318.5615716DDE@mail.nitros9.org> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.17; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: nea@ietf.org Subject: [Nea] Re: Requirements specifications 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 > Keith Moore wrote: > > > To re-phrase that, NEA can permit such searches only with the > > > consent of the end host. > ... > > I'm very concerned about user privacy, and I don't accept as an axiom > > that the host can consent to searches that impact the user. > > To be pedantic, the user doesn't consent to anything. The user > naively belives that the information the host presents to him is > accurate, and the the host is doing something related to what he > instructs it to do. you are overgeneralizing. > Users don't take actions on networks. Computers do. incorrect. users interact with networks in many different ways, including deciding whether to connect to them, which network services to buy, when to complain, etc. > The end host decides if the user has consented to something, usually > by asking for input. Other hosts on the network don't see users, they > see hosts. For all practical network-related purposes, hosts consent > to actions, users don't. for the purposes of this discussion, we could decide that a requirement of the NEA protocol is for an implementation to require user consent before releasing certain information. and later on we could design an NEA protocol that imposed this requirement on implementations as a condition of conformance to the protocol specification. we have no mechanism to force implementations to do this, but implementations that didn't do this would not conform - and vendors who claimed conformance would be lying. customers and users could take action against such vendors for misleading them, especially if they could show that harm was done as a result. > It is still good to talk about users, of course, but only in so far > as their relationship with the end host. false. users can and do interact with other hosts besides the end host. even if the end host is an intermediary, it is not necessarily able to consent on a user's behalf. (ever hear of OTPs or secureID?) Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Nov 14 15:56:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk5K8-0004SE-K1; Tue, 14 Nov 2006 15:56:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk5K8-0004S8-20 for nea@ietf.org; Tue, 14 Nov 2006 15:56:04 -0500 Received: from 124-254-74-144-static-dsl.ispone.net.au ([124.254.74.144] helo=oscar.sleepycat.com.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk5K5-0003PJ-VA for nea@ietf.org; Tue, 14 Nov 2006 15:56:04 -0500 Received: from 124-254-82-173-static-dsl.ispone.net.au ([124.254.82.173] helo=dhs) by oscar.sleepycat.com.au with smtp (Exim 4.62) (envelope-from ) id 1Gk5K3-0005GQ-Jj for nea@ietf.org; Wed, 15 Nov 2006 07:56:00 +1100 Received: (qmail 7271 invoked by uid 453); 14 Nov 2006 20:55:58 -0000 X-Spam-Status: No, hits=0.0 required=5.0 tests= X-Spam-Check-By: dhs Received: from pc-00008.dhs (HELO speedy) (192.168.0.8) by dhs (qpsmtpd/0.31.1) with ESMTP; Wed, 15 Nov 2006 07:55:46 +1100 From: "Darryl \(Dassa\) Lynch" To: Subject: RE: [Nea] IETF67 NEA WG Meeting summary Date: Wed, 15 Nov 2006 07:55:45 +1100 Organization: DHS International Pty Ltd MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <4559D390.9080405@cs.utk.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 thread-index: AccH+cqPfcXpi0stSRWa6uPvOApn6gAMWoKg X-Spam-Score: 0.5 (/) X-Spam-Report: Spam detection software, running on the system "oscar.sleepycat.com.au", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Keith Moore wrote: >>> Couldn't the solution be as simple as allowing the client nodes the >>> option of deciding what information they are prepared to make >>> available and the network then using what is available to >> decide how they should be treated? >> >> I really don't think so. The problem is with giving the >> network a way to interrogate the host in detail. >> >>> If not enough information is provided the node can be shunted off >>> for some form of remediation, if the network deems it has enough >>> information then the node can be allowed in. >>> >>> Both parties have choices then, what information to provide and what >>> is required to be accepted. >> >> say you want to attend a conference, like IETF. but before >> we let you in the building where the conference is held we >> want to make sure you're okay. so we're going to lock you >> in a room with an interrogator and he's going to ask you an >> arbitrary number of arbitrary questions - maybe about your >> sex life, drug use, whatever. you're free to refuse to >> answer any question, but your failure to answer might >> determine whether we let you in or shunt you off for some >> form of remediation. after all, you have nothing to hide, right? [...] Content analysis details: (0.5 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.5 DNS_FROM_RFC_ABUSE RBL: Envelope sender in abuse.rfc-ignorant.org 1.4 DNS_FROM_RFC_POST RBL: Envelope sender in postmaster.rfc-ignorant.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dassa@dhs.org List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Message-Id: Keith Moore wrote: >>> Couldn't the solution be as simple as allowing the client nodes the >>> option of deciding what information they are prepared to make >>> available and the network then using what is available to >> decide how they should be treated? >> >> I really don't think so. The problem is with giving the >> network a way to interrogate the host in detail. >> >>> If not enough information is provided the node can be shunted off >>> for some form of remediation, if the network deems it has enough >>> information then the node can be allowed in. >>> >>> Both parties have choices then, what information to provide and what >>> is required to be accepted. >> >> say you want to attend a conference, like IETF. but before >> we let you in the building where the conference is held we >> want to make sure you're okay. so we're going to lock you >> in a room with an interrogator and he's going to ask you an >> arbitrary number of arbitrary questions - maybe about your >> sex life, drug use, whatever. you're free to refuse to >> answer any question, but your failure to answer might >> determine whether we let you in or shunt you off for some >> form of remediation. after all, you have nothing to hide, right? I often avoid situations where I may be requested to provide information I'm not willing to provide. There is nothing new in that. Providing I have the choice to provide the information or not it isn't a problem for me. Consumers have enough market force to ensure organisations will not request more than what may be reasonable. It is considered reasonable to put people through security before they can fly out of the country or even often, within a country. The amount of security the public is willing to put up with is still being worked out, personally I find it intrusive but am willing to go along as it is for the public good. >> while we're at it, maybe we should examine your laptop too. >> maybe you have kiddie porn on there somewhere, maybe you >> have illegal mp3 files (despite the fact that we can't tell >> whether or not you have a license for such files - we'll >> decide for ourselves whether they're illegal or not). maybe >> you have open source software. that's bad enough - you >> never know what those guys will put in there. maybe you >> have p2p file sharing software - you must be a pirate! >> maybe you've even written some software of your own. we >> certainly don't want to trust that. >> >> I'm not joking. there are people who would use this >> mechanism to do all kinds of invasive searches. there are >> people in the us congress who would see nothing wrong with >> having networks search computers for "illegal" or >> "subversive" content if the mechanisms to do so were already >> in place. it's simply not acceptable to standardize a >> mechanism that can be used to do invasive searches of a computer. There are already mechanisms that will do such searches and they are being used, at a higher level than NEA. NEA should provide a suitable mix of attributes so that higher level scanning will be minimal and less intrusive. If I know a system connecting to my network is patched up and has it's own reasonable protection measures in place I'm less likely to be concerned about it and doing more intrusive investigations to ensure there isn't any risk associated with it. I'm more inclined to allow it out of a DMZ. At present I can only do this manually or after the system has been allowed into the network unless I enforce even worse mechanisms than NEA could ever be. Darryl (Dassa) Lynch _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Nov 14 17:04:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk6Ob-0001xl-73; Tue, 14 Nov 2006 17:04:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk6OZ-0001xd-6I for nea@ietf.org; Tue, 14 Nov 2006 17:04:43 -0500 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk6OV-0004N9-BE for nea@ietf.org; Tue, 14 Nov 2006 17:04:43 -0500 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id C7A4056470; Tue, 14 Nov 2006 17:04:36 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cuZNp1XmkDSe; Tue, 14 Nov 2006 17:04:32 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 057E656463; Tue, 14 Nov 2006 17:04:31 -0500 (EST) Message-ID: <455A3D76.6070201@cs.utk.edu> Date: Tue, 14 Nov 2006 17:04:38 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: dassa@dhs.org Subject: Re: [Nea] IETF67 NEA WG Meeting summary References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 > I often avoid situations where I may be requested to provide > information I'm not willing to provide. There is nothing new in > that. Providing I have the choice to provide the information or not > it isn't a problem for me. Consumers have enough market force to > ensure organisations will not request more than what may be > reasonable. sometimes they do, often they don't. it depends on the market, and also on consumer awareness. a lot of automobile purchasers aren't aware, for instance, that the new car that they are buying records information about their driving habits that can be used against them. > It is considered reasonable to put people through security before > they can fly out of the country or even often, within a country. The > amount of security the public is willing to put up with is still > being worked out, personally I find it intrusive but am willing to go > along as it is for the public good. and a lot of people (including myself) are not nearly so willing to fly commercially as they used to be. > There are already mechanisms that will do such searches and they are > being used, at a higher level than NEA. sure, but we're talking about what IETF should standardize, not about what already exists. the existence of bad things does not compel IETF to bless them. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Nov 14 20:27:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk9YS-0002OZ-Cr; Tue, 14 Nov 2006 20:27:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gk9YR-0002OU-MX for nea@ietf.org; Tue, 14 Nov 2006 20:27:07 -0500 Received: from nz-out-0102.google.com ([64.233.162.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gk9YQ-0006mr-Gh for nea@ietf.org; Tue, 14 Nov 2006 20:27:07 -0500 Received: by nz-out-0102.google.com with SMTP id k1so18245nzf for ; Tue, 14 Nov 2006 17:27:06 -0800 (PST) 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=TppbyUWsrhnu1YBSGnhi7q6YlldLIlhQzIQlBXKp9eeitOre0wD00XCXl7WwuuntGG2PJpgyAdj8CwMNWTFxGbl1c/OfyndRY5mGhZlNt2DT8bbsvKbA62+punUwKMAMgETOj9lDPk+BnA5/VGP0dSAr/qgbLugKRu0G0fy5G/I= Received: by 10.65.154.4 with SMTP id g4mr2305573qbo.1163554025941; Tue, 14 Nov 2006 17:27:05 -0800 (PST) Received: by 10.65.156.6 with HTTP; Tue, 14 Nov 2006 17:27:05 -0800 (PST) Message-ID: Date: Tue, 14 Nov 2006 20:27:05 -0500 From: "Mike Fratto" To: "Keith Moore" Subject: Re: [Nea] IETF67 NEA WG Meeting summary In-Reply-To: <455A3D76.6070201@cs.utk.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <455A3D76.6070201@cs.utk.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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 Can you please move this entire thread elsewhere? It is not sunstantive to the discussion of setting ID requirements. If you are unwilling to do that, then how about adding something substantive. For example, Keith, you have referenced time and time again vague risks to privacy. Can you spell out in clear and actionable terms what those risks are? A bulleted list with a short description would be useful. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Nov 15 00:19:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkDBA-0003Fw-Pu; Wed, 15 Nov 2006 00:19:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkDB9-0003En-Ep for nea@ietf.org; Wed, 15 Nov 2006 00:19:19 -0500 Received: from mail3.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkCwX-0007eH-QU for nea@ietf.org; Wed, 15 Nov 2006 00:04:17 -0500 Received: from tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.0.685.15; Tue, 14 Nov 2006 21:04:13 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) with Microsoft SMTP Server id 8.0.685.20; Tue, 14 Nov 2006 21:04:12 -0800 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.2786); Tue, 14 Nov 2006 21:04:12 -0800 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] IETF67 NEA WG Meeting summary Date: Tue, 14 Nov 2006 21:03:27 -0800 Message-ID: In-Reply-To: <4559EA50.5090206@cs.utk.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] IETF67 NEA WG Meeting summary Thread-Index: AccIB2XrOScudDIQRuWmt8Mk1+60BAAaf+oQ From: Khaja Ahmed To: Keith Moore , Stephen Hanna X-OriginalArrivalTime: 15 Nov 2006 05:04:12.0646 (UTC) FILETIME=[7DB28060:01C70873] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 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 you be OK with the following amendment to the first requirement? NEA MUST NOT expose information about a host to any party other than the owner of that host or to parties authorized by the owner. Khaja -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu]=20 Sent: Tuesday, November 14, 2006 8:10 AM To: Stephen Hanna Cc: nea@ietf.org Subject: Re: [Nea] IETF67 NEA WG Meeting summary > OK, good. Let's talk about requirements. In the end, if we find > (or the IESG finds) that our requirements cannot be met then > it won't make sense to do any more NEA work in IETF. In the context > of a requirements discussion, I have no problem with having an > open discussion about risks introduced by NEA. okay, here are concrete suggestions for the first couple of=20 requirements. my guess is that this is too much precision too soon, but we'll see how it goes. 1. NEA MUST NOT expose information about a host to any party other than=20 the owner of that host. (and a host has at most one owner) (an alternative would be that NEA can only expose details about a host's configuration to host's owner, but that it could expose yes/no=20 information in the sense of "I do/don't meet the requirements of your=20 network" to parties other than the host's owner. which might make NEA=20 more broadly applicable, but might also open up a big can of worms=20 and/or be out of scope for this WG's current charter.) 2. The NEA protocol MUST take reasonable action to ensure that=20 information about the host being transmitted via the NEA protocol is not disclosed to third parties who have access to the information=20 presented on the wire. (e.g. the NEA protocol exchange must be encrypted) _______________________________________________ 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 Nov 15 01:01:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkDpL-0003MF-39; Wed, 15 Nov 2006 01:00:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkDpJ-0003M6-Hj for nea@ietf.org; Wed, 15 Nov 2006 01:00:49 -0500 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkDpI-0004sZ-Ay for nea@ietf.org; Wed, 15 Nov 2006 01:00:49 -0500 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 5E15A56493; Wed, 15 Nov 2006 01:00:47 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYbCWNJTUlzk; Wed, 15 Nov 2006 01:00:42 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 72B5256472; Wed, 15 Nov 2006 01:00:35 -0500 (EST) Message-ID: <455AAD0A.8060309@cs.utk.edu> Date: Wed, 15 Nov 2006 01:00:42 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Mike Fratto Subject: Re: [Nea] IETF67 NEA WG Meeting summary References: <455A3D76.6070201@cs.utk.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 > Can you please move this entire thread elsewhere? It is not > sunstantive to the discussion of setting ID requirements. If you are > unwilling to do that, then how about adding something substantive. no, I'm not willing to move this thread elsewhere, because security and privacy issues are at the crux of the problem that NEA must solve if it is to meet rfc 2026 criteria and gain community consensus. > For example, Keith, you have referenced time and time again vague > risks to privacy. Can you spell out in clear and actionable terms > what those risks are? A bulleted list with a short description would > be useful. it's too simple a concept for a bulleted list. how difficult is it to understand that people don't want the contents of their hard drives to be subjected to arbitrary searches as a precondition to being able to access networks? _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Nov 15 01:20:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkE80-0002ab-LM; Wed, 15 Nov 2006 01:20:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkE7z-0002YC-6w for nea@ietf.org; Wed, 15 Nov 2006 01:20:07 -0500 Received: from ka.cs.utk.edu ([160.36.56.221]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkE7w-0006Zl-U7 for nea@ietf.org; Wed, 15 Nov 2006 01:20:07 -0500 Received: from localhost (localhost [127.0.0.1]) by ka.cs.utk.edu (Postfix) with ESMTP id 3C0542F248; Wed, 15 Nov 2006 01:20:04 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from ka.cs.utk.edu ([127.0.0.1]) by localhost (ka.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8gj2B3tDOsP; Wed, 15 Nov 2006 01:19:58 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by ka.cs.utk.edu (Postfix) with ESMTP id 622112F23C; Wed, 15 Nov 2006 01:19:58 -0500 (EST) Message-ID: <455AB195.90900@cs.utk.edu> Date: Wed, 15 Nov 2006 01:20:05 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Khaja Ahmed Subject: Re: [Nea] IETF67 NEA WG Meeting summary References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 you be OK with the following amendment to the first requirement? > NEA MUST NOT expose information about a host to any party other than > the owner of that host or to parties authorized by the owner. no, I'm not okay with that. the problem is that people can be coerced into giving up their privacy if the protocol makes it easy for them to do that. I'll give an example: HTTP cookies. they weren't intended to be used as a means to track user behavior. they ended up being used that way because (a) they were not designed with due concern for privacy and (b) many implementations didn't bother implementing the protections specified by the standards. instead they gave users a yes or no switch: "do you want to enable cookies or not?" and a lot of web sites also gave users a yes or no option: "either enable arbitrary cookies or don't use our web site". and the web sites didn't adhere to the rules for using cookies either. what I conclude from the cookie experience is that when the server and host don't have the same owner, the server (i.e. the network) can't be trusted to not abuse the ability to query hosts for fine-grained information if NEA gives it that ability, and NEA client (i.e. host) implementors can't be trusted to implement appropriate privacy safeguards for clients if the protocol itself isn't designed in such a way as to make it unlikely that networks will be able to demand such information from clients. regarding NEA: what I might be okay with is giving authorized third-parties yes or no assurance that the host meets or does not meet their policies, without giving them fine-grained detail about what is installed on the host. so the owner of a host could get details about why a host did or did not fit within a particular network's policy, but the network (if owned by another party than the owner of the host) could only get yes or no information. I would like to see this option examined further. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Nov 15 03:56:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkGZ5-0006I7-Tb; Wed, 15 Nov 2006 03:56:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkGZ4-0006Hv-EL for nea@ietf.org; Wed, 15 Nov 2006 03:56:14 -0500 Received: from eunet-gw.ipv6.netcore.fi ([2001:670:86:3001::1] helo=netcore.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkGZ2-0002u6-VL for nea@ietf.org; Wed, 15 Nov 2006 03:56:14 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.12.11.20060614/8.12.11) with ESMTP id kAF8twCT007005; Wed, 15 Nov 2006 10:55:59 +0200 Date: Wed, 15 Nov 2006 10:55:58 +0200 (EET) From: Pekka Savola To: Keith Moore In-Reply-To: <4559EA50.5090206@cs.utk.edu> Message-ID: References: <4559EA50.5090206@cs.utk.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.88.6/2195/Tue Nov 14 21:53:04 2006 on otso.netcore.fi X-Virus-Status: Clean X-Spam-Status: No, score=-1.0 required=5.0 tests=AWL, BAYES_50, NO_RELAYS autolearn=ham version=3.1.7 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on otso.netcore.fi X-Spam-Score: -2.8 (--) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: nea@ietf.org Subject: [Nea] privacy: exposing information to owner 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 On Tue, 14 Nov 2006, Keith Moore wrote: > 1. NEA MUST NOT expose information about a host to any party other than the > owner of that host. (and a host has at most one owner) > > (an alternative would be that NEA can only expose details about a host's > configuration to host's owner, but that it could expose yes/no information in > the sense of "I do/don't meet the requirements of your network" to parties > other than the host's owner. which might make NEA more broadly applicable, > but might also open up a big can of worms and/or be out of scope for this WG's > current charter.) Actually, I think in some contexts this might need to be stronger than this. For example, even if an employee's laptop is owned by the enterprise, some legislations (at least here in Finland) there are prohibitions on what the employer may (or may not) do e.g., to track the employee or employee's usage. For example, it would be illegal to track which websites the user surfs to ("to ensure productive use of working time"), the amount of time keyboard/mouse is idle ("the user is not doing anything at work") etc. It is not clear to me to what extent this would need to be reflected in the NEA protocol or requirements. Nonetheless 'only the owner can get full information' might be too much in some cases. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Nov 15 05:46:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkIHY-0007QI-Qx; Wed, 15 Nov 2006 05:46:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkIHX-0007Q3-Qx for nea@ietf.org; Wed, 15 Nov 2006 05:46:15 -0500 Received: from 124-254-74-144-static-dsl.ispone.net.au ([124.254.74.144] helo=oscar.sleepycat.com.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkIHW-0003Zt-18 for nea@ietf.org; Wed, 15 Nov 2006 05:46:15 -0500 Received: from 124-254-82-173-static-dsl.ispone.net.au ([124.254.82.173] helo=dhs) by oscar.sleepycat.com.au with smtp (Exim 4.62) (envelope-from ) id 1GkIHN-0000xY-J1 for nea@ietf.org; Wed, 15 Nov 2006 21:46:05 +1100 Received: (qmail 7720 invoked by uid 453); 15 Nov 2006 10:46:04 -0000 X-Spam-Status: No, hits=0.0 required=5.0 tests= X-Spam-Check-By: dhs Received: from pc-00008.dhs (HELO speedy) (192.168.0.8) by dhs (qpsmtpd/0.31.1) with ESMTP; Wed, 15 Nov 2006 21:45:52 +1100 From: "Darryl \(Dassa\) Lynch" To: Subject: RE: [Nea] IETF67 NEA WG Meeting summary Date: Wed, 15 Nov 2006 21:45:42 +1100 Organization: DHS International Pty Ltd MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccIfiHXjW/iiTp3TVi+KmJLAfAhawAI+UYw In-Reply-To: <455AB195.90900@cs.utk.edu> X-Spam-Score: 0.5 (/) X-Spam-Report: Spam detection software, running on the system "oscar.sleepycat.com.au", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Keith Moore wrote: >> regarding NEA: what I might be okay with is giving >> authorized third-parties yes or no assurance that the host >> meets or does not meet their policies, without giving them >> fine-grained detail about what is installed on the host. so >> the owner of a host could get details about why a host did >> or did not fit within a particular network's policy, but the >> network (if owned by another party than the owner of the host) could >> only get yes or no information. I would like to see this option >> examined further. [...] Content analysis details: (0.5 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.5 DNS_FROM_RFC_ABUSE RBL: Envelope sender in abuse.rfc-ignorant.org 1.4 DNS_FROM_RFC_POST RBL: Envelope sender in postmaster.rfc-ignorant.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dassa@dhs.org List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Message-Id: Keith Moore wrote: >> regarding NEA: what I might be okay with is giving >> authorized third-parties yes or no assurance that the host >> meets or does not meet their policies, without giving them >> fine-grained detail about what is installed on the host. so >> the owner of a host could get details about why a host did >> or did not fit within a particular network's policy, but the >> network (if owned by another party than the owner of the host) could >> only get yes or no information. I would like to see this option >> examined further. I don't imagine this is totally out there although I can see it may require some careful consideration with respect to how the attributes may follow this and still be useful and provide enough information for judgements to be made. An example I can imagine is where a NEA enabled node attempts to connect and is requested to provide information on the current anti-virus status. A yes or no answer can only be given where the policy is known and then a comparison made at the node to determine if the policy is met or not. This shifts the onus of providing additional information to the network and away from the node which exposes some information that may be gleened for refined attack vectors. My personal choice is to limit the amount of information exposed by the network and leave the onus on the node to provide more as they are the ones requesting access. If the attributes are defined carefully it should be possible to reach a reasonable compromise. Darryl (Dassa) Lynch _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Nov 15 08:25:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkKlZ-000247-BC; Wed, 15 Nov 2006 08:25:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkKlZ-000242-3Z for nea@ietf.org; Wed, 15 Nov 2006 08:25:25 -0500 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkKlX-0003BV-Of for nea@ietf.org; Wed, 15 Nov 2006 08:25:25 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 15 Nov 2006 05:22:27 -0800 X-IronPort-AV: i="4.09,424,1157353200"; d="scan'208"; a="620090285:sNHT53718412" 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] privacy: exposing information to owner Date: Wed, 15 Nov 2006 08:25:20 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] privacy: exposing information to owner Thread-index: AccIlAApueMwf8X4SLWDaF9wxiB0ugAIvS6A From: "Stephen Hanna" To: "Pekka Savola" , "Keith Moore" X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 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 This comment highlights the fact that there is a lot of variation in what information should be disclosed. On military networks, it's entirely appropriate for the network to require a complete and verifiable inventory of software on the endpoint (maybe also information about recent activity, configuration, etc.). The network will probably not be willing to divulge its access policies. On open access networks, no information should be required from the endpoint. Any participation in NEA should be purely voluntary and can involve the network sending its latest policy to the endpoint, which may respond at its discretion. No enforcement involved. Commercial networks lie somewhere in between. They may be willing to grant Internet access if no information is available on the endpoint. Access to corporate resources will probably require some information and the amount of information required will probably depend on the sensitivity of the resources to be accessed (and on local regulations, as Pekka points out). It seems clear to me that this is an areas for local policy. The endpoint should have a policy about what information it is willing to disclose and to whom. The network should have a policy about what information it requests, whether it will divulge its policies, and what access it is willing to grant. The requirement for the NEA standards should be that they describe the security and privacy concerns inherent in this system, describe how those concerns can be addressed, and require the protocols to include features that enable the endpoint and network to implement whatever policy they want. Then the endpoint and network owners can configure their policies with confidence. One endpoint owner may disable NEA. Another may configure a policy of "Tell nothing but accept advice from my ISP". Others may decide to disclose OS patch info to their corporate servers only. The military owner may configure a policy to disclose a full inventory but ONLY to authorized servers. For us to decide on a one-size-fits-all policy in this area would be impossible. If we're concerned about naive users, we can require that endpoints ship with NEA disabled and require explicit approval and administrative privileges to enable it or configure policy. Thanks, Steve -----Original Message----- From: Pekka Savola [mailto:pekkas@netcore.fi]=20 Sent: Wednesday, November 15, 2006 2:56 AM To: Keith Moore Cc: nea@ietf.org Subject: [Nea] privacy: exposing information to owner On Tue, 14 Nov 2006, Keith Moore wrote: > 1. NEA MUST NOT expose information about a host to any party other than the > owner of that host. (and a host has at most one owner) >=20 > (an alternative would be that NEA can only expose details about a host's > configuration to host's owner, but that it could expose yes/no information in > the sense of "I do/don't meet the requirements of your network" to parties > other than the host's owner. which might make NEA more broadly applicable, > but might also open up a big can of worms and/or be out of scope for this WG's > current charter.) Actually, I think in some contexts this might need to be stronger than=20 this. For example, even if an employee's laptop is owned by the=20 enterprise, some legislations (at least here in Finland) there are=20 prohibitions on what the employer may (or may not) do e.g., to track=20 the employee or employee's usage. For example, it would be illegal to track which websites the user=20 surfs to ("to ensure productive use of working time"), the amount of=20 time keyboard/mouse is idle ("the user is not doing anything at work")=20 etc. It is not clear to me to what extent this would need to be reflected=20 in the NEA protocol or requirements. Nonetheless 'only the owner can=20 get full information' might be too much in some cases. --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ 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 Nov 15 08:45:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkL4y-0002RT-Lk; Wed, 15 Nov 2006 08:45:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkL4x-0002QN-Kx for nea@ietf.org; Wed, 15 Nov 2006 08:45:27 -0500 Received: from nz-out-0102.google.com ([64.233.162.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkL4w-00063t-FO for nea@ietf.org; Wed, 15 Nov 2006 08:45:27 -0500 Received: by nz-out-0102.google.com with SMTP id k1so47125nzf for ; Wed, 15 Nov 2006 05:45:26 -0800 (PST) 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=bVj8FYdcg0v9R95iSqcB9fJJyfuWPob3nPK0N8G5PhTiTMbdnrl9S08naSZGYar1RwqobfgP0/glAtd12+5LGewHh5mSl456fgoBrJmorQghMnUSDzjMd3JmpI3ESPtLo/0i3pNAJnx8MqzeIzTcA8F6BggP+ZVI5FloANgXk00= Received: by 10.65.191.7 with SMTP id t7mr3439084qbp.1163598326097; Wed, 15 Nov 2006 05:45:26 -0800 (PST) Received: by 10.65.156.6 with HTTP; Wed, 15 Nov 2006 05:45:25 -0800 (PST) Message-ID: Date: Wed, 15 Nov 2006 08:45:25 -0500 From: "Mike Fratto" To: "Keith Moore" Subject: Re: [Nea] IETF67 NEA WG Meeting summary In-Reply-To: <455AAD0A.8060309@cs.utk.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <455A3D76.6070201@cs.utk.edu> <455AAD0A.8060309@cs.utk.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 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 > it's too simple a concept for a bulleted list. > > how difficult is it to understand that people don't want the contents of > their hard drives to be subjected to arbitrary searches as a > precondition to being able to access networks? Please, if the list is so simple, then perhaps you can spare a minute to list them out? Or are you unwilling to explicitly state your opinion? _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Nov 15 09:31:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkLnE-0002Pv-Nl; Wed, 15 Nov 2006 09:31:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkLnD-0002Po-AD for nea@ietf.org; Wed, 15 Nov 2006 09:31:11 -0500 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkLnC-0003rd-0S for nea@ietf.org; Wed, 15 Nov 2006 09:31:11 -0500 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 0B0A5564CD; Wed, 15 Nov 2006 09:31:09 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFiBDnIhsZd0; Wed, 15 Nov 2006 09:31:03 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 0B79F564C8; Wed, 15 Nov 2006 09:31:01 -0500 (EST) Message-ID: <455B24AD.9090209@cs.utk.edu> Date: Wed, 15 Nov 2006 09:31:09 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Stephen Hanna Subject: Re: [Nea] privacy: exposing information to owner References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 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 -------- Original Message -------- > This comment highlights the fact that there is a lot of variation in > what information should be disclosed. > > On military networks, it's entirely appropriate for the network to > require a complete and verifiable inventory of software on the > endpoint (maybe also information about recent activity, > configuration, etc.). The network will probably not be willing to > divulge its access policies. > > On open access networks, no information should be required from the > endpoint. Any participation in NEA should be purely voluntary and can > involve the network sending its latest policy to the endpoint, which > may respond at its discretion. No enforcement involved. > > Commercial networks lie somewhere in between. They may be willing to > grant Internet access if no information is available on the endpoint. > Access to corporate resources will probably require some information > and the amount of information required will probably depend on the > sensitivity of the resources to be accessed (and on local > regulations, as Pekka points out). > > It seems clear to me that this is an areas for local policy. I don't agree with your assessment. Just because a network to which a host attaches might be run by (say) the military doesn't mean that it's reasonable for an Internet standard to facilitate an arbitrary level of surveillance or even to give the user a choice about how much surveillance is allowed. I don't see any way to do this that will not result, in practice, in users being forced to compromise their privacy far beyond that which is reasonable. > The endpoint should have a policy about what information it is > willing to disclose and to whom. The network should have a policy > about what information it requests, whether it will divulge its > policies, and what access it is willing to grant. The requirement for > the NEA standards should be that they describe the security and > privacy concerns inherent in this system, describe how those concerns > can be addressed, and require the protocols to include features that > enable the endpoint and network to implement whatever policy they > want. Then the endpoint and network owners can configure their > policies with confidence. One endpoint owner may disable NEA. Another > may configure a policy of "Tell nothing but accept advice from my > ISP". Others may decide to disclose OS patch info to their corporate > servers only. The military owner may configure a policy to disclose a > full inventory but ONLY to authorized servers. Strongly disagree with all of the above. For the most part, users aren't sophisticated enough to determine what the policies on their hosts should be. This makes them vulnerable to invasion of privacy - first as individuals, as naive users succumb to pressure from networks to grant more access than is necessary - and then market forces force even the more sophisticated users to either accept this privacy erosion for themselves or have their access severely limited. I've seen it happen more times than I can count. > For us to decide on a one-size-fits-all policy in this area would be > impossible. perhaps, but that might mean that there is no reasonable solution to the NEA approach, and a very different approach is needed. > If we're concerned about naive users, we can require that endpoints > ship with NEA disabled and require explicit approval and > administrative privileges to enable it or configure policy. doesn't solve the problem. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Nov 15 09:32:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkLoL-0002rb-1Q; Wed, 15 Nov 2006 09:32:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkLoJ-0002qy-VC for nea@ietf.org; Wed, 15 Nov 2006 09:32:19 -0500 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkLoI-0003zL-Or for nea@ietf.org; Wed, 15 Nov 2006 09:32:19 -0500 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 2C310564D4; Wed, 15 Nov 2006 09:32:18 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmvFdrEB42Zu; Wed, 15 Nov 2006 09:32:07 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 37B00564C8; Wed, 15 Nov 2006 09:32:07 -0500 (EST) Message-ID: <455B24EC.4010700@cs.utk.edu> Date: Wed, 15 Nov 2006 09:32:12 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Mike Fratto Subject: Re: [Nea] IETF67 NEA WG Meeting summary References: <455A3D76.6070201@cs.utk.edu> <455AAD0A.8060309@cs.utk.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 -------- Original Message -------- >> it's too simple a concept for a bulleted list. >> >> how difficult is it to understand that people don't want the contents of >> their hard drives to be subjected to arbitrary searches as a >> precondition to being able to access networks? > > Please, if the list is so simple, then perhaps you can spare a minute > to list them out? I don't understand - what do you want me to list? examples of potential contents of someone's hard drive that a user might not want to be disclosed? _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Nov 15 09:34:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkLqd-0005LW-GI; Wed, 15 Nov 2006 09:34:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkLqc-0005LR-QJ for nea@ietf.org; Wed, 15 Nov 2006 09:34:42 -0500 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkLqa-0004Kd-Iu for nea@ietf.org; Wed, 15 Nov 2006 09:34:42 -0500 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 97DB9564BA; Wed, 15 Nov 2006 09:15:36 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYLDf1fraujF; Wed, 15 Nov 2006 09:15:27 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id DDC6D564D0; Wed, 15 Nov 2006 09:15:26 -0500 (EST) Message-ID: <455B2105.1060204@cs.utk.edu> Date: Wed, 15 Nov 2006 09:15:33 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: dassa@dhs.org Subject: Re: [Nea] IETF67 NEA WG Meeting summary References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 > An example I can imagine is where a NEA enabled node attempts to connect and > is requested to provide information on the current anti-virus status. A yes > or no answer can only be given where the policy is known and then a > comparison made at the node to determine if the policy is met or not. This > shifts the onus of providing additional information to the network and away > from the node which exposes some information that may be gleened for refined > attack vectors. good point. > My personal choice is to limit the amount of information exposed by the > network and leave the onus on the node to provide more as they are the ones > requesting access. > > If the attributes are defined carefully it should be possible to reach a > reasonable compromise. perhaps, though that might be a bit different than the charter anticipates, depending on whether that particular text is descriptive or proscriptive. (IMHO, way too much is assumed by the current charter - it's a case of making engineering decisions before the problem is understood.) _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Nov 15 09:47:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkM3M-0001Po-TF; Wed, 15 Nov 2006 09:47:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkM3M-0001Pj-7Z for nea@ietf.org; Wed, 15 Nov 2006 09:47:52 -0500 Received: from mailservice.tudelft.nl ([130.161.131.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkM3K-0005tS-ON for nea@ietf.org; Wed, 15 Nov 2006 09:47:52 -0500 Received: from localhost (localhost [127.0.0.1]) by amavis (Postfix) with ESMTP id C6A32222F1D; Wed, 15 Nov 2006 15:47:45 +0100 (CET) X-Virus-Scanned: amavisd-new at tudelft.nl X-Spam-Score: -1.975 X-Spam-Level: X-Spam-Status: No, score=-1.975 tagged_above=-99 required=5 tests=[ALL_TRUSTED=-1.8, BAYES_40=-0.185, PROLO_LEO3=0.01] Received: from mailservice.tudelft.nl ([127.0.0.1]) by localhost (tudelft.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 5WtFqWR2xDiA; Wed, 15 Nov 2006 15:47:40 +0100 (CET) Received: from oli.tudelft.nl (secure.oli.tudelft.nl [130.161.3.196]) by mx0.tudelft.nl (Postfix) with SMTP id 69B93222F63; Wed, 15 Nov 2006 15:47:40 +0100 (CET) Received: from 159.46.248.233 (SquirrelMail authenticated user jochemd@oli.tudelft.nl) by secure.oli.tudelft.nl with HTTP; Wed, 15 Nov 2006 15:47:40 +0100 (CET) Message-ID: <45802.159.46.248.233.1163602060.squirrel@secure.oli.tudelft.nl> Date: Wed, 15 Nov 2006 15:47:40 +0100 (CET) Subject: RE: [Nea] IETF67 NEA WG Meeting summary From: "Jochem van Dieten" To: In-Reply-To: References: <4559D92A.20507@cs.utk.edu> X-Priority: 3 Importance: Normal X-Mailer: SquirrelMail (version 1.2.10) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: nea@ietf.org, moore@cs.utk.edu 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 Stephen Hanna said: > I seem to be Mr. Charter these days. > > Our charter says "NEA is applicable to computing > enterprise environments, where endpoints accessing the enterprise's > network are owned and/or expected to conform to the policies set > forth by the organization that owns and operates the network. All > other > cases are outside the scope of the NEA charter, since we do not know > that NEA would be useful in such cases." > > So the corporate environment described by Uri is not > a corner case. It's the only case we're allowed to consider. > Let's stop talking about fascist governments and such. > We must focus on a corporate environment where endpoints > are owned by or expect to conform to the policies set > forth by the network owner. I believe this wording of the charter does extend the scope of NEA beyond the corporate environment: enterprise is more then just corporate. This charter covers the academic environment where students bring their own laptop, but connect to the enterprise network of their institution where they are expected to conform to the policies set forth by that institution. In this environment it is also not realistic to expect users to "keep your personal machine at home and use your work machine at work": the home network in the dorm is the same enterprise network as the network at work. And let's not forget that in this environment we already see NEA-like solutions being deployed as we speak. So unless I am misunderstanding the charter and the academic environment is explicitly not covered, I do believe Keith's concerns regarding the risk NEA poses to privacy are accurate and we should formulate requirements to safeguard that privacy. Jochem _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Nov 15 09:52:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkM7h-00039w-Ok; Wed, 15 Nov 2006 09:52:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkM7g-00037e-00 for nea@ietf.org; Wed, 15 Nov 2006 09:52:20 -0500 Received: from nz-out-0102.google.com ([64.233.162.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkM7e-0006OT-QQ for nea@ietf.org; Wed, 15 Nov 2006 09:52:19 -0500 Received: by nz-out-0102.google.com with SMTP id k1so61591nzf for ; Wed, 15 Nov 2006 06:52:16 -0800 (PST) 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=PcjizfVkciw37gaUmSxqov6LH2XCPgwlEA5fy6HnRL9B6cG3VdSH4yQ94T4F+IOOtAkZKXCepg0H8rB+qUVsQtYiccmOpAafe+drshPOfMIFafUu+UmwU2p33C6mdMbS2e1/kaptd/8CdMYqEecuUa7t7YSiyTdpI7uhQgyUJQo= Received: by 10.65.228.5 with SMTP id f5mr2968047qbr.1163602335146; Wed, 15 Nov 2006 06:52:15 -0800 (PST) Received: by 10.65.156.6 with HTTP; Wed, 15 Nov 2006 06:52:15 -0800 (PST) Message-ID: Date: Wed, 15 Nov 2006 09:52:15 -0500 From: "Mike Fratto" To: "Keith Moore" Subject: Re: [Nea] IETF67 NEA WG Meeting summary In-Reply-To: <455B24EC.4010700@cs.utk.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <455A3D76.6070201@cs.utk.edu> <455AAD0A.8060309@cs.utk.edu> <455B24EC.4010700@cs.utk.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed 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 > I don't understand - what do you want me to list? examples of potential > contents of someone's hard drive that a user might not want to be disclosed? I am asking you to list in clear and concise terms the "privacy issues" you have. Is exposing the contents of a hard drive the only issue you have, or are there more? If there are more, then state please list them. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Nov 15 10:14:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkMT7-00046l-MG; Wed, 15 Nov 2006 10:14:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkMT6-00046c-AL for nea@ietf.org; Wed, 15 Nov 2006 10:14:28 -0500 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkMT5-0001Fa-3d for nea@ietf.org; Wed, 15 Nov 2006 10:14:28 -0500 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id B7FD6564CD; Wed, 15 Nov 2006 10:14:26 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xpaalM0vU8+D; Wed, 15 Nov 2006 10:14:22 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 3FC0D564C9; Wed, 15 Nov 2006 10:14:22 -0500 (EST) Message-ID: <455B2ED5.4070004@cs.utk.edu> Date: Wed, 15 Nov 2006 10:14:29 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Mike Fratto Subject: Re: [Nea] IETF67 NEA WG Meeting summary References: <455A3D76.6070201@cs.utk.edu> <455AAD0A.8060309@cs.utk.edu> <455B24EC.4010700@cs.utk.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 >> I don't understand - what do you want me to list? examples of potential >> contents of someone's hard drive that a user might not want to be >> disclosed? > > I am asking you to list in clear and concise terms the "privacy > issues" you have. Is exposing the contents of a hard drive the only > issue you have, or are there more? oh, okay, I see what you mean now. exposing the contents of the hard drive isn't the only issue I'd have. exposing what is running on the cpu would be another issue, exposing what is talking to what network local or remote ports or addresses would be another, as would be exposing the existence of other network interfaces and what they're connected to. it's a bit hard to tell where the issues end, as the NEA charter is fairly ambiguous as to what constitutes "posture". Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Nov 15 11:33:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkNhy-0000go-Cl; Wed, 15 Nov 2006 11:33:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkNhw-0000gH-V7 for nea@ietf.org; Wed, 15 Nov 2006 11:33:52 -0500 Received: from wx-out-0506.google.com ([66.249.82.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkNhu-0005UL-CC for nea@ietf.org; Wed, 15 Nov 2006 11:33:52 -0500 Received: by wx-out-0506.google.com with SMTP id h29so289034wxd for ; Wed, 15 Nov 2006 08:33:50 -0800 (PST) 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=O1dk2P8VsHv3D3MMWk3wXFLD5q2Cq+VST7HcgkCHXlPESDdEFy0oZO8rlOt53MhnN027+dwIDw1kwNLrsFSeIagpYwTYzu8Ehsm7ceYhn8oNFKRog6DwDIZR3j84yG/vTTE/UrqsIQdeWj3qYuDZomAfAGiBFxilfmMhjp/Tg78= Received: by 10.90.105.20 with SMTP id d20mr2475880agc.1163608430151; Wed, 15 Nov 2006 08:33:50 -0800 (PST) Received: by 10.65.156.6 with HTTP; Wed, 15 Nov 2006 08:33:49 -0800 (PST) Message-ID: Date: Wed, 15 Nov 2006 11:33:49 -0500 From: "Mike Fratto" To: "Keith Moore" Subject: Re: [Nea] privacy: exposing information to owner In-Reply-To: <455B24AD.9090209@cs.utk.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <455B24AD.9090209@cs.utk.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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 On 11/15/06, Keith Moore wrote: > I don't agree with your assessment. But that is the scope of the charter. Enterprises, including corporations, academic institutions, non-profits, and govenment entities, where the network is wholly owned by the enterprise have the right within local laws to ask what ever they want. That is thier local policy. You as a user, say a contractor, guest, or employee, have the right to accept or decline thier policy. That is your local policy. If you are on a remote network and you computer is controlled by your enterprise, they have the right to say what will and will not be disclosed. That is a matter for your employers policy. The output of the NEA needs to provide ways to account for the different stake holders without dictating local policies. Besides, this is nothing new. Having guest users agree to an AUP is fairly standard practice. The NEA simply facilitates the granting of access. > > The endpoint should have a policy about what information it is > > willing to disclose and to whom. The network should have a policy > > about what information it requests, whether it will divulge its > > policies, and what access it is willing to grant. > > Strongly disagree with all of the above. For the most part, users > aren't sophisticated enough to determine what the policies on their > hosts should be. That is beside the point entirely. While vendors should make it easy for end users to make a determination about what data to share, there is no reason to compell them to do so. And even if there was a reason to compel them to do so, then your talking UI features which I think are out of scope. Perhaps a best practices document would be helpful to provide guidance in cases like this, but they are not show stoppers. > > If we're concerned about naive users, we can require that endpoints > > ship with NEA disabled and require explicit approval and > > administrative privileges to enable it or configure policy. > > doesn't solve the problem. Becuase there is no problem to solve. Accpetance of interrogation is a matter of agreeing to local policies. If the network policy is to assess a host and your, or your employers policy is to refuse assessments, then it is up to the network owner to decide what to do with your computer. There is no implicit right for a computer user to connect to a network. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Nov 15 11:38:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkNmj-0004AG-Ua; Wed, 15 Nov 2006 11:38:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkNmi-00049p-AY for nea@ietf.org; Wed, 15 Nov 2006 11:38:48 -0500 Received: from nz-out-0102.google.com ([64.233.162.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkNmh-000683-3X for nea@ietf.org; Wed, 15 Nov 2006 11:38:48 -0500 Received: by nz-out-0102.google.com with SMTP id k1so86454nzf for ; Wed, 15 Nov 2006 08:38:46 -0800 (PST) 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=Gj3rHfEcKTvsRRYziNDX7Y3numFnDJBuvjb3LMEe5+XWpLrkkpRV9vbQ5D/dWMj7QXlF7gDp2/zW1tsx2LWogXM2jNWxjSgs2LyVHRYTcKtrhn99Zco9WPVx6/l6Z/Ohc19NrmouuPJkx/53X1RG1ivU+lcTONMRogswA8+ajx4= Received: by 10.65.141.18 with SMTP id t18mr3641086qbn.1163608726350; Wed, 15 Nov 2006 08:38:46 -0800 (PST) Received: by 10.65.156.6 with HTTP; Wed, 15 Nov 2006 08:38:46 -0800 (PST) Message-ID: Date: Wed, 15 Nov 2006 11:38:46 -0500 From: "Mike Fratto" To: "Keith Moore" Subject: Re: [Nea] IETF67 NEA WG Meeting summary In-Reply-To: <455AB195.90900@cs.utk.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <455AB195.90900@cs.utk.edu> 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 > regarding NEA: what I might be okay with is giving authorized > third-parties yes or no assurance that the host meets or does not meet > their policies, without giving them fine-grained detail about what is > installed on the host. so the owner of a host could get details about > why a host did or did not fit within a particular network's policy, but > the network (if owned by another party than the owner of the host) could > only get yes or no information. I would like to see this option > examined further. Nothing is gained here regarding privacy. A validation server could glean what is installed by asking a series of questions and inferring the response. for example: Q: do you have software A, B, or C? A: No Q: do you have software D? A: Yes Ergo, host has software D. And if your so concerned about privacy, the network operator has a right to keep thier policies private so as not to give potential attackers specific knowlege about thier protective measures. I think a reasonable solution is one that Steve offered in the other thread where (to summarize), the endpoint, including the user, and the network agree on what will be shared during an assessment and then the network bases an access control decision on that assessment. Therefore, people with privacy concerns don't expose information and the network operator enforces local policy. Does that mean there may be cases where endpoints aren't allowed access? Sure does, but privacy, like access, has it's price. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Nov 15 13:15:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkPI4-0004eO-7O; Wed, 15 Nov 2006 13:15:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkPI3-0004eE-J1 for nea@ietf.org; Wed, 15 Nov 2006 13:15:15 -0500 Received: from elasmtp-junco.atl.sa.earthlink.net ([209.86.89.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkPI2-0002x5-5o for nea@ietf.org; Wed, 15 Nov 2006 13:15:15 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ndLEj+NwVbk9RdXnZWpQC5W0ElMyw+dtMBo+pQxSJa7ORGNIvnsBJeyGRkP/zgdA; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [4.246.235.163] (helo=gw) by elasmtp-junco.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GkPHz-0004jm-UD; Wed, 15 Nov 2006 13:15:13 -0500 Message-ID: <006301c708e2$00c24030$010aa8c0@home.glassey.com> From: "todd glassey" To: "Keith Moore" , "Stephen Hanna" References: <455B24AD.9090209@cs.utk.edu> Subject: Re: [Nea] privacy: exposing information to owner Date: Wed, 15 Nov 2006 10:14:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79a8b9c62cc9ba755af67c495a952abb37350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.246.235.163 X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d 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 SNIP - > > Commercial networks lie somewhere in between. They may be willing to > > grant Internet access if no information is available on the endpoint. > > Access to corporate resources will probably require some information > > and the amount of information required will probably depend on the > > sensitivity of the resources to be accessed (and on local > > regulations, as Pekka points out). > > > > It seems clear to me that this is an areas for local policy. > > I don't agree with your assessment. Just because a network to which a > host attaches might be run by (say) the military doesn't mean that it's > reasonable for an Internet standard to facilitate an arbitrary level of > surveillance or even to give the user a choice about how much > surveillance is allowed. I don't see any way to do this that will not > result, in practice, in users being forced to compromise their privacy > far beyond that which is reasonable. Kieth - "Is Reasonable" is an objective term & what you forgot to add is this: "Is reasonable by my way of thinking"... something that may not be shared by all here. > > > The endpoint should have a policy about what information it is > > willing to disclose and to whom. Funny Kieth I suggested exactly this two plus years ago as part of a policy negotiation framework inside PKIX and an integrity suite to implement it, which Stephen Kent and others slammed me to the mat for suggesting again and again... funny that eh? > > The network should have a policy > > about what information it requests, whether it will divulge its > > policies, and what access it is willing to grant. yes and that policy needs to be electronically negotiable to end-nodes that are connecting to its Extranets or Intranet services. > > The requirement for > > the NEA standards should be that they describe the security and > > privacy concerns inherent in this system, Not inherent in, but rather "Security and Privacy Concerns pertaing to that systems operation". Remember that the Privacy Concerns are not controlled by the IETF but rather by global courts and national legislation. So the IETF's play is not to 'pronounce something private' but rather to build processes that can be used to implement paperless processes where there is an inherent or built-in level of privacy specific to those law's requirements. > > describe how those concerns > > can be addressed, and require the protocols to include features that > > enable the endpoint and network to implement whatever policy they > > want. > >Then the endpoint and network owners can configure their > > policies with confidence. yes. This was the whole point of the Policy Communication Protocol I proposed to PKIX. > > One endpoint owner may disable NEA. Another > > may configure a policy of "Tell nothing but accept advice from my > > ISP". NEA could easily be tied to DHCP to prevent the installation of a lease or in infrastructure to prevent the routing of those 'bad' or 'unquialified' connections. > > Others may decide to disclose OS patch info to their corporate > > servers only. The military owner may configure a policy to disclose a > > full inventory but ONLY to authorized servers. > > Strongly disagree with all of the above. For the most part, users > aren't sophisticated enough to determine what the policies on their > hosts should be. But the NEA has nothing to do with users. Its a set of tools to demonstrate the continuing integrity of the systems its layered on. Its not setup (the NEA) to serve the individual but rather that individual's computer or workstation as a managed entity in a larger framework. > This makes them vulnerable to invasion of privacy - > first as individuals, as naive users succumb to pressure from networks > to grant more access than is necessary - and then market forces force > even the more sophisticated users to either accept this privacy erosion > for themselves or have their access severely limited. I've seen it > happen more times than I can count. So you offer here to protect the world from what? how technical things are? really? > > > For us to decide on a one-size-fits-all policy in this area would be > > impossible. > > perhaps, but that might mean that there is no reasonable solution to the > NEA approach, and a very different approach is needed. For what - ? a) Communicating policy requirements and agreeing to participate under those terms? b) For continuously analysing those systems under management and reporting on their operational integrity? i.e. are the policies met... ; and c) For raising some alarm if some stateful variable changes outside of its policy controls? My take is that there is a solution to the NEA approach, the problem is in understanding what each of the NEA flavors or 'agent-services' are to do. One use is clearly for security, one is for configuration management, one is for tracking use, one is for 'QoS'... etc etc etc. so what you really want is the 'anything and everything' daemon and protocol for it. Again - I proposed this type of tool sometime ago in my model, but I looked at implementing the policy control framework on a dat-0centric model that was based on bottom-up operations. So for me the first step in this is not in a top-level tool set but in integrating Syslog, NTP, and DNS into the same shell or framework. Once the messaging and event tracking system is seamless - then the addition of the policy controls of NEA make sense to me as an Auditor. > > > If we're concerned about naive users, we can require that endpoints > > ship with NEA disabled and require explicit approval and > > administrative privileges to enable it or configure policy. > > doesn't solve the problem. Which problem? Is that the problem that the end-users are naive? > > > Keith > > _______________________________________________ > 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 Nov 15 13:59:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkPyv-0007Ve-N8; Wed, 15 Nov 2006 13:59:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkPyv-0007VU-8z for nea@ietf.org; Wed, 15 Nov 2006 13:59:33 -0500 Received: from mailb.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkPyp-00057m-Vd for nea@ietf.org; Wed, 15 Nov 2006 13:59:32 -0500 Received: from tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.15; Wed, 15 Nov 2006 10:59:27 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) with Microsoft SMTP Server id 8.0.685.20; Wed, 15 Nov 2006 10:59:27 -0800 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.2786); Wed, 15 Nov 2006 10:59:26 -0800 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] IETF67 NEA WG Meeting summary Date: Wed, 15 Nov 2006 10:59:16 -0800 Message-ID: In-Reply-To: <455AAD0A.8060309@cs.utk.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] IETF67 NEA WG Meeting summary Thread-Index: AccIe56O16xgcGmcTrKKnt8fs9pP+AAZjwSg From: Khaja Ahmed To: X-OriginalArrivalTime: 15 Nov 2006 18:59:26.0896 (UTC) FILETIME=[2C1E3300:01C708E8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Keith Moore 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 The risk is indeed easy to understand. =20 It needs to have a mitigation mechanism and we need a mechanism that allows the owner of a host to explicitly choose to undertake the risk or not. By way of mitigation measure we can articulate a requirement that the protocol MUST be capable of employing some authentication measure to determine who is asking for the information. We should also have a requirement that the protocol MUST be run only when authorized. Meaning some mechanism in the host needs to explicitly allow the protocol to communicate information. There MAY, additionally, be fine grained controls that authorize specific sub-sets of the information based on identity/anonymity of the requestor. The authorization MAY allow that all requestors be provided the information requested. This is perfectly appropriate for situations that have other mitigating measures. For example a corporate server / desktop that is never expected to leave the building and / or be on any other network. As long as this is an explicit risk management choice made by the owner of the asset it should be fine. =20 Khaja -----Original Message----- From: Keith Moore [mailto:moore@cs.utk.edu]=20 Sent: Tuesday, November 14, 2006 10:01 PM To: Mike Fratto Cc: nea@ietf.org Subject: Re: [Nea] IETF67 NEA WG Meeting summary > Can you please move this entire thread elsewhere? It is not > sunstantive to the discussion of setting ID requirements. If you are > unwilling to do that, then how about adding something substantive. no, I'm not willing to move this thread elsewhere, because security and=20 privacy issues are at the crux of the problem that NEA must solve if it=20 is to meet rfc 2026 criteria and gain community consensus. > For example, Keith, you have referenced time and time again vague > risks to privacy. Can you spell out in clear and actionable terms > what those risks are? A bulleted list with a short description would > be useful. it's too simple a concept for a bulleted list. how difficult is it to understand that people don't want the contents of their hard drives to be subjected to arbitrary searches as a=20 precondition to being able to access networks? _______________________________________________ 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 Nov 15 15:46:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkReB-0002H9-75; Wed, 15 Nov 2006 15:46:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkReA-0002H2-4O for nea@ietf.org; Wed, 15 Nov 2006 15:46:14 -0500 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkRe8-0001PN-Ti for nea@ietf.org; Wed, 15 Nov 2006 15:46:14 -0500 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id BE949564E3; Wed, 15 Nov 2006 15:46:10 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjHQBG57UJfU; Wed, 15 Nov 2006 15:46:05 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 0F879564E2; Wed, 15 Nov 2006 15:46:03 -0500 (EST) Message-ID: <455B7C93.5060608@cs.utk.edu> Date: Wed, 15 Nov 2006 15:46:11 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Mike Fratto Subject: Re: [Nea] privacy: exposing information to owner References: <455B24AD.9090209@cs.utk.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 -------- Original Message -------- > On 11/15/06, Keith Moore wrote: >> I don't agree with your assessment. > > But that is the scope of the charter. Enterprises, including > corporations, academic institutions, non-profits, and govenment > entities, where the network is wholly owned by the enterprise have the > right within local laws to ask what ever they want. no they do not. I don't know where you get this idea, and I don't know why in the world you think IETF should bless any means to implement this. Nor do I understand why you think such a thing would ever meet the rfc 2026 requirements for standardization or get rough consensus from this community. we're here to do what's best for the Internet as a whole, not to build a surveillance mechanism to let networks spy on users. doing so is completely unacceptable. if that's what the WG thinks it's chartered to do, then the group should be shut down right now and stop wasting everyone's time. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Nov 15 15:47:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkRfI-0003L0-Jg; Wed, 15 Nov 2006 15:47:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkRfH-0003Kv-Ei for nea@ietf.org; Wed, 15 Nov 2006 15:47:23 -0500 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkRfG-0001ZS-6y for nea@ietf.org; Wed, 15 Nov 2006 15:47:23 -0500 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 9CFD4564E2; Wed, 15 Nov 2006 15:47:21 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFFIbwFEOKdS; Wed, 15 Nov 2006 15:47:11 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id F2160564EA; Wed, 15 Nov 2006 15:47:10 -0500 (EST) Message-ID: <455B7CD6.9080107@cs.utk.edu> Date: Wed, 15 Nov 2006 15:47:18 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Mike Fratto Subject: Re: [Nea] IETF67 NEA WG Meeting summary References: <455AB195.90900@cs.utk.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 -------- Original Message -------- >> regarding NEA: what I might be okay with is giving authorized >> third-parties yes or no assurance that the host meets or does not meet >> their policies, without giving them fine-grained detail about what is >> installed on the host. so the owner of a host could get details about >> why a host did or did not fit within a particular network's policy, but >> the network (if owned by another party than the owner of the host) could >> only get yes or no information. I would like to see this option >> examined further. > > Nothing is gained here regarding privacy. A validation server could > glean what is installed by asking a series of questions and inferring > the response. I already pointed out that the protocol would have to prevent this somehow. > I think a reasonable solution is one that Steve offered in the other > thread where (to summarize), the endpoint, including the user, and the > network agree on what will be shared during an assessment and then the > network bases an access control decision on that assessment. > Therefore, people with privacy concerns don't expose information and > the network operator enforces local policy. unacceptable, for reasons already given. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Nov 15 15:52:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkRkP-0006xl-7M; Wed, 15 Nov 2006 15:52:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkRkN-0006xF-TE for nea@ietf.org; Wed, 15 Nov 2006 15:52:39 -0500 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkRkM-0002ZT-KT for nea@ietf.org; Wed, 15 Nov 2006 15:52:39 -0500 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id A1AF0564FB; Wed, 15 Nov 2006 15:52:27 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from shu.cs.utk.edu ([127.0.0.1]) by localhost (shu.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8qQd2p1-1Af; Wed, 15 Nov 2006 15:52:03 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id E1149564EE; Wed, 15 Nov 2006 15:51:53 -0500 (EST) Message-ID: <455B7DEB.8080004@cs.utk.edu> Date: Wed, 15 Nov 2006 15:51:55 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Khaja Ahmed Subject: Re: [Nea] IETF67 NEA WG Meeting summary References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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 -------- Original Message -------- > The risk is indeed easy to understand. > > It needs to have a mitigation mechanism and we need a mechanism that > allows the owner of a host to explicitly choose to undertake the risk or > not. > > By way of mitigation measure we can articulate a requirement that the > protocol MUST be capable of employing some authentication measure to > determine who is asking for the information. > > We should also have a requirement that the protocol MUST be run only > when authorized. Meaning some mechanism in the host needs to explicitly > allow the protocol to communicate information. There MAY, additionally, > be fine grained controls that authorize specific sub-sets of the > information based on identity/anonymity of the requestor. The > authorization MAY allow that all requestors be provided the information > requested. This is perfectly appropriate for situations that have other > mitigating measures. For example a corporate server / desktop that is > never expected to leave the building and / or be on any other network. > As long as this is an explicit risk management choice made by the owner > of the asset it should be fine. I disagree, for reasons given earlier. It's not acceptable to allow an arbitrary network to ask arbitrary questions of a host, even if the user gets to control which questions are answered, because this provides a sufficient mechanism to coerce the user into giving up his privacy - either because the user doesn't understand the implications of his decisions (likely) or because the user doesn't, for practical purposes, have a choice (also likely). Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Nov 15 16:30:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkSKy-0004gX-2G; Wed, 15 Nov 2006 16:30:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkSKw-0004g1-HT for nea@ietf.org; Wed, 15 Nov 2006 16:30:26 -0500 Received: from mga03.intel.com ([143.182.124.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkSKu-00024d-7L for nea@ietf.org; Wed, 15 Nov 2006 16:30:26 -0500 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by mga03.intel.com with ESMTP; 15 Nov 2006 13:30:22 -0800 Received: from fmsmsx333.amr.corp.intel.com ([132.233.42.2]) by azsmga001.ch.intel.com with ESMTP; 15 Nov 2006 13:30:22 -0800 X-ExtLoop1: 1 X-IronPort-AV: i="4.09,425,1157353200"; d="gif'147?scan'147,208,217,147"; a="147036320:sNHT40189618" Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx333.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Nov 2006 13:30:22 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 15 Nov 2006 16:30:09 -0500 Message-ID: <279DDDAFA85EC74C9300A0598E704056F90F2C@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: NEA Req's team thread-index: AccI/Tm6Fa1h8o45R5qt+0MCXpVVPQ== From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 15 Nov 2006 21:30:22.0131 (UTC) FILETIME=[41756830:01C708FD] X-Spam-Score: 0.2 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Subject: [Nea] NEA Req's team 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="===============0957165216==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============0957165216== Content-class: urn:content-classes:message Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C708FD.3F9533C8" This is a multi-part message in MIME format. ------_=_NextPart_001_01C708FD.3F9533C8 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C708FD.3F9533C8" ------_=_NextPart_002_01C708FD.3F9533C8 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Susan, =20 I'll join the req's team. =20 Tnx! =20 Regards, Uri Opinions in this e-mail are strictly my personal ones, and not Intel's. =20 ------_=_NextPart_002_01C708FD.3F9533C8 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Blank
Susan,
 
I'll join the req's = team.
 
Tnx!
 
Regards,
Uri
<Disclaimer> Opinions in this e-mail are = strictly my=20 personal ones, and not Intel's.

 

------_=_NextPart_002_01C708FD.3F9533C8-- ------_=_NextPart_001_01C708FD.3F9533C8 Content-Type: image/gif; name="Blank Bkgrd.gif" Content-Transfer-Encoding: base64 Content-ID: <977362821@15112006-338B> Content-Description: Blank Bkgrd.gif Content-Location: Blank%20Bkgrd.gif R0lGODlhLQAtAID/AP////f39ywAAAAALQAtAEACcAxup8vtvxKQsFon6d02898pGkgiYoCm6sq2 7iqWcmzOsmeXeA7uPJd5CYdD2g9oPF58ygqz+XhCG9JpJGmlYrPXGlfr/Yo/VW45e7amp2tou/lW xo/zX513z+Vt+1n/tiX2pxP4NUhy2FM4xtjIUQAAOw== ------_=_NextPart_001_01C708FD.3F9533C8-- --===============0957165216== 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 --===============0957165216==-- From nea-bounces@ietf.org Wed Nov 15 17:54:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkTeG-00080j-TK; Wed, 15 Nov 2006 17:54:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkTeG-00080e-HE for nea@ietf.org; Wed, 15 Nov 2006 17:54:28 -0500 Received: from web42106.mail.mud.yahoo.com ([209.191.86.239]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GkTeE-0005ql-QT for nea@ietf.org; Wed, 15 Nov 2006 17:54:28 -0500 Received: (qmail 61432 invoked by uid 60001); 15 Nov 2006 22:46:02 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=oHLcYj63jJhH5LFUgxf8z0CqaXrqCCez/63CYfq4msr9WArv82/gx9eicNmZCy57VrJPT4GLFnsjGgwDNHKAvNkH4bYbrLfYD0JBmTMydAZgjU32+oTJmnLkkg6ImhZN4QBQTNmOtPJOr39eWVLp6I79lXA1V7uhQdUOKKEz3vo= ; Message-ID: <20061115224602.61429.qmail@web42106.mail.mud.yahoo.com> Received: from [66.134.79.50] by web42106.mail.mud.yahoo.com via HTTP; Wed, 15 Nov 2006 14:46:02 PST Date: Wed, 15 Nov 2006 14:46:02 -0800 (PST) From: Anil Gopinath To: nea@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.7 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Nea] Posture Broker 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 thinking about the role of the posture broker and was wondering if its a core (must be implemented) component of NEA architecture? For simpler implementations does it make sense for the posture validators to talk directly to the network access authority? Thanks, Anil ____________________________________________________________________________________ Sponsored Link Compare mortgage rates for today. Get up to 5 free quotes. Www2.nextag.com _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Nov 15 19:24:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkV2q-0004jU-KC; Wed, 15 Nov 2006 19:23:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkV2o-0004jN-Ps for nea@ietf.org; Wed, 15 Nov 2006 19:23:54 -0500 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkV2n-0001yu-CV for nea@ietf.org; Wed, 15 Nov 2006 19:23:54 -0500 Received: from unknown (HELO gamma.jnpr.net) ([172.24.245.25]) by borg.juniper.net with ESMTP; 15 Nov 2006 16:20:56 -0800 X-IronPort-AV: i="4.09,426,1157353200"; d="scan'208,217"; a="620391124:sNHT78149596" Received: from electron.jnpr.net ([172.24.15.21]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Nov 2006 16:23:52 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 15 Nov 2006 16:23:50 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: On end-point and network privacy issues, requirements, etc... Thread-Index: AccJFX19egL0GytZSU+ZLXnBvEHk3A== From: "Juan Gomez" To: X-OriginalArrivalTime: 16 Nov 2006 00:23:52.0503 (UTC) FILETIME=[7E861C70:01C70915] X-Spam-Score: 0.0 (/) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: Juan Gomez Subject: [Nea] On end-point and network privacy issues, requirements, etc... 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="===============0649588230==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============0649588230== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C70915.7E28DE62" This is a multi-part message in MIME format. ------_=_NextPart_001_01C70915.7E28DE62 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 1.-After reading most of the messages on this topic I think that having NEA endpoint/network negotiate to what level they are willing to disclose attributes (endpoints) and policies (network) will expand the scope of the WG and its applicability and perhaps is most desirable.=20 =20 2.-I seem to have read that some of the requirements being proposed include having NEA provide encryption and authentication: hopefully that means leveraging existing protocols that already exist and not bulking NEA with its own versions of those. =20 3.-Last, but not least :-), when endpoint and network are presented as adversaries, unwilling to disclose full information about each other, what ensures that the assertions resulting from one NEA negotiation/protocol query are reliable: say network queries the endpoint about attributes or network provides endpoint client with policies: what part of the protocol ensures the compliance assurance by the endpoint is reliable? Should this be a requirement too? =20 Regards, Juan Gomez =20 =20 =20 ------_=_NextPart_001_01C70915.7E28DE62 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

1.-After reading most of the messages on this topic I = think that having NEA endpoint/network negotiate to what level they are willing to disclose attributes (endpoints) and policies (network) will expand the = scope of the WG and its applicability and perhaps is most desirable. =

 

2.-I seem to have read that some of the requirements = being proposed include having NEA provide encryption and authentication: = hopefully that means leveraging existing protocols that already exist and not = bulking NEA with its own versions of those.

 

3.-Last, but not least J, when endpoint and network are presented as adversaries, unwilling to disclose = full information about each other, what ensures that the assertions resulting = from one NEA negotiation/protocol query are reliable: say network queries the = endpoint about attributes or network provides endpoint client with policies: what = part of the protocol ensures the compliance assurance by the endpoint is = reliable? Should this be a requirement too?

 

Regards, Juan Gomez

 

 

 

------_=_NextPart_001_01C70915.7E28DE62-- --===============0649588230== 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 --===============0649588230==-- From nea-bounces@ietf.org Wed Nov 15 20:15:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkVqo-0004Ab-FH; Wed, 15 Nov 2006 20:15:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkVqm-0004AV-P0 for nea@ietf.org; Wed, 15 Nov 2006 20:15:32 -0500 Received: from e33.co.us.ibm.com ([32.97.110.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkVqk-0000t9-U4 for nea@ietf.org; Wed, 15 Nov 2006 20:15:32 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.13.8/8.12.11) with ESMTP id kAG1FQpF003481 for ; Wed, 15 Nov 2006 20:15:26 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay02.boulder.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kAG1FQC1545570 for ; Wed, 15 Nov 2006 18:15:26 -0700 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 kAG1FQpg002718 for ; Wed, 15 Nov 2006 18:15:26 -0700 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 kAG1FP9v002706; Wed, 15 Nov 2006 18:15:25 -0700 In-Reply-To: <455B7C93.5060608@cs.utk.edu> Subject: Re: [Nea] privacy: exposing information to owner To: Keith Moore X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Frank Yeh Jr Date: Wed, 15 Nov 2006 17:15:19 -0800 X-MIMETrack: Serialize by Router on D03NM129/03/M/IBM(Release 7.0.2HF32 | October 17, 2006) at 11/15/2006 18:15:25 MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4fc59e88b356924367ae169e6a06365d 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="===============0146638509==" Errors-To: nea-bounces@ietf.org --===============0146638509== Content-type: multipart/alternative; Boundary="0__=07BBF8BBDF9107408f9e8a93df938690918c07BBF8BBDF910740" Content-Disposition: inline --0__=07BBF8BBDF9107408f9e8a93df938690918c07BBF8BBDF910740 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Greetings, IMHO this discussion of whether the protocol will enable invasion= of user's privacy is a non-sequiter. First of all, the NEA protocol is intended to allow the network t= o transport data between two endpoints on the network with one of these b= eing a host and one of them being a server that will make the decision on wh= at level of access to give to the host. Then the server also has a means t= o communicate with the network to tell it what access to allow the host a= nd potentially a way to remediate "violations" to policy so that subsequen= t attempts at access can be allowed. Saying that the user information is exposed to the network is actually There is nothing in the protocol that states WHAT the data being transmitted between the endpoints will be, that is going to be applicat= ion specific. As Keith Moore pointed out earlier with his cookie example, j= ust because a protocol is designed for one thing does not mean that it will= not be used for other purposes. So what the protocol will do is allow a ser= ver to ask a host for ANY conceivable set of data from that host and allow = this whole communication to happen in a secure network tunnel. With 802.1x a= s the Layer 2 protocol, the host does not have to have layer 3 connectivi= ty to participate in this conversation. To me, this is the value of the protocol. What people will say using it and what decisions they will ma= ke based on what is said are completely beyond the scope of the protocol. Saying that we are going to provide a tunnel for endpoints to communicate with each other over a standard protocol says nothing about= what the content will be, what decisions will be made based on what dat= a, or anything other than the fact that there is a channel for communicati= ons. So if the IETF does not support any protocols that could potentia= lly be used to transmit sensitive user data to others with or without that user's knowledge or assent, then perhaps IP should be elilminated as it= too allows for the invasion of user's privacy. HTTP_ check, let's eliminate= that too. SSH or SSL? Those are secure but they do allow user's private= information to be transmitted across that secure tunnel to another endp= oint so guess we'd better eliminate those too. Ooops, sarcasm now off. Consider that several successive access attempts, with remediatio= n sessions in between, can occur before a host gets admitted to a network= . The first thing checked can be whether the host is trying to comply to = the right policy, and the first remediation pass can update the policy to t= he desired one. There is also nothing to say that you could not specify several different policies, each with different requirements and differ= ent levels of network access based on compliance to them. So a user could g= et challenged and select which policy he wanted to comply with based on th= e leve l of access he desired, select the policy, get automatically remediated to comply with the selected policy and then be assigned the level of access indicated by the selected policy. It then becomes the user's choice about what he wants to reveal. In my personal experience, you will end up with users plugging in= and being redirected to something that says that they agree with some sort = of text that specifies the terms of their network access. They will then accept the EULA and that will eliminate any privacy issues for the netw= ork owner. Of course, they will simply click on the EULA without reading it= so they might unknowingly be agreeing to disclosing more than they want to= . I'd like the user experience to look something like this: - User plugs into the network and is authenticated and assessed. Us= ers are redirected to a web page that shows them the different levels of ac= cess they can select, what access levels are required for various purposes, = and the privacy implications of selecting the various levels. When they sel= ect a level, the must agree to a EULA that says they understand the privacy= implications of their decision. - Once the user selects a level, that defines the policy requiremen= ts and then the iterative process of remediating and reassessment begins. - Once the user is compliant to the selected level of policy, they = are admitted and their access level is indicated. The user could go to an entirely different network and have to co= mply with a different set of policies. He should have the option at either network to select what he wants to disclose based on what he wants to access. This is not perfect but it is significantly better than what is currently available. BTW, I'd like a little more clarification as to why you think tha= t network owners do not have the right to ask their users anything that locally applicable rules allow. The IETF does not dictate privacy laws.= A number of organizations sign contracts with labor unions tha say that t= hey cannot do things like monitor hosts to check on an employee's productiv= ity or attendance. They are then legally and contractually obligated to pro= tect that level of privacy. So if there is no applicable law and no contract= that prevents the network owner from doing so, what is it that you thin= k says they do not have the right? Regards, Frank Yeh Keith Moore wrote on 11/15/2006 12:46:11 PM: > > > -------- Original Message -------- > > > On 11/15/06, Keith Moore wrote: > >> I don't agree with your assessment. > > > > But that is the scope of the charter. Enterprises, including > > corporations, academic institutions, non-profits, and govenment > > entities, where the network is wholly owned by the enterprise have = the > > right within local laws to ask what ever they want. > > no they do not. I don't know where you get this idea, and I don't kn= ow > why in the world you think IETF should bless any means to implement > this. Nor do I understand why you think such a thing would ever meet= > the rfc 2026 requirements for standardization or get rough consensus > from this community. > > we're here to do what's best for the Internet as a whole, not to buil= d a > surveillance mechanism to let networks spy on users. doing so is > completely unacceptable. if that's what the WG thinks it's chartered= to > do, then the group should be shut down right now and stop wasting > everyone's time. > > Keith > > > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea= --0__=07BBF8BBDF9107408f9e8a93df938690918c07BBF8BBDF910740 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Greetings,

IMHO this discussion of whether the protocol will enable invasion of u= ser's privacy is a non-sequiter.

First of all, the NEA protocol is intended to allow the network to tra= nsport data between two endpoints on the network with one of these bein= g a host and one of them being a server that will make the decision on = what level of access to give to the host. Then the server also has a me= ans to communicate with the network to tell it what access to allow the= host and potentially a way to remediate "violations" to poli= cy so that subsequent attempts at access can be allowed. Saying that th= e user information is exposed to the network is actually

There is nothing in the protocol that states WHAT the data being trans= mitted between the endpoints will be, that is going to be application s= pecific. As Keith Moore pointed out earlier with his cookie example, ju= st because a protocol is designed for one thing does not mean that it w= ill not be used for other purposes. So what the protocol will do is all= ow a server to ask a host for ANY conceivable set of data from that hos= t and allow this whole communication to happen in a secure network tunn= el. With 802.1x as the Layer 2 protocol, the host does not have to have= layer 3 connectivity to participate in this conversation. To me, this = is the value of the protocol. What people will say using it and what de= cisions they will make based on what is said are completely beyond the = scope of the protocol.

Saying that we are going to provide a tunnel for endpoints to communic= ate with each other over a standard protocol says nothing about what th= e content will be, what decisions will be made based on what data, or a= nything other than the fact that there is a channel for communications.=

So if the IETF does not support any protocols that could potentially b= e used to transmit sensitive user data to others with or without that u= ser's knowledge or assent, then perhaps IP should be elilminated as it = too allows for the invasion of user's privacy. HTTP_ check, let's elimi= nate that too. SSH or SSL? Those are secure but they do allow user's pr= ivate information to be transmitted across that secure tunnel to anothe= r endpoint so guess we'd better eliminate those too.

Ooops, sarcasm now off.

Consider that several successive access attempts, with remediation ses= sions in between, can occur before a host gets admitted to a network. T= he first thing checked can be whether the host is trying to comply to t= he right policy, and the first remediation pass can update the policy t= o the desired one. There is also nothing to say that you could not spec= ify several different policies, each with different requirements and di= fferent levels of network access based on compliance to them. So a user= could get challenged and select which policy he wanted to comply with = based on the leve l of access he desired, select the policy, get automa= tically remediated to comply with the selected policy and then be assig= ned the level of access indicated by the selected policy. It then becom= es the user's choice about what he wants to reveal.

In my personal experience, you will end up with users plugging in and = being redirected to something that says that they agree with some sort = of text that specifies the terms of their network access. They will the= n accept the EULA and that will eliminate any privacy issues for the ne= twork owner. Of course, they will simply click on the EULA without read= ing it so they might unknowingly be agreeing to disclosing more than th= ey want to.

I'd like the user experience to look something like this:

- User plugs into the network and is authenticated and assessed. Users = are redirected to a web page that shows them the different levels of ac= cess they can select, what access levels are required for various purpo= ses, and the privacy implications of selecting the various levels. When= they select a level, the must agree to a EULA that says they understan= d the privacy implications of their decision.
- Once the user selects a level, that defines the policy requirements a= nd then the iterative process of remediating and reassessment begins. - Once the user is compliant to the selected level of policy, they are = admitted and their access level is indicated.

The user could go to an entirely different network and have to comply = with a different set of policies. He should have the option at either n= etwork to select what he wants to disclose based on what he wants to ac= cess.

This is not perfect but it is significantly better than what is curren= tly available.

BTW, I'd like a little more clarification as to why you think that net= work owners do not have the right to ask their users anything that loca= lly applicable rules allow. The IETF does not dictate privacy laws. A n= umber of organizations sign contracts with labor unions tha say that th= ey cannot do things like monitor hosts to check on an employee's produc= tivity or attendance. They are then legally and contractually obligated= to protect that level of privacy. So if there is no applicable law and= no contract that prevents the network owner from doing so, what is it = that you think says they do not have the right?

Regards,
Frank Yeh

Keith Moore <moore@cs.utk.edu> wrote on 11/15/2006 12:46:11 P= M:

>
>
> -------- Original Message --------
>
> > On 11/15/06, Keith Moore <moore@cs.utk.edu> wrote:
> >> I don't agree with your assessment.
> >
> > But that is the scope of the charter. Enterprises, including<= br> > > corporations, academic institutions, non-profits, and govenme= nt
> > entities, where the network is wholly owned by the enterprise= have the
> > right within local laws to ask what ever they want.
>
> no they do not.  I don't know where you get this idea, and I = don't know
> why in the world you think IETF should bless any means to implemen= t
> this.  Nor do I understand why you think such a thing would e= ver meet
> the rfc 2026 requirements for standardization or get rough consens= us
> from this community.
>
> we're here to do what's best for the Internet as a whole, not to b= uild a
> surveillance mechanism to let networks spy on users.  doing s= o is
> completely unacceptable.  if that's what the WG thinks it's c= hartered to
> do, then the group should be shut down right now and stop wasting =
> everyone's time.
>
> Keith
>
>
> _______________________________________________
> Nea mailing list
> Nea@ietf.org
> https://www= 1.ietf.org/mailman/listinfo/nea
= --0__=07BBF8BBDF9107408f9e8a93df938690918c07BBF8BBDF910740-- --===============0146638509== 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 --===============0146638509==-- From nea-bounces@ietf.org Thu Nov 16 09:02:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkhoj-00059h-Ka; Thu, 16 Nov 2006 09:02:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkhoi-00059b-KP for nea@ietf.org; Thu, 16 Nov 2006 09:02:12 -0500 Received: from bes.cs.utk.edu ([160.36.56.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkhoh-0007F3-6S for nea@ietf.org; Thu, 16 Nov 2006 09:02:12 -0500 Received: from localhost (localhost [127.0.0.1]) by bes.cs.utk.edu (Postfix) with ESMTP id 7D60CFD69; Thu, 16 Nov 2006 09:02:08 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from bes.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNuoKTkP5ZfU; Thu, 16 Nov 2006 09:01:57 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by bes.cs.utk.edu (Postfix) with ESMTP id A6E31FA8E; Thu, 16 Nov 2006 09:01:56 -0500 (EST) Message-ID: <455C6F5C.5090903@cs.utk.edu> Date: Thu, 16 Nov 2006 09:02:04 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Frank Yeh Jr Subject: Re: [Nea] privacy: exposing information to owner References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac 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 > IMHO this discussion of whether the protocol will enable invasion of > user's privacy is a non-sequiter. I don't think that word means what you think it means. > First of all, the NEA protocol is intended to allow the network to > transport data between two endpoints on the network with one of these > being a host and one of them being a server that will make the > decision on what level of access to give to the host. Then the server > also has a means to communicate with the network to tell it what > access to allow the host and potentially a way to remediate > "violations" to policy so that subsequent attempts at access can be > allowed. Saying that the user information is exposed to the network > is actually Not sure where you were going here... > There is nothing in the protocol that states WHAT the data being > transmitted between the endpoints will be, that is going to be > application specific. Well, the protocol doesn't exist yet, and we're trying to determine requirements for that protocol, and a necessary part of determining requirements is to consider security issues, including privacy issues. Clearly a consideration of privacy issues involves a discussion of WHAT the data being transmitted between the endpoints can be. There is an inherent conflict between the need to provide some privacy protection for the user and the (IMHO naive) desire to make this protocol arbitrarily flexible for the benefit of the network operator. > As Keith Moore pointed out earlier with his cookie example, just > because a protocol is designed for one thing does not mean that it > will not be used for other purposes. So what the protocol will do is > allow a server to ask a host for ANY conceivable set of data from > that host and allow this whole communication to happen in a secure > network tunnel. This does not follow, and if the NEA group were to try to define the protocol in that way, IMHO it would be extremely unlikely to gain IETF consensus and subsequent standardization. That and if I were on IESG (I'm not) the failure of the NEA group to adequately consider privacy in its requirements would be a clear indicator that the group should be shut down rather than be allowed to have its charter extended to actually develop the protocol under discussion. Finally the failure to consider what is best for the Internet as a whole is a violation of IETF process which should make the group's work vulnerable to being overturned on appeal. > With 802.1x as the Layer 2 protocol, the host does not have to have > layer 3 connectivity to participate in this conversation. To me, this > is the value of the protocol. What people will say using it and what > decisions they will make based on what is said are completely beyond > the scope of the protocol. Strongly disagree. The entire purpose of a requirements discussion is to narrow the potential solution space and scope of the protocol. > Saying that we are going to provide a tunnel for endpoints to > communicate with each other over a standard protocol says nothing > about what the content will be, what decisions will be made based on > what data, or anything other than the fact that there is a channel > for communications. That would be true if that were what we were doing. But we're not doing that. > So if the IETF does not support any protocols that could potentially > be used to transmit sensitive user data to others with or without > that user's knowledge or assent, then perhaps IP should be > elilminated as it too allows for the invasion of user's privacy. > HTTP_ check, let's eliminate that too. SSH or SSL? Those are secure > but they do allow user's private information to be transmitted across > that secure tunnel to another endpoint so guess we'd better > eliminate those too. Nope. See, the entire point of ssh (to give an example) is to allow authorized users to be able to run commands under their account on the server machine. ssh users are aware of this purpose, and act accordingly. They don't enable ssh on their machines unless they want authorized users to be able to log in to their accounts over the network. OTOH, the entire point of NEA is to allow networks to determine whether a host is safe to connect to the network, NOT to allow networks to conduct espionage on hosts that connect to their networks. > Consider that several successive access attempts, with remediation > sessions in between, can occur before a host gets admitted to a > network. The first thing checked can be whether the host is trying to > comply to the right policy, and the first remediation pass can > update the policy to the desired one. There is also nothing to say > that you could not specify several different policies, each with > different requirements and different levels of network access based > on compliance to them. So a user could get challenged and select > which policy he wanted to comply with based on the leve l of access > he desired, select the policy, get automatically remediated to comply > with the selected policy and then be assigned the level of access > indicated by the selected policy. It then becomes the user's choice > about what he wants to reveal. > > In my personal experience, you will end up with users plugging in and > being redirected to something that says that they agree with some > sort of text that specifies the terms of their network access. They > will then accept the EULA and that will eliminate any privacy issues > for the network owner. But the network owner is not the only party whose interests need to be considered. > I'd like the user experience to look something like this: [deleted] I don't see any reason why IETF should endorse a protocol that (a) allows network providers to conduct arbitrarily surveillance of hosts and (b) trusts network providers to be honest about what kinds of surveillance users are being subjected to. That's completely insecure. > The user could go to an entirely different network and have to comply > with a different set of policies. He should have the option at > either network to select what he wants to disclose based on what he > wants to access. I do not accept the argument that users will have adequate choice of networks to which to connect. Faith in market forces to solve these problems is, in general, misguided. In my experience that kind of argument is usually used as an excuse to justify deliberately creating a condition where consumers' interests are harmed. An IETF working group should not be trying to create market conditions that favor network providers' interests over those of consumers. And I don't think you'll be able to get community consensus to do that, especially not after various privacy groups get wind of what some people here are trying to do. > BTW, I'd like a little more clarification as to why you think that > network owners do not have the right to ask their users anything that > locally applicable rules allow. I'd like more clarification as to why you think that they do. But that's not what's relevant. What's relevant is why the IETF should endorse a protocol that allows networks to ask arbitrary questions of hosts, and in effect, to conduct surveillance of the internal state of those hosts - when such a protocol is clearly harmful to users' interests. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Nov 16 15:11:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GknZ8-0001xX-Rd; Thu, 16 Nov 2006 15:10:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GknZ6-0001ud-1W for nea@ietf.org; Thu, 16 Nov 2006 15:10:28 -0500 Received: from b.mail.sonic.net ([64.142.19.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GknZ4-0004bV-Lo for nea@ietf.org; Thu, 16 Nov 2006 15:10:28 -0500 Received: from [168.61.10.136] (SJC-Office-DHCP-136.Mail-Abuse.ORG [168.61.10.136]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id kAGKALxO000735 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 16 Nov 2006 12:10:22 -0800 In-Reply-To: <455AB195.90900@cs.utk.edu> References: <455AB195.90900@cs.utk.edu> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2E6BCAC4-47D8-41E8-AC27-95EFFD379BB7@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [Nea] third-party assurances Date: Thu, 16 Nov 2006 12:10:20 -0800 To: Keith Moore X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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 On Nov 14, 2006, at 10:20 PM, Keith Moore wrote: > regarding NEA: what I might be okay with is giving authorized third- > parties yes or no assurance that the host meets or does not meet > their policies, without giving them fine-grained detail about what > is installed on the host. Certificates obtained from third-party services can meet this requirement. These third-party services might be as simple as a web- site and agreeing to the AUP. Clicking yes presents the time-stamped NEA certificate that is placed into the NEA repository. The NEA repository should permit profiles where the user can limit which certificates can be seen by specific NEA servers. This approach replaces modifications to DNS redirecting browsers to a specific web page, for example. Not all systems will be using a browser or be used directly by a human. When a provider detects malicious activity, some type of non-optional compliance requirement might be instantiated. Limiting access to bots better ensures more draconian measures are not taken. The market place of access providers is not exceedingly diverse, where I share some of your concerns regarding how NEA might be misused. The number of systems running a cloned corporate version of Windows unable to apply patches is placing the network at risk. How is that problem best addressed? It seems a good method for dealing with this problem is to enable a means for dealing with bots in an automated fashion. There is simply little a provider will do to help customers restore their pirated OS. Asking for evidence of remediation from an array of third- parties selected by these users seems to be one such approach. When there is a compliance failure, the user should be offered a list of choices, and not automated by default. The provider can indicate the services they consider acceptable by presenting their version of the certificates with their hostmaster@ id. > so the owner of a host could get details about why a host did or > did not fit within a particular network's policy, but the network > (if owned by another party than the owner of the host) could only > get yes or no information. I would like to see this option > examined further. The only information that might be available could be limited to which certs were presented together with their time-stamp. -Doug _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Nov 16 19:25:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkrXi-0007oS-EP; Thu, 16 Nov 2006 19:25:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkrXh-0007mH-2D for nea@ietf.org; Thu, 16 Nov 2006 19:25:17 -0500 Received: from hu-out-0506.google.com ([72.14.214.237]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkrXa-0005HY-UF for nea@ietf.org; Thu, 16 Nov 2006 19:25:17 -0500 Received: by hu-out-0506.google.com with SMTP id 38so277308huc for ; Thu, 16 Nov 2006 16:25:07 -0800 (PST) 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=M0e2H1GmEA9C6fZjwHFWbfq/2Nnf8WVaKZR0bONW/Y5n/AU1hOCVreBZKWy4mncviLCSd7MEpXb1zGph0rISpJt4qm2SrH0HGvRW/qx5c1/x3n9Tbe4tBYw8/tbMWUP/ttkwzVkHWxXZt0c6gd8keCQCCvi69oGHMmDs5hJNm6I= Received: by 10.67.91.6 with SMTP id t6mr1803946ugl.1163723106853; Thu, 16 Nov 2006 16:25:06 -0800 (PST) Received: by 10.67.97.9 with HTTP; Thu, 16 Nov 2006 16:25:06 -0800 (PST) Message-ID: Date: Thu, 16 Nov 2006 16:25:06 -0800 From: "Sean Convery" To: "Keith Moore" Subject: Re: Re: [Nea] privacy: exposing information to owner In-Reply-To: <455C6F5C.5090903@cs.utk.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <455C6F5C.5090903@cs.utk.edu> X-Spam-Score: 1.9 (+) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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 Hi Keith, On 11/16/06, Keith Moore wrote: > I don't see any reason why IETF should endorse a protocol that (a) > allows network providers to conduct arbitrarily surveillance of hosts > and (b) trusts network providers to be honest about what kinds of > surveillance users are being subjected to. That's completely insecure. > I agree with your privacy concerns and your point that managed assets of an organization will connect to networks that aren't managed by the organization. This means we can't just assume a company X asset will only connect to a company X network. As you know, there are a host of techniques on the Internet today which farm information from unsuspecting users and you are right to point out that NEA is potentially a new one. Pop-ups to authorize such queries are certainly not ideal by themselves. I am concerned that users will tend to just click "yes" much like they do today when connecting to a web site with an invalid certificate. However, I fundamentally believe in the benefit NEA provides to organizations. When I think of your objections while reading through this long thread, I'm reminded of Bill Joy's essay "Why the Future Doesn't Need Us." In it, he says, "The only realistic alternative I see is relinquishment: to limit development of the technologies that are too dangerous, by limiting our pursuit of certain kinds of knowledge." This is an ultimately unsatisfying conclusion and Joy himself admits as much towards the end of the essay when he writes "I'm trying to imagine some better answers..." What NEA is dealing with is nowhere near the magnitude of self-replicating nano-machines and the other things Joy was concerned with but that doesn't mean we should dismiss NEA's privacy concerns. For me the question should be, "How do we sufficiently protect the organization and end user from disclosing information that would be harmful to them?" I'm unwilling to cede NEA because we think a user prompt will simply be bypassed. We're smart folks, I'm sure we can think of something. Bringing this around to the requirements, I think Khaja's amendment to your requirement seems reasonable: (NEA MUST NOT expose information about a host to any party other than the owner of that host or to parties authorized by the owner.) Ensuring that the user and owner are sufficiently aware of the risk in disclosure seems to fall into the realm of implementation. This sounds very much like the work Kim Cameron and co. are doing with infocards by providing ways for users to choose the profile of identity information they are willing to provide. Can you think of a better way to represent this requirement which still allows hosts to connect to multiple networks? What is happening in the marketplace today in the absence of standards is downloadable ActiveX controls are being embedded within captive portals at network login. In order to connect to a network you have to agree to install this applet which scans your system for compliance. In this situation you have no controls over what information is provided. This is clearly bad. Standards would at least give the user control over the client element and could configure it to disclose only what they wanted to. One option down the road is federation. Imagine a company X asset connects to a company X network and gets a normal scan done: nothing which violates your original requirement. Then at the end the asset is provided with a certificate signed by company X stating that the machine is running the latest patch, latest AV file, etc, whatever company X is comfortable providing within the certificate. Then when that asset connects to company Y's network it is authorized to present the certificate only (which might not even list the specific AV vendor, just that it is current). No additional information can be sent regardless of what the user is willing to consent to. Then if X and Y trust each other's assessments they are done. I realize this isn't ideal, but it tries to address your concern around novice users. I'm sure there are other ideas out there. Thanks, Sean Off topic: If there are folks on the list who haven't read Bill Joy's essay it was in Wired 8.04 and I highly recommend it: http://www.wired.com/wired/archive/8.04/joy.html _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Nov 16 19:58:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gks4B-0005NU-MV; Thu, 16 Nov 2006 19:58:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gks4A-0005NO-Mv for nea@ietf.org; Thu, 16 Nov 2006 19:58:50 -0500 Received: from ka.cs.utk.edu ([160.36.56.221]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gks48-0001Sp-CD for nea@ietf.org; Thu, 16 Nov 2006 19:58:50 -0500 Received: from localhost (localhost [127.0.0.1]) by ka.cs.utk.edu (Postfix) with ESMTP id A86382F268; Thu, 16 Nov 2006 19:58:47 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from ka.cs.utk.edu ([127.0.0.1]) by localhost (ka.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwhyAx+V1jrz; Thu, 16 Nov 2006 19:58:41 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by ka.cs.utk.edu (Postfix) with ESMTP id 2EE0B2F267; Thu, 16 Nov 2006 19:58:41 -0500 (EST) Message-ID: <455D094A.1000801@cs.utk.edu> Date: Thu, 16 Nov 2006 19:58:50 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Sean Convery Subject: Re: [Nea] privacy: exposing information to owner References: <455C6F5C.5090903@cs.utk.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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 Sean, thanks for the thoughtful and detailed comments. on reading your message I realize that trying to lump both the privacy concerns and the user interface/user naivete concerns into a single requirement potentially makes that single requirement overbroad and glosses over important issues that need more detailed examination. so I'm thinking that it should be separated along something like these lines: - the protocol MUST NOT release information about a host to third parties (other than the owner) absent explicit consent by both the owner and user to release that information to each specific party - owners and users MUST have explicit control over the kinds of information disclosed to third parties - owners and users MUST be able to control the information which is allowed to be released on a per-party basis - owners and users MUST be able to revoke or alter previously-granted consent - the model by which owners and users consent to release of information MUST be easily understood by ordinary users. (note here that either too-fine-grained control or too-coarse-grained control can thwart understanding) (MUST is probably a bit overused above, but I don't feel like doing much much wordsmithing at present - I'm mostly trying to identify the areas of concern.) I don't think I agree that "Ensuring that the user and owner are sufficiently aware of the risk in disclosure seems to fall into the realm of implementation." implementation clearly plays a role, but so does protocol design - at least in the selection of questions that a network can ask of a host. I am increasingly skeptical that this can be done, especially if the questions that a network can ask are implementation specific. I'm also skeptical that implementors can be trusted with presenting users with a clear picture of the risks they are taking - particularly when some implementors will probably have a conflict of interest there (say if a particular NEA implementor also sells other software and it wants to levy its NEA implementations to make sure that such software hasn't been patched, it's licenses are paid up, etc.) . > This sounds very much like the work Kim Cameron and co. are doing with infocards > by providing ways for users to choose the profile of identity > information they are willing to provide. Can you think of a better > way to represent this requirement which still allows hosts to connect > to multiple networks? something like profiles is probably what is needed in order to make this simple enough for users to understand. > One option down the road is federation. Imagine a company X asset > connects to a company X network and gets a normal scan done: nothing > which violates your original requirement. Then at the end the asset > is provided with a certificate signed by company X stating that the > machine is running the latest patch, latest AV file, etc, whatever > company X is comfortable providing within the certificate. Then when > that asset connects to company Y's network it is authorized to > present the certificate only (which might not even list the specific > AV vendor, just that it is current). No additional information can be > sent regardless of what the user is willing to consent to. Then if X > and Y trust each other's assessments they are done. worth further investigation, I think. thanks again, Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Nov 16 22:06:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gku3N-0007dp-Bw; Thu, 16 Nov 2006 22:06:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gku3L-0007de-6O for nea@ietf.org; Thu, 16 Nov 2006 22:06:07 -0500 Received: from e35.co.us.ibm.com ([32.97.110.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gku3I-0001IE-Q1 for nea@ietf.org; Thu, 16 Nov 2006 22:06:07 -0500 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.13.8/8.12.11) with ESMTP id kAH361rl014588 for ; Thu, 16 Nov 2006 22:06:01 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kAH361DT258962 for ; Thu, 16 Nov 2006 20:06:01 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kAH360id017709 for ; Thu, 16 Nov 2006 20:06:00 -0700 Received: from d03nm129.boulder.ibm.com (d03nm129.boulder.ibm.com [9.17.195.155]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kAH360YS017703; Thu, 16 Nov 2006 20:06:00 -0700 In-Reply-To: <455D094A.1000801@cs.utk.edu> Subject: Re: [Nea] privacy: exposing information to owner To: Keith Moore X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Frank Yeh Jr Date: Thu, 16 Nov 2006 19:05:54 -0800 X-MIMETrack: Serialize by Router on D03NM129/03/M/IBM(Release 7.0.2HF32 | October 17, 2006) at 11/16/2006 20:06:00 MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 90fbdaf3c139ce803b358d56775b59ed 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="===============1685430759==" Errors-To: nea-bounces@ietf.org --===============1685430759== Content-type: multipart/alternative; Boundary="0__=07BBF8BADF99FF978f9e8a93df938690918c07BBF8BADF99FF97" Content-Disposition: inline --0__=07BBF8BADF99FF978f9e8a93df938690918c07BBF8BADF99FF97 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Greetings, Keith Moore wrote on 11/16/2006 04:58:50 PM: > Sean, > > thanks for the thoughtful and detailed comments. > > on reading your message I realize that trying to lump both the privac= y > concerns and the user interface/user naivete concerns into a single > requirement potentially makes that single requirement overbroad and > glosses over important issues that need more detailed examination. > > so I'm thinking that it should be separated along something like thes= e > lines: > > - the protocol MUST NOT release information about a host to third > parties (other than the owner) absent explicit consent by both the ow= ner > and user to release that information to each specific party > - owners and users MUST have explicit control over the kinds of > information disclosed to third parties > - owners and users MUST be able to control the information which is > allowed to be released on a per-party basis > - owners and users MUST be able to revoke or alter previously-granted= > consent > - the model by which owners and users consent to release of informati= on > MUST be easily understood by ordinary users. (note here that either > too-fine-grained control or too-coarse-grained control can thwart > understanding) > > (MUST is probably a bit overused above, but I don't feel like doing m= uch > much wordsmithing at present - I'm mostly trying to identify the area= s > of concern.) > > I don't think I agree that "Ensuring that the user and owner are > sufficiently aware of the risk in disclosure seems to fall into the > realm of implementation." implementation clearly plays a role, but s= o > does protocol design - at least in the selection of questions that a > network can ask of a host. I am increasingly skeptical that this can= be > done, especially if the questions that a network can ask are > implementation specific. I'm also skeptical that implementors can be= > trusted with presenting users with a clear picture of the risks they = are > taking - particularly when some implementors will probably have a > conflict of interest there (say if a particular NEA implementor also > sells other software and it wants to levy its NEA implementations to > make sure that such software hasn't been patched, it's licenses are p= aid > up, etc.) . > > I'm still perplexed as to why you word things as if the network i= s asking the host for anything other than the normal sort of information= that is used to establish network connections. This is all the the netw= ork will be doing as far as direct communication with the host. The sensiti= ve information will, by design, be opaque to the network and only visible = to a validation server on the other end of the tunnel. This server will have= a way to communicate what access level to give to the host and a way to s= end the host someplace to find out what happened and what to do next. That = is about the extent of the network's involvement. Okay, got that bit of irrelevance off my chest. The owner of the network and the validation server will be the same in most cases, so ac= cess to that information is the point and knowledge by the user of what is b= eing disclosed is important. I still maintain that the content of what is transported by the network in a secure tunnel that is designed to prote= ct that content is not the business of the network doing the transporting.= It is a Layer 7 and above thing. There are all sorts of standard protocols= that could be used to transport private information, but there is a bin= ary difference in them based on the user's knowledge of what is being transported. FTP and TELNET are voluntary, cookies are stealthy. FTP go= od, cookies bad. So here's how stuff works in a lot of enterprises now. You have t= o install the client software and there is a EULA that you agree to. You = sign an agreement to follow the policies and guidelines of the company. The company owns the laptop you are using. When you plug in to the network = that the company owns, the client software automatically learns of any new policy changes. You can see what the data being collected is if you wan= t to take the trouble to look. If you are not in compliance, you get a popup= telling you to fix it and if you don't, after a period of time your man= ager gets emailed. There is no network enforcement yet, but all of the rest = of it is already being done. We have boatloads of lawyers who look at this= stuff all the time, so legally I figure this is a precedent. Now let's add in network enforcement. We are already transporting= the data so all we are adding is the ability to constrain network access ba= sed on what is found. I guess what we are asking is does the network want t= o be an accomplice to this sort of thing? There are already proprietary ways= of doing the network enforcement thing on top of everything else. Cisco's = NAC, MicroSoft's NAP, TCG's TNC give people a way to do this now or in the n= ear future. IMHO this situation would benefit from an IETF standard. So let's look for some middle ground. I'm hoping that you'll acce= pt for the sake of argument that the network cannot prevent people from do= ing what you fear will be done_ invading other people's privacy to some ext= ent. If the network were to take an active part in doing the endpoint assess= ment it might be able to better control what was being disclosed. A reasonab= le example would be SNMP, where the types of data to be transported are registered in MIBs. If there were a way to define a sort if MIB structu= re to define the types of assessment data being transmitted and nothing th= at was not registered could be transmitted, would that provide a better me= ans of control? This is outside the scope of the existing non-standard protocols and probably outside of the charter but would it make people = with your perspective more comfortable with the idea? Would it be better if all of the data was analyzed on the client = and only a status was returned to the server? This is done today by some solutions but you then run into the problem of trusting the client's evaluation, which it turns out is better if you can protect the client = with trusted hardware. Even if all the data itself is transported, you still= have to establish trust in the client to trust the data so the status i= s simpler and just as valid. In this model, the policy is sent to the cli= ent and includes the requirements and information on how to achieve complia= nce. The client evalautes itself and uses the information to get into a compliant state before re-attempting access. Again, this is just how ou= r application works and it is completely outside of the scope of the non-standard protocols we are discussing. We just liked the fact that t= he validation load was distributed on the clients rather than the server f= or things like black tuesdays. > > This sounds very much like the work Kim Cameron and co. are doing > with infocards > > by providing ways for users to choose the profile of identity > > information they are willing to provide. Can you think of a better > > way to represent this requirement which still allows hosts to conne= ct > > to multiple networks? > > something like profiles is probably what is needed in order to make t= his > simple enough for users to understand. > I agree. EULA's suck. > > > One option down the road is federation. Imagine a company X asset > > connects to a company X network and gets a normal scan done: nothin= g > > which violates your original requirement. Then at the end the asset= > > is provided with a certificate signed by company X stating that the= > > machine is running the latest patch, latest AV file, etc, whatever > > company X is comfortable providing within the certificate. Then whe= n > > that asset connects to company Y's network it is authorized to > > present the certificate only (which might not even list the specifi= c > > AV vendor, just that it is current). No additional information can = be > > sent regardless of what the user is willing to consent to. Then if= X > > and Y trust each other's assessments they are done. > In a recent survey of fortune 500 CIO's, one response to the ques= tion "what keeps you awake at night" was "fraud in the supply chain". Federa= tion is valuable and slowly happening, but how does federation help you with= your own users? You have to establish trust with them before you hand t= hem off to a partner who is trusting you. Wouldn't it be nice to say that t= he host being handed off is known to have the latest patches and virus upd= ates and has scanned for viruses today? Wouldn't it be nice to demand this o= f hosts being handed off to you? > worth further investigation, I think. > > thanks again, > > Keith > > If you really feel that this protocol should dictate what content= is transported between the endpoints then I think that would be a change i= n charter. Regards, Frank Yeh Corporate Security Strategy Team IBM Tivoli Software= --0__=07BBF8BADF99FF978f9e8a93df938690918c07BBF8BADF99FF97 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Greetings,

Keith Moore <moore@cs.utk.edu> wrote on 11/16/2006 04:58:50 P= M:

> Sean,
>
> thanks for the thoughtful and detailed comments.
>
> on reading your message I realize that trying to lump both the pri= vacy
> concerns and the user interface/user naivete concerns into a singl= e
> requirement potentially makes that single requirement overbroad an= d
> glosses over important issues that need more detailed examination.=
>
> so I'm thinking that it should be separated along something like t= hese
> lines:
>
> - the protocol MUST NOT release information about a host to third<= br> > parties (other than the owner) absent explicit consent by both the= owner
> and user to release that information to each specific party
> - owners and users MUST have explicit control over the kinds of > information disclosed to third parties
> - owners and users MUST be able to control the information which i= s
> allowed to be released on a per-party basis
> - owners and users MUST be able to revoke or alter previously-gran= ted
> consent
> - the model by which owners and users consent to release of inform= ation
> MUST be easily understood by ordinary users.  (note here that= either
> too-fine-grained control or too-coarse-grained control can thwart<= br> > understanding)
>
> (MUST is probably a bit overused above, but I don't feel like doin= g much
> much wordsmithing at present - I'm mostly trying to identify the a= reas
> of concern.)
>
> I don't think I agree that "Ensuring that the user and owner = are
> sufficiently aware of the risk in disclosure seems to fall into th= e
> realm of implementation."  implementation clearly plays = a role, but so
> does protocol design - at least in the selection of questions that= a
> network can ask of a host.  I am increasingly skeptical that = this can be
> done, especially if the questions that a network can ask are
> implementation specific.  I'm also skeptical that implementor= s can be
> trusted with presenting users with a clear picture of the risks th= ey are
> taking - particularly when some implementors will probably have a =
> conflict of interest there (say if a particular NEA implementor al= so
> sells other software and it wants to levy its NEA implementations = to
> make sure that such software hasn't been patched, it's licenses ar= e paid
> up, etc.) .
>
>

I'm still perplexed as to why you word things as if the network is= asking the host for anything other than  the normal sort of infor= mation that is used to establish network connections. This is all the t= he network will be doing as far as direct communication with the host. = The sensitive information will, by design, be opaque to the network and= only visible to a validation server on the other end of the tunnel. Th= is server will have a way to communicate what access level to give to t= he host and a way to send the host someplace to find out what happened = and what to do next. That is about the extent of the network's involvem= ent.

Okay, got that bit of irrelevance off my chest. The owner of the n= etwork and the validation server will be the same in most cases, so acc= ess to that information is the point and knowledge by the user of what = is being disclosed is important. I still maintain that the content of w= hat is transported by the network in a secure tunnel that is designed t= o protect that content is not the business of the network doing the tra= nsporting. It is a Layer 7 and above thing. There are all sorts of stan= dard protocols that could be used to transport private information, but= there is a binary difference in them based on the user's knowledge of = what is being transported. FTP and TELNET are voluntary, cookies are st= ealthy. FTP good, cookies bad.

So here's how stuff works in a lot of enterprises now. You have to= install the client software and there is a EULA that you agree to. You= sign an agreement to follow the policies and guidelines of the company= . The company owns the laptop you are using. When you plug in to the ne= twork that the company owns, the client software automatically learns o= f any new policy changes. You can see what the data being collected is = if you want to take the trouble to look. If you are not in compliance, = you get a popup telling you to fix it and if you don't, after a period = of time your manager gets emailed. There is no network enforcement yet,= but all of the rest of it is already being done. We have boatloads of = lawyers who look at this stuff all the time, so legally I figure this i= s a precedent.

Now let's add in network enforcement. We are already transporting = the data so all we are adding is the ability to constrain network acces= s based on what is found. I guess what we are asking is does the networ= k want to be an accomplice to this sort of thing? There are already pro= prietary ways of doing the network enforcement thing on top of everythi= ng else. Cisco's NAC, MicroSoft's NAP, TCG's TNC give people a way to d= o this now or in the near future. IMHO this situation would benefit fro= m an IETF standard.

So let's look for some middle ground. I'm hoping that you'll accep= t for the sake of argument that the network cannot prevent people from = doing what you fear will be done_ invading other people's privacy to so= me extent. If the network were to take an active part in doing the endp= oint assessment it might be able to better control what was being discl= osed. A reasonable example would be SNMP, where the types of data to be= transported are registered in MIBs. If there were a way to define a so= rt if MIB structure to define the types of assessment data being transm= itted and nothing that was not registered could be transmitted, would t= hat provide a better means of control? This is outside the scope of the= existing non-standard protocols and probably outside of the charter bu= t would it make people with your perspective more comfortable with the = idea?

Would it be better if all of the data was analyzed on the client a= nd only a status was returned to the server? This is done today by some= solutions but you then run into the problem of trusting the client's e= valuation, which it turns out is better if you can protect the client w= ith trusted hardware. Even if all the data itself is transported, you s= till have to establish trust in the client to trust the data so the sta= tus is simpler and just as valid. In this model, the policy is sent to = the client and includes the requirements and information on how to achi= eve compliance. The client evalautes itself and uses the information to= get into a compliant state before re-attempting access. Again, this is= just how our application works and it is completely outside of the sco= pe of the non-standard protocols we are discussing. We just liked the f= act that the validation load was distributed on the clients rather than= the server for things like black tuesdays.

> > This sounds very much like the work Kim Cameron and co. a= re doing
> with infocards
> > by providing ways for users to choose the profile of identity=
> > information they are willing to provide. Can you think of a b= etter
> > way to represent this requirement which still allows hosts to= connect
> > to multiple networks?
>
> something like profiles is probably what is needed in order to mak= e this
> simple enough for users to understand.
>

I agree. EULA's suck.

>
> > One option down the road is federation. Imagine a company X a= sset
> > connects to a company X network and gets a normal scan done: = nothing
> > which violates your original requirement. Then at the end the= asset
> > is provided with a certificate signed by company X stating th= at the
> > machine is running the latest patch, latest AV file, etc, wha= tever
> > company X is comfortable providing within the certificate. Th= en when
> > that asset connects to company Y's network it is authorized t= o
> > present the certificate only (which might not even list the s= pecific
> > AV vendor, just that it is current). No additional informatio= n can be
> >  sent regardless of what the user is willing to consent = to. Then if X
> >  and Y trust each other's assessments they are done.
= >

In a recent survey of fortune 500 CIO's, one response to the quest= ion "what keeps you awake at night" was "fraud in the su= pply chain". Federation is valuable and slowly happening, but how = does federation help you with your own users? You have to establish tru= st with them before you hand them off to a partner who is trusting you.= Wouldn't it be nice to say that the host being handed off is known to = have the latest patches and virus updates and has scanned for viruses t= oday? Wouldn't it be nice to demand this of hosts being handed off to y= ou?
 
> worth further investigation, I think.
>
> thanks again,
>
> Keith
>
>

If you really feel that this protocol should dictate what content = is transported between the endpoints then I think that would be a chang= e in charter.

Regards,
Frank Yeh
Corporate Security Strategy Team
IBM
Tivoli Software= --0__=07BBF8BADF99FF978f9e8a93df938690918c07BBF8BADF99FF97-- --===============1685430759== 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 --===============1685430759==-- From nea-bounces@ietf.org Thu Nov 16 23:11:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkv4r-0004qi-CR; Thu, 16 Nov 2006 23:11:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkv4q-0004qc-T5 for nea@ietf.org; Thu, 16 Nov 2006 23:11:44 -0500 Received: from bes.cs.utk.edu ([160.36.56.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkv4o-0000pe-EP for nea@ietf.org; Thu, 16 Nov 2006 23:11:44 -0500 Received: from localhost (localhost [127.0.0.1]) by bes.cs.utk.edu (Postfix) with ESMTP id 6B3DDFD1B; Thu, 16 Nov 2006 23:11:41 -0500 (EST) X-Virus-Scanned: by amavisd-new with ClamAV and SpamAssasin at cs.utk.edu Received: from bes.cs.utk.edu ([127.0.0.1]) by localhost (bes.cs.utk.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZFIUY7yM0EI; Thu, 16 Nov 2006 23:11:35 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by bes.cs.utk.edu (Postfix) with ESMTP id B1584FD11; Thu, 16 Nov 2006 23:11:26 -0500 (EST) Message-ID: <455D3678.1000306@cs.utk.edu> Date: Thu, 16 Nov 2006 23:11:36 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.8 (Macintosh/20061025) MIME-Version: 1.0 To: Frank Yeh Jr Subject: Re: [Nea] privacy: exposing information to owner References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f 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 > I'm still perplexed as to why you word things as if the network is > asking the host for anything other than the normal sort of > information that is used to establish network connections. because it's clear to me that some kinds of networks have incentives to ask hosts for other kinds of information that users would not want to divulge, and that if NEA provides them with such a mechanism, they'll use it. after all, the "normal sort of information...used to establish network connections" didn't used to require any information about the host at all - it was just user authentication provided by the host to the network and IP address, netmask, etc. provided back to the host. what is considered "normal" has changed over time to be more intrusive. who is to say what network admins will consider "normal" in the future if they're given mechanisms that allow them to ask hosts arbitrary things? > This is all the the network will be doing as far as direct > communication with the host. The sensitive information will, by > design, be opaque to the network and only visible to a validation > server on the other end of the tunnel. This server will have a way to > communicate what access level to give to the host and a way to send > the host someplace to find out what happened and what to do next. > That is about the extent of the network's involvement. anytime information about the host is exposed, whether to a network or a validation server controlled by a third-party, I'm concerned about the potential for misuse of that information. you can't just assume that the information won't be misused - you have to do threat analysis. > So here's how stuff works in a lot of enterprises now. You have to > install the client software and there is a EULA that you agree to. > You sign an agreement to follow the policies and guidelines of the > company. The company owns the laptop you are using. When you plug in > to the network that the company owns, the client software > automatically learns of any new policy changes. You can see what the > data being collected is if you want to take the trouble to look. If > you are not in compliance, you get a popup telling you to fix it and > if you don't, after a period of time your manager gets emailed. There > is no network enforcement yet, but all of the rest of it is already > being done. We have boatloads of lawyers who look at this stuff all > the time, so legally I figure this is a precedent. legality isn't the issue. the issue is whether NEA is something that IETF can recommend as being good for the Internet. there's a big difference between what is generally beneficial and what is legal. > Now let's add in network enforcement. We are already transporting the > data so all we are adding is the ability to constrain network access > based on what is found. who is "we"? IETF doesn't have a protocol to do this yet, so IETF is not already transporting this data. IETF is looking at how to design a new protocol to do this job. It's naive to assume that existing protocols that weren't designed with due consideration of user privacy or other security issues can be tweaked to solve those problems. (yes, the charter does assume this, and yes, the charter is naive...but it hardly matters because the group will have to be rechartered in light of the requirements that get developed before it does actual protocol design anyway) > So let's look for some middle ground. I'm hoping that you'll accept > for the sake of argument that the network cannot prevent people from > doing what you fear will be done_ invading other people's privacy to > some extent. If the network were to take an active part in doing the > endpoint assessment it might be able to better control what was being > disclosed. I don't expect the network to be acting on behalf of the user - I think it's much more likely that there is a conflict between the interests of the network operator and the interests of the user. So I don't think the network can be trusted to protect the user's interests. Indeed, the scenarios I've been looking at are ones where the network has an interest in violating the user's privacy. > A reasonable example would be SNMP, where the types of data to be > transported are registered in MIBs. If there were a way to define a > sort if MIB structure to define the types of assessment data being > transmitted and nothing that was not registered could be transmitted, > would that provide a better means of control? This is outside the > scope of the existing non-standard protocols and probably outside of > the charter but would it make people with your perspective more > comfortable with the idea? I'm not sure, but I've been asking myself a similar question. > Would it be better if all of the data was analyzed on the client and > only a status was returned to the server? another question I've been asking myself. > This is done today by some solutions but you then run into the > problem of trusting the client's evaluation, which it turns out is > better if you can protect the client with trusted hardware. Even if > all the data itself is transported, you still have to establish trust > in the client to trust the data so the status is simpler and just as > valid. this might be an aside, but pragmatically I'm not sure you can ever rely 100% on a client's evaluation of anything. consider two cases: in case A a client is running an OS natively, and an NEA client under that OS. the NEA client looks at the host configuration and reports to the server whether that configuration conforms to policy. case B is like case A except that the OS is running under a virtualizer. the NEA client still runs under that OS, but it can only see the configuration of its virtual machine - and it thinks that it sees the entire machine. it reports to the server the same result as in case A. however the machine is actually running other guest OSes that also share the same network interface as the one that reported NEA results....so the NEA results are fairly meaningless. now if you really constrain the kind of hardware that is used on your network you might be able to get around that problem, but I think that in practice it will be difficult to impose those constraints in most environments. > In this model, the policy is sent to the client and includes the > requirements and information on how to achieve compliance. The client > evalautes itself and uses the information to get into a compliant > state before re-attempting access. Again, this is just how our > application works and it is completely outside of the scope of the > non-standard protocols we are discussing. We just liked the fact that > the validation load was distributed on the clients rather than the > server for things like black tuesdays. makes sense. > If you really feel that this protocol should dictate what content is > transported between the endpoints then I think that would be a > change in charter. I think that imposing limitations on what kinds of content can be transported is something that should be investigated as a way to address the privacy issues. As for the charter, there are lots of things in the current charter that I think are naive or inappropriate, but as these are common problems in IETF charters I don't think we need to hash them out here. The main thing, IMHO, is that right now we're just developing requirements (which I wish they had called "design goals and requirements"). If we end up with requirements that conflict with other assumptions in the charter, the charter will need to be changed, but that's not such a big deal as the charter has to be changed anyway to allow this WG to progress past the requirements definition stage. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Nov 17 17:46:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlCTH-0002zG-Q9; Fri, 17 Nov 2006 17:46:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlCTG-0002y4-IW for nea@ietf.org; Fri, 17 Nov 2006 17:46:06 -0500 Received: from 124-254-74-144-static-dsl.ispone.net.au ([124.254.74.144] helo=oscar.sleepycat.com.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlCTE-0004an-Ov for nea@ietf.org; Fri, 17 Nov 2006 17:46:06 -0500 Received: from 124-254-82-173-static-dsl.ispone.net.au ([124.254.82.173] helo=dhs) by oscar.sleepycat.com.au with smtp (Exim 4.62) (envelope-from ) id 1GlCT2-0001mc-Kv for nea@ietf.org; Sat, 18 Nov 2006 09:45:52 +1100 Received: (qmail 3323 invoked by uid 453); 17 Nov 2006 22:45:51 -0000 X-Spam-Status: No, hits=1.9 required=5.0 tests=DNS_FROM_RFC_ABUSE,DNS_FROM_RFC_POST X-Spam-Check-By: dhs Received: from pc-00008.dhs (HELO speedy) (192.168.0.8) by dhs (qpsmtpd/0.31.1) with ESMTP; Sat, 18 Nov 2006 09:45:43 +1100 From: "Darryl \(Dassa\) Lynch" To: Subject: RE: [Nea] privacy: exposing information to owner Date: Sat, 18 Nov 2006 09:45:47 +1100 Organization: DHS International Pty Ltd MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccJ/pF0CBgthFvtRs6mMDS89r9WIgAmxQ6w In-Reply-To: <455D3678.1000306@cs.utk.edu> X-Spam-Score: 0.5 (/) X-Spam-Report: Spam detection software, running on the system "oscar.sleepycat.com.au", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Keith Moore wrote: >>> I'm still perplexed as to why you word things as if the network is >>> asking the host for anything other than the normal sort of >>> information that is used to establish network connections. >> >> because it's clear to me that some kinds of networks have >> incentives to ask hosts for other kinds of information that >> users would not want to divulge, and that if NEA provides >> them with such a mechanism, they'll use it. [...] Content analysis details: (0.5 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.5 DNS_FROM_RFC_ABUSE RBL: Envelope sender in abuse.rfc-ignorant.org 1.4 DNS_FROM_RFC_POST RBL: Envelope sender in postmaster.rfc-ignorant.org X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dassa@dhs.org List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Message-Id: Keith Moore wrote: >>> I'm still perplexed as to why you word things as if the network is >>> asking the host for anything other than the normal sort of >>> information that is used to establish network connections. >> >> because it's clear to me that some kinds of networks have >> incentives to ask hosts for other kinds of information that >> users would not want to divulge, and that if NEA provides >> them with such a mechanism, they'll use it. Could a solution to this concern be one of the first attributes exchanged with NEA being to define if the connecting node is owned/controlled by the network owner and following allowed attributes are defined by this. So, if the connecting node is not controlled by the network owner only a subset of attributes will be available but if it is controlled by the network owner then the full set of attributes will be exposed. Darryl (Dassa) Lynch _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Nov 17 19:48:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlENJ-0007Sf-J8; Fri, 17 Nov 2006 19:48:05 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlENI-0007RV-K1 for nea@ietf.org; Fri, 17 Nov 2006 19:48:04 -0500 Received: from b.mail.sonic.net ([64.142.19.5]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GlENG-0003As-4Q for nea@ietf.org; Fri, 17 Nov 2006 19:48:04 -0500 Received: from [168.61.10.136] (SJC-Office-DHCP-136.Mail-Abuse.ORG [168.61.10.136]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id kAI0lqM8001421 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 17 Nov 2006 16:47:54 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [Nea] privacy: exposing information to owner Date: Fri, 17 Nov 2006 16:47:50 -0800 To: dassa@dhs.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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 On Nov 17, 2006, at 2:45 PM, Darryl ((Dassa)) Lynch wrote: > Keith Moore wrote: >>> >>> because it's clear to me that some kinds of networks have >>> incentives to ask hosts for other kinds of information that users >>> would not want to divulge, and that if NEA provides them with >>> such a mechanism, they'll use it. > > Could a solution to this concern be one of the first attributes > exchanged with NEA being to define if the connecting node is owned/ > controlled by the network owner and following allowed attributes > are defined by this. So, if the connecting node is not controlled > by the network owner only a subset of attributes will be available > but if it is controlled by the network owner then the full set of > attributes will be exposed. If what is being asked are sets of certs identified with hostmaster@big-isp.com, then the client is always able to profile which matching certs are provided, and decide which certs might be obtained. The certs offered by the provider contains the resources needed by the client to obtain their version of the provider's desired cert. The type of service needs to be acceptable to both the client and the server. 1) Can this NEA process be abused? Yes. 2) Is the network being abused already by compromised clients? Yes. 3) Does this NEA process provide a means to facilitate remediation? Yes. 4) Does this NEA process provide a means to prevent exploits before requisite services are obtained? Yes. 5) Does this provide better guidance to users of which services are trustworthy? Yes. 6) Does the use of third-parties and certs with a time-stamp offer privacy? Depends. Currently most obtain security updates for their software. This can not be done without indicating what software is being used. When scanning or scrubbing services are required, this too can not be done without indicating what software is being used. The latest trusted computing model can also indicates what hardware and drivers are being used to prevent root kits and some types of virtualization from not being detected. This would be a trade-off between the devil you know and the one you don't. Will Keith still be able to find a provider that asks for only friendly certs? Don't know. This could be a matter of public policy as with anything of this nature. Technology often gets ahead of regulation. Waiting for the next crisis before any level of controls are instantiated is not likely to improve upon Keith's freedoms and privacy. -Doug _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Nov 17 22:05:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlGWA-0002kF-BB; Fri, 17 Nov 2006 22:05:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlGW8-0002k4-Ka for nea@ietf.org; Fri, 17 Nov 2006 22:05:20 -0500 Received: from e31.co.us.ibm.com ([32.97.110.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlGW3-0006a7-Qb for nea@ietf.org; Fri, 17 Nov 2006 22:05:20 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.13.8/8.12.11) with ESMTP id kAI35Eww013275 for ; Fri, 17 Nov 2006 22:05:14 -0500 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by westrelay02.boulder.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id kAI35EcL489736 for ; Fri, 17 Nov 2006 20:05:14 -0700 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id kAI35EcL027298 for ; Fri, 17 Nov 2006 20:05:14 -0700 Received: from d03nm129.boulder.ibm.com (d03nm129.boulder.ibm.com [9.17.195.155]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id kAI35Dch027293; Fri, 17 Nov 2006 20:05:13 -0700 In-Reply-To: <455D3678.1000306@cs.utk.edu> Subject: Re: [Nea] privacy: exposing information to owner To: Keith Moore X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Frank Yeh Jr Date: Fri, 17 Nov 2006 19:05:08 -0800 X-MIMETrack: Serialize by Router on D03NM129/03/M/IBM(Release 7.0.2HF32 | October 17, 2006) at 11/17/2006 20:05:13 MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: c343632e7d969f32683dd165d9d1aa55 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="===============0839901405==" Errors-To: nea-bounces@ietf.org --===============0839901405== Content-type: multipart/alternative; Boundary="0__=07BBF8B9DF9F2AE18f9e8a93df938690918c07BBF8B9DF9F2AE1" Content-Disposition: inline --0__=07BBF8B9DF9F2AE18f9e8a93df938690918c07BBF8B9DF9F2AE1 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Greetings, Keith Moore wrote on 11/16/2006 08:11:36 PM: > > I'm still perplexed as to why you word things as if the network is > > asking the host for anything other than the normal sort of > > information that is used to establish network connections. > > because it's clear to me that some kinds of networks have > incentives to ask hosts for other kinds of information that users wou= ld > not want to divulge, and that if NEA provides them with such a > mechanism, they'll use it. > I'm not sure we define "network" in exactly the same way, but sin= ce the point is invasion of privacy, it doesn't really matter for this discussion. > after all, the "normal sort of information...used to establish networ= k > connections" didn't used to require any information about the host a= t > all - it was just user authentication provided by the host to the > network and IP address, netmask, etc. provided back to the host. wha= t > is considered "normal" has changed over time to be more intrusive. wh= o > is to say what network admins will consider "normal" in the future if= > they're given mechanisms that allow them to ask hosts arbitrary thing= s? > Fair enough. > > This is all the the network will be doing as far as direct > > communication with the host. The sensitive information will, by > > design, be opaque to the network and only visible to a validation > > server on the other end of the tunnel. This server will have a way = to > > communicate what access level to give to the host and a way to send= > > the host someplace to find out what happened and what to do next. > > That is about the extent of the network's involvement. > > anytime information about the host is exposed, whether to a network o= r a > validation server controlled by a third-party, I'm concerned about th= e > potential for misuse of that information. you can't just assume that= > the information won't be misused - you have to do threat analysis. > I admire this sort of thinking and agree to a point. The problem = is that you cannot define, categorize and control everything nor would you= want to and granularity must be balanced against value and performance.= > > So here's how stuff works in a lot of enterprises now. You have to > > install the client software and there is a EULA that you agree to. > > You sign an agreement to follow the policies and guidelines of the > > company. The company owns the laptop you are using. When you plug i= n > > to the network that the company owns, the client software > > automatically learns of any new policy changes. You can see what th= e > > data being collected is if you want to take the trouble to look. If= > > you are not in compliance, you get a popup telling you to fix it an= d > > if you don't, after a period of time your manager gets emailed. The= re > > is no network enforcement yet, but all of the rest of it is already= > > being done. We have boatloads of lawyers who look at this stuff all= > > the time, so legally I figure this is a precedent. > > legality isn't the issue. the issue is whether NEA is something that= > IETF can recommend as being good for the Internet. there's a big > difference between what is generally beneficial and what is legal. > AHA! So legality is not the issue but what's good for the interne= t is... how liberating! So perhaps another way of looking at this is in t= he light of the existing proprietary standards. Since there are already generally available protocols to do this sort of thing, can we consider= whether having a standard as opposed to multiple non-standard protocols= is good for the internet? > > Now let's add in network enforcement. We are already transporting t= he > > data so all we are adding is the ability to constrain network acce= ss > > based on what is found. > > who is "we"? IETF doesn't have a protocol to do this yet, so IETF is= > not already transporting this data. IETF is looking at how to design= a > new protocol to do this job. We is the people using the non-standard protocols or doing compli= ance checking without network enforcement. > It's naive to assume that existing > protocols that weren't designed with due consideration of user privac= y > or other security issues can be tweaked to solve those problems. (ye= s, > the charter does assume this, and yes, the charter is naive...but it > hardly matters because the group will have to be rechartered in light= of > the requirements that get developed before it does actual protocol > design anyway) > I see the protocol as protecting that data during transport and a= m still uncomfortable with trying to dictate what is done with data once = it leaves the network. This sort of data is already being transported usin= g existing protocols, often in a somewhat less secure fashion than the protocol would enable. If we start here, where do we stop? > > So let's look for some middle ground. I'm hoping that you'll accept= > > for the sake of argument that the network cannot prevent people fro= m > > doing what you fear will be done_ invading other people's privacy t= o > > some extent. If the network were to take an active part in doing th= e > > endpoint assessment it might be able to better control what was bei= ng > > disclosed. > > I don't expect the network to be acting on behalf of the user - I thi= nk > it's much more likely that there is a conflict between the interests = of > the network operator and the interests of the user. So I don't think= > the network can be trusted to protect the user's interests. Indeed, = the > scenarios I've been looking at are ones where the network has an > interest in violating the user's privacy. > Semantics on "network" failing here. I see the network being prevented from seeing data that is going to be transported between network-attached devices. Network owner and endpoint owner might not be= the same. > > A reasonable example would be SNMP, where the types of data to be > > transported are registered in MIBs. If there were a way to define a= > > sort if MIB structure to define the types of assessment data being > > transmitted and nothing that was not registered could be transmitte= d, > > would that provide a better means of control? This is outside the > > scope of the existing non-standard protocols and probably outside o= f > > the charter but would it make people with your perspective more > > comfortable with the idea? > > I'm not sure, but I've been asking myself a similar question. > > > Would it be better if all of the data was analyzed on the client an= d > > only a status was returned to the server? > > another question I've been asking myself. > > > This is done today by some solutions but you then run into the > > problem of trusting the client's evaluation, which it turns out is > > better if you can protect the client with trusted hardware. Even if= > > all the data itself is transported, you still have to establish tru= st > > in the client to trust the data so the status is simpler and just a= s > > valid. > > this might be an aside, but pragmatically I'm not sure you can ever r= ely > 100% on a client's evaluation of anything. > Boy is THAT a different thread. Trusted Hardware says otherwise b= ut pragmatic experience says anything can be defeated somehow. > consider two cases: > > in case A a client is running an OS natively, and an NEA client under= > that OS. the NEA client looks at the host configuration and reports = to > the server whether that configuration conforms to policy. > > case B is like case A except that the OS is running under a virtualiz= er. > the NEA client still runs under that OS, but it can only see the > configuration of its virtual machine - and it thinks that it sees the= > entire machine. it reports to the server the same result as in case = A. > however the machine is actually running other guest OSes that also > share the same network interface as the one that reported NEA > results....so the NEA results are fairly meaningless. > Hmmm... all the virtual machines I work with assign different uni= que virtual MAC Addresses to their virtual interfaces so they can co-exist = on a LAN. They just look like multiple hosts on a hub to the network. Since = we can constrain traffic per IP, and each virtual host has a separate IP, = the real or virtual hosts each have to be in compliance and traffic can be selectively filtered for those not in compliance. Multiple hosts connec= ted behind a NAT-device that is then attached to a NEA-enabled port might b= e a better scenario. VM's can be configured this way and in this scenario t= he host has to be compliant but the NAT'ed VM's could probably . > now if you really constrain the kind of hardware that is used on your= > network you might be able to get around that problem, but I think tha= t > in practice it will be difficult to impose those constraints in most > environments. > And much harder to constrain the use of pure software VM's. But w= e don't have to be perfect, just add value. This protocol really has more= value in keeping honest people from being duped into commiting dishones= t acts than about not being defeatable. > > In this model, the policy is sent to the client and includes the > > requirements and information on how to achieve compliance. The clie= nt > > evalautes itself and uses the information to get into a compliant > > state before re-attempting access. Again, this is just how our > > application works and it is completely outside of the scope of the > > non-standard protocols we are discussing. We just liked the fact th= at > > the validation load was distributed on the clients rather than the > > server for things like black tuesdays. > > makes sense. > > > If you really feel that this protocol should dictate what content i= s > > transported between the endpoints then I think that would be a > > change in charter. > > I think that imposing limitations on what kinds of content can be > transported is something that should be investigated as a way to addr= ess > the privacy issues. Is this a fundamental thing with all IETF protocols? It just seem= s like a very idealistic but unrealistic thing to try to do. With or with= out user consent, private data is being transmitted using just about every existing network protocol imaginable. Is this a case of the genie being= out of the bottle or is NEA a different threat level for you? > As for the charter, there are lots of things in the > current charter that I think are naive or inappropriate, but as these= > are common problems in IETF charters I don't think we need to hash th= em > out here. The main thing, IMHO, is that right now we're just developi= ng > requirements (which I wish they had called "design goals and > requirements"). If we end up with requirements that conflict with ot= her > assumptions in the charter, the charter will need to be changed, but > that's not such a big deal as the charter has to be changed anyway to= > allow this WG to progress past the requirements definition stage. > > Keith That is comforting! Regards, Frank Yeh Corporate Security Strategy Team IBM Tivoli Software= --0__=07BBF8B9DF9F2AE18f9e8a93df938690918c07BBF8B9DF9F2AE1 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Greetings,

Keith Moore <moore@cs.utk.edu> wrote on 11/16/2006 08:11:36 P= M:

> > I'm still perplexed as to why you word things as if the netwo= rk is
> > asking the host for anything other than  the normal sort= of
> > information that is used to establish network connections. >
> because it's clear to me that some kinds of networks have
> incentives to ask hosts for other kinds of information that users = would
> not want to divulge, and that if NEA provides them with such a
= > mechanism, they'll use it.
>

I'm not sure we define "network" in exactly the same way= , but since the point is invasion of privacy, it doesn't really matter = for this discussion.

> after all, the "normal sort of information...used to establis= h network
> connections"  didn't used to require any information abo= ut the host at
> all - it was just user authentication provided by the host to the<= br> > network and IP address, netmask, etc. provided back to the host. &= nbsp;what
> is considered "normal" has changed over time to be more = intrusive. who
> is to say what network admins will consider "normal" in = the future if
> they're given mechanisms that allow them to ask hosts arbitrary th= ings?
>

Fair enough.
 
> > This is all the the network will be doing as far as direct > > communication with the host. The sensitive information will, = by
> > design, be opaque to the network and only visible to a valida= tion
> > server on the other end of the tunnel. This server will have = a way to
> > communicate what access level to give to the host and a way t= o send
> > the host someplace to find out what happened and what to do n= ext.
> > That is about the extent of the network's involvement.
>
> anytime information about the host is exposed, whether to a networ= k or a
> validation server controlled by a third-party, I'm concerned about= the
> potential for misuse of that information.  you can't just ass= ume that
> the information won't be misused - you have to do threat analysis.=
>

I admire this sort of thinking and agree to a point. The problem i= s that you cannot define, categorize and control everything nor would y= ou want to and granularity must be balanced against value and performan= ce.
 
> > So here's how stuff works in a lot of enterprises now. You ha= ve to
> > install the client software and there is a EULA that you agre= e to.
> > You sign an agreement to follow the policies and guidelines o= f the
> > company. The company owns the laptop you are using. When you = plug in
> > to the network that the company owns, the client software
= > > automatically learns of any new policy changes. You can see w= hat the
> > data being collected is if you want to take the trouble to lo= ok. If
> > you are not in compliance, you get a popup telling you to fix= it and
> > if you don't, after a period of time your manager gets emaile= d. There
> > is no network enforcement yet, but all of the rest of it is a= lready
> > being done. We have boatloads of lawyers who look at this stu= ff all
> > the time, so legally I figure this is a precedent.
>
> legality isn't the issue.  the issue is whether NEA is someth= ing that
> IETF can recommend as being good for the Internet.  there's a= big
> difference between what is generally beneficial and what is legal.=
>

AHA! So legality is not the issue but what's good for the internet= is... how liberating! So perhaps another way of looking at this is in = the light of the existing proprietary standards. Since there are alread= y generally available protocols to do this sort of thing, can we consid= er whether having a standard as opposed to multiple non-standard protoc= ols is good for the internet?
 
> > Now let's add in network enforcement. We are already transpor= ting the
> >  data so all we are adding is the ability to constrain n= etwork access
> >  based on what is found.
>
> who is "we"?  IETF doesn't have a protocol to do th= is yet, so IETF is
> not already transporting this data.  IETF is looking at how t= o design a
> new protocol to do this job.  

We is the people using the non-standard protocols or doing complia= nce checking without network enforcement.

> It's naive to assume that existing
> protocols that weren't designed with due consideration of user pri= vacy
> or other security issues can be tweaked to solve those problems. &= nbsp;(yes,
> the charter does assume this, and yes, the charter is naive...but = it
> hardly matters because the group will have to be rechartered in li= ght of
> the requirements that get developed before it does actual protocol=
> design anyway)
>

I see the protocol as protecting that data during transport and am= still uncomfortable with trying to dictate what is done with data once= it leaves the network. This sort of data is already being transported = using existing protocols, often in a somewhat less secure fashion than = the protocol would enable. If we start here, where do we stop?
=
> > So let's look for some middle ground. I'm hoping that you'll = accept
> > for the sake of argument that the network cannot prevent peop= le from
> > doing what you fear will be done_ invading other people's pri= vacy to
> > some extent. If the network were to take an active part in do= ing the
> > endpoint assessment it might be able to better control what w= as being
> > disclosed.
>
> I don't expect the network to be acting on behalf of the user - I = think
> it's much more likely that there is a conflict between the interes= ts of
> the network operator and the interests of the user.  So I don= 't think
> the network can be trusted to protect the user's interests.  = Indeed, the
> scenarios I've been looking at are ones where the network has an > interest in violating the user's privacy.
>

Semantics on "network" failing here. I see the network b= eing prevented from seeing data that is going to be transported between= network-attached devices. Network owner and endpoint owner might not b= e the same.
 
> > A reasonable example would be SNMP, where the types of data t= o be
> > transported are registered in MIBs. If there were a way to de= fine a
> > sort if MIB structure to define the types of assessment data = being
> > transmitted and nothing that was not registered could be tran= smitted,
> >  would that provide a better means of control? This is o= utside the
> > scope of the existing non-standard protocols and probably out= side of
> > the charter but would it make people with your perspective mo= re
> > comfortable with the idea?
>
> I'm not sure, but I've been asking myself a similar question.
>
> > Would it be better if all of the data was analyzed on the cli= ent and
> >  only a status was returned to the server?
>
> another question I've been asking myself.
>
> > This is done today by some  solutions but you then run i= nto the
> > problem of trusting the client's evaluation, which it turns o= ut is
> > better if you can protect the client with trusted hardware. E= ven if
> > all the data itself is transported, you still have to establi= sh trust
> > in the client to trust the data so the status is simpler and = just as
> > valid.
>
> this might be an aside, but pragmatically I'm not sure you can eve= r rely
> 100% on a client's evaluation of anything.
>

Boy is THAT a different thread. Trusted Hardware says otherwise bu= t pragmatic experience says anything can be defeated somehow.
 
> consider two cases:
>
> in case A a client is running an OS natively, and an NEA client un= der
> that OS.  the NEA client looks at the host configuration and = reports to
> the server whether that configuration conforms to policy.
>
> case B is like case A except that the OS is running under a virtua= lizer.
> the NEA client still runs under that OS, but it can only see the > configuration of its virtual machine - and it thinks that it sees = the
> entire machine.  it reports to the server the same result as = in case A.
> however the machine is actually running other guest OSes that also=
> share the same network interface as the one that reported NEA
> results....so the NEA results are fairly meaningless.
>

Hmmm... all the virtual machines I work with assign different uniq= ue virtual MAC Addresses to their virtual interfaces so they can co-exi= st on a LAN. They just look like multiple hosts on a hub to the network= . Since we can constrain traffic per IP, and each virtual host has a se= parate IP, the real or virtual hosts each have to be in compliance and = traffic can be selectively filtered for those not in compliance. Multip= le hosts connected behind a NAT-device that is then attached to a NEA-e= nabled port might be a better scenario. VM's can be configured this way= and in this scenario the host has to be compliant but the NAT'ed VM's = could probably .

> now if you really constrain the kind of hardware that is used on y= our
> network you might be able to get around that problem, but I think = that
> in practice it will be difficult to impose those constraints in mo= st
> environments.
>

And much harder to constrain the use of pure software VM's. But we= don't have to be perfect, just add value. This protocol really has mor= e value in keeping honest people from being duped into commiting dishon= est acts than about not being defeatable.

> > In this model, the policy is sent to the client and inclu= des the
> > requirements and information on how to achieve compliance. Th= e client
> > evalautes itself and uses the information to get into a compl= iant
> > state before re-attempting access. Again, this is just how ou= r
> > application works and it is completely outside of the scope o= f the
> > non-standard protocols we are discussing. We just liked the f= act that
> > the validation load was distributed on the clients rather tha= n the
> > server for things like black tuesdays.
>
> makes sense.
>
> > If you really feel that this protocol should dictate what con= tent is
> >  transported between the endpoints then I think that wou= ld be a
> > change in charter.
>
> I think that imposing limitations on what kinds of content can be =
> transported is something that should be investigated as a way to a= ddress
> the privacy issues.  

Is this a fundamental thing with all IETF protocols? It just seems= like a very idealistic but unrealistic thing to try to do. With or wit= hout user consent, private data is being transmitted using just about e= very existing network protocol imaginable. Is this a case of the genie = being out of the bottle or is NEA a different threat level for you?

> As for the charter, there are lots of things in the
> current charter that I think are naive or inappropriate, but as th= ese
> are common problems in IETF charters I don't think we need to hash= them
> out here. The main thing, IMHO, is that right now we're just devel= oping
> requirements (which I wish they had called "design goals and =
> requirements").  If we end up with requirements that con= flict with other
> assumptions in the charter, the charter will need to be changed, b= ut
> that's not such a big deal as the charter has to be changed anyway= to
> allow this WG to progress past the requirements definition stage.<= br> >
> Keith

That is comforting!

Regards,
Frank Yeh
Corporate Security Strategy Team
IBM
Tivoli Software= --0__=07BBF8B9DF9F2AE18f9e8a93df938690918c07BBF8B9DF9F2AE1-- --===============0839901405== 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 --===============0839901405==-- From nea-bounces@ietf.org Wed Nov 22 17:43:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn0og-0001Ya-Mm; Wed, 22 Nov 2006 17:43:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gn0of-0001YU-N8 for nea@ietf.org; Wed, 22 Nov 2006 17:43:41 -0500 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gn0oe-0004sY-FM for nea@ietf.org; Wed, 22 Nov 2006 17:43:41 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 22 Nov 2006 14:40:40 -0800 X-IronPort-AV: i="4.09,449,1157353200"; d="scan'208"; a="624269618:sNHT30201340" 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, 22 Nov 2006 17:43:40 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NEA Requirements Design Team Selected Thread-index: AccNp+vOQGPyN4rOSpGoc/adf9n/dAAAojswAAOcopAALoHbkA== From: "Stephen Hanna" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Nea] NEA Requirements Design Team Selected 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 to all those who volunteered to serve on the NEA Requirements design team. We got eighteen volunteers, a very good turnout! In order to scale this back to a workable team that can deliver a first draft in a short period of time, we asked all volunteers to tell us about their expertise, interests, and time available. From the responses we received, we have selected the following design team: Hormuzd Khosravi Mahalingam Mani Kaushik Narayanan Paul Sangster Joseph Tardo We have asked this team to develop a substantive first draft of the NEA Requirements document and publish it as an Internet Draft by early January. We do not expect that this first draft will be perfect. It will serve as a basis for discussions within the WG. Everyone on the NEA list will have a full opportunity to express their views. During this period, members of the design team will function as editors for the document, ensuring that the document reflects the rough consensus of the WG. Thanks, Steve and Susan _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Nov 27 10:26:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoiNB-0006Tq-5w; Mon, 27 Nov 2006 10:26:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoiNA-0006S2-8E for nea@ietf.org; Mon, 27 Nov 2006 10:26:20 -0500 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoiN7-0000qJ-IE for nea@ietf.org; Mon, 27 Nov 2006 10:26:20 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 27 Nov 2006 07:23:12 -0800 X-IronPort-AV: i="4.09,464,1157353200"; d="scan'208"; a="626866362:sNHT47288536" 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, 27 Nov 2006 10:26:15 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NEA Requirements Design Team Selected Thread-index: AccNp+vOQGPyN4rOSpGoc/adf9n/dAAAojswAAOcopAALoHbkADxP5hg From: "Stephen Hanna" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Nea] RE: NEA Requirements Design Team Selected 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 Actually, Mani's email address is mmani@avaya.com. My mistake. Sorry about that. Thanks, Steve=20 -----Original Message----- From: Stephen Hanna=20 Sent: Wednesday, November 22, 2006 5:44 PM To: nea@ietf.org Subject: NEA Requirements Design Team Selected Thanks to all those who volunteered to serve on the NEA Requirements design team. We got eighteen volunteers, a very good turnout! In order to scale this back to a workable team that can deliver a first draft in a short period of time, we asked all volunteers to tell us about their expertise, interests, and time available. From the responses we received, we have selected the following design team: Hormuzd Khosravi Mahalingam Mani Kaushik Narayanan Paul Sangster Joseph Tardo We have asked this team to develop a substantive first draft of the NEA Requirements document and publish it as an Internet Draft by early January. We do not expect that this first draft will be perfect. It will serve as a basis for discussions within the WG. Everyone on the NEA list will have a full opportunity to express their views. During this period, members of the design team will function as editors for the document, ensuring that the document reflects the rough consensus of the WG. Thanks, Steve and Susan _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Nov 27 11:40:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GojWV-0008Gf-7K; Mon, 27 Nov 2006 11:40:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GojWT-0008Fy-Ig for nea@ietf.org; Mon, 27 Nov 2006 11:40:01 -0500 Received: from nf-out-0910.google.com ([64.233.182.191]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GojWA-0005EX-Np for nea@ietf.org; Mon, 27 Nov 2006 11:40:01 -0500 Received: by nf-out-0910.google.com with SMTP id m18so1977864nfc for ; Mon, 27 Nov 2006 08:39:41 -0800 (PST) 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:references; b=WYwWqrYCRUO88r02+YLktubx5lDZqYMJ4faTLp014QgMXui/Mup4zXkuEMv9qWOwYFfD15A/JS6sBAaRUtTY+htXGFHU9whvcJn2ChHG6pFAqJWySuHU9TZ14rrtbCZ5yMxhgK9V57CEloq/QEWTJx5GLhcOFWFkvaMZQ8cLgyg= Received: by 10.82.126.5 with SMTP id y5mr2064982buc.1164645581379; Mon, 27 Nov 2006 08:39:41 -0800 (PST) Received: by 10.82.100.4 with HTTP; Mon, 27 Nov 2006 08:39:41 -0800 (PST) Message-ID: Date: Mon, 27 Nov 2006 08:39:41 -0800 From: "Mahalingam Mani" To: "Anil Gopinath" Subject: Re: [Nea] Posture Broker In-Reply-To: <20061115224602.61429.qmail@web42106.mail.mud.yahoo.com> MIME-Version: 1.0 References: <20061115224602.61429.qmail@web42106.mail.mud.yahoo.com> X-Spam-Score: 0.8 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 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="===============0559957916==" Errors-To: nea-bounces@ietf.org --===============0559957916== Content-Type: multipart/alternative; boundary="----=_Part_74851_27667706.1164645581358" ------=_Part_74851_27667706.1164645581358 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Anil, indeed it is an interesting question. given the new abstraction of NAA out of current considerations; Posture Transport Server (PTS) is what remains. Given the role of PTS & PTC as being responsible to aggregate (possibly different) NEA transports; the responsibility of aggregating PA assessment decisions (to result in consolidated policy enforcements) is vested with the (Posture Broker Server) PBS. A short response to your question - it may be that a PBS implementation may (and in many cases will) co-reside with the NAA. PBC is the aggregation point on the client side that targets the PBS to direct the collections to and shields the collectors from such chores as locating and coordinating with each other on the PBS (instance - there could be more than one reachable in a network) to send to. Hence, PBS is the complementary (un/marshalling) at the server side - performing similar function leaving it to the PBS to identify the NAA (instance to direct it to). [My understanding from the WG charter: The policy decisions and enforcement influenced by and resulting from such assessment is out of scope]. regards, -mani On 11/15/06, Anil Gopinath wrote: > > > I was thinking about the role of the posture broker > and was wondering if its a core (must be implemented) > component of NEA architecture? For simpler > implementations does it make sense for the posture > validators to talk directly to the network access > authority? > > Thanks, > Anil > > > > > ____________________________________________________________________________________ > > Sponsored Link > > Compare mortgage rates for today. > Get up to 5 free quotes. > Www2.nextag.com > > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea > ------=_Part_74851_27667706.1164645581358 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

Anil,
 
indeed it is an interesting question. given the new abstraction of NAA out of current considerations;
Posture Transport Server (PTS) is what remains. Given the role of PTS & PTC as being responsible
to aggregate (possibly different) NEA transports; the responsibility of aggregating PA assessment
decisions (to result in consolidated policy enforcements) is vested with the (Posture Broker Server)
PBS.
 
A short response to your question - it may be that a PBS implementation may (and in many
cases will) co-reside with the NAA.
 
PBC is the aggregation point on the client side that targets the PBS to direct the collections to
and shields the collectors from such chores as locating and coordinating with each other on the
PBS (instance - there could be more than one reachable in a network) to send to.
 
Hence, PBS is the complementary (un/marshalling) at the server side - performing similar function
leaving it to the PBS to identify the NAA (instance to direct it to).
 
[My understanding from the WG charter: The policy decisions and enforcement influenced by
and resulting from such assessment is out of scope].

regards,
-mani
 
On 11/15/06, Anil Gopinath <anil_public@yahoo.com > wrote:

I was thinking about the role of the posture broker
and was wondering if its a core (must be implemented)
component of NEA architecture? For simpler
implementations does it make sense for the posture
validators to talk directly to the network access
authority?

Thanks,
Anil




____________________________________________________________________________________
Sponsored Link

Compare mortgage rates for today.
Get up to 5 free quotes.
Www2.nextag.com

_______________________________________________
Nea mailing list
Nea@ietf.org
https://www1.ietf.org/mailman/listinfo/nea

------=_Part_74851_27667706.1164645581358-- --===============0559957916== 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 --===============0559957916==--