From wwwrun@core3.amsl.com Tue Jun 9 07:24:12 2009 Return-Path: X-Original-To: nea@ietf.org Delivered-To: nea@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 7A8743A6A94; Tue, 9 Jun 2009 07:24:12 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090609142412.7A8743A6A94@core3.amsl.com> Date: Tue, 9 Jun 2009 07:24:12 -0700 (PDT) Cc: nea@ietf.org Subject: [Nea] Last Call: draft-ietf-nea-pa-tnc (PA-TNC: A Posture Attribute Protocol (PA) Compatible with TNC) to Proposed Standard X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 14:24:12 -0000 The IESG has received a request from the Network Endpoint Assessment WG (nea) to consider the following document: - 'PA-TNC: A Posture Attribute Protocol (PA) Compatible with TNC ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-06-23. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-nea-pa-tnc-04.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17198&rfc_flag=0 From wwwrun@core3.amsl.com Tue Jun 9 07:24:48 2009 Return-Path: X-Original-To: nea@ietf.org Delivered-To: nea@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 05E473A684B; Tue, 9 Jun 2009 07:24:47 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090609142448.05E473A684B@core3.amsl.com> Date: Tue, 9 Jun 2009 07:24:48 -0700 (PDT) Cc: nea@ietf.org Subject: [Nea] Last Call: draft-ietf-nea-pb-tnc (PB-TNC: A Posture Broker Protocol (PB) Compatible with TNC) to Proposed Standard X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 14:24:48 -0000 The IESG has received a request from the Network Endpoint Assessment WG (nea) to consider the following document: - 'PB-TNC: A Posture Broker Protocol (PB) Compatible with TNC ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-06-23. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-nea-pb-tnc-04.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17187&rfc_flag=0 From sethomso@cisco.com Fri Jun 12 15:38:30 2009 Return-Path: X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 566683A6A04 for ; Fri, 12 Jun 2009 15:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFnzo2tRgRKu for ; Fri, 12 Jun 2009 15:38:28 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 8A7A23A696B for ; Fri, 12 Jun 2009 15:38:28 -0700 (PDT) X-Files: nea-charter-changebar.txt : 6454 X-IronPort-AV: E=Sophos;i="4.42,211,1243814400"; d="txt'?scan'208";a="322744780" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 12 Jun 2009 22:38:37 +0000 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n5CMcbj5024768 for ; Fri, 12 Jun 2009 15:38:37 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.13.8/8.13.8) with ESMTP id n5CMcaPi018759 for ; Fri, 12 Jun 2009 22:38:36 GMT 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.3959); Fri, 12 Jun 2009 18:38:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C9EBAE.8614D3DC" Date: Fri, 12 Jun 2009 18:38:35 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft of proposed updates to NEA charter to include work on PT protocol --- Please Review Thread-Index: AcnrroWFUVu2NFr+R3W3uw7XQuIFWA== From: "Susan Thomson (sethomso)" To: X-OriginalArrivalTime: 12 Jun 2009 22:38:36.0437 (UTC) FILETIME=[8627EC50:01C9EBAE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=17192; t=1244846317; x=1245710317; c=relaxed/simple; s=sjdkim3002; 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:=20Draft=20of=20proposed=20updates=20to=20NEA=20ch arter=20to=20include=20work=20on=20PT=20protocol=20---=20Ple ase=20Review |Sender:=20; bh=CgMeBKNRotkLBkuiPbd3FQwkfPhESO1LHo3TIyEFNmA=; b=p/c6FtAUla/67/atmtBdn58Du/z31B6iHOM1h9CN0Huhibc4DpkPj8BeH/ brhHuuBGMXYHunk8JmIUdTT9Ad6PUrqaf0sd+f3EL61zcsnQX7/rhY0ZUpoP mwJm2b6HaW; Authentication-Results: sj-dkim-3; header.From=sethomso@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [Nea] Draft of proposed updates to NEA charter to include work on PT protocol --- Please Review X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 22:38:30 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9EBAE.8614D3DC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As discussed at the last IETF, we need to update the NEA WG charter and the milestones to work on the PT protocol. =20 A draft proposed update to the charter is included in this email. Changes include: - Specification of one or more PT protocols to encapsulate PB - At least one mandatory to implement PT - Updated milestones Please review and provide feedback on the proposed updates over the next two weeks, by Fri Jun 26. If you support the changes, please indicate that too. A one-word message indicating support is sufficient. =20 Note: The scope of the charter updates is limited to the PT protocol only at this time. Other work items may be added in the future. The intent is to complete the initial goal laid out in the original charter which is to support interoperability between a NEA client and server. Hence, the changes to the charter have been minimized. The proposed draft text is below as well as in the attachment. The attachment includes changebars derived from the IETF rfcdiff tool showing which paragraphs have changed from the original charter. Thanks Susan ---------------- Network Endpoint Assessment (NEA) architectures have been implemented=20 in the industry to assess the "posture" of endpoint devices for the=20 purposes of monitoring compliance to an organization's posture policy=20 and optionally restricting access until the endpoint has been updated=20 to satisfy the posture requirements. An endpoint that does not comply=20 with posture policy may be vulnerable to a number of known threats that=20 may exist on the network. The intent of NEA is to facilitate corrective=20 actions to address these known vulnerabilities before a host is exposed=20 to potential attack. Note that an endpoint that is deemed compliant may=20 still be vulnerable to threats that may exist on the network. The=20 network may thus continue to be exposed to such threats as well as the=20 range of other threats not addressed by maintaining endpoint=20 compliance.=20 =20 Posture refers to the hardware or software configuration of an endpoint=20 as it pertains to an organization's security policy. Posture may=20 include knowledge that software installed to protect the machine (e.g.=20 patch management software, anti-virus software, host firewall software,=20 host intrusion protection software or any custom software) is enabled=20 and up-to-date. An endpoint supporting NEA protocols can be queried for=20 posture information.=20 =20 An organization may make a range of policy decisions based on the=20 posture of an endpoint. NEA is not intended to be prescriptive in this=20 regard. Supported deployment scenarios will include, but are not=20 limited to, providing normal access regardless of compliance result=20 along with any recommendations for remediation ("advisory mode"), as=20 well as providing restricted access sufficient for remediation purposes=20 and any essential services until an endpoint is in compliance=20 ("mandatory mode"). Specifying mechanisms for providing restricted=20 access is outside the scope of the NEA WG.=20 =20 Since NEA involves many different components from different vendors,=20 interoperability is important. The NEA working group will=20 develop standard protocols at the following three layers in the architecture:=20 the Posture Attribute protocol (PA), the Posture Broker protocol=20 (PB), and the Posture Transport protocol (PT). PA and PB will be designed to=20 support a variety of PT protocols. Together, PA, PB and the mandatory to=20 implement PT protocols will allow interoperability between an NEA Client from one vendor and an NEA Server from another.=20 =20 Since there are already several non-standard protocols at these =20 layers, the NEA working group will consider these existing protocols as=20 candidates for the standard protocols. A requirements document will be=20 written and used as a basis for evaluating the candidate protocols. The=20 working group may decide to standardize one of the candidate protocols,=20 use one of them as a basis for a new or revised protocol, or decide=20 that a new protocol is needed.=20 =20 The NEA Requirements document will include a problem statement,=20 definition of terms, requirements for the PA and PB protocols, and an=20 overall security analysis. It will also include generic requirements=20 for the protocol transporting PA, PB: the Posture Transport protocol=20 (PT). =20 =20 The PA (Posture Attribute) protocol consists of posture attributes that=20 are carried between a particular Posture Collector in a NEA client and=20 a particular Posture Validator in a NEA Server. The PA protocol is=20 carried inside the PB protocol. A base set of standard posture=20 attributes will be specified that are expected to address many common=20 posture policies. Vendor-specific attributes will also be supported;=20 vendor-specific attributes will be identified by a private enterprise=20 number and a vendor assigned value. Vendors are strongly encouraged to=20 document vendor-specific attributes in an RFC. The NEA WG will=20 investigate the use of a standard syntax for all attributes.=20 =20 The PB (Posture Broker) protocol aggregates posture attributes from one=20 or more Posture Collectors in an NEA client and sends them to the NEA=20 server for assessment by one or more Posture Validators.=20 =20 The PT (Posture Transport) protocol carries the PB protocol. The expectation=20 is that the PT protocol is a shim protocol that defines an encapsulation of PB=20 within an existing standard transport protocol. Existing standard transport=20 protocols will be leveraged to the extent possible. The NEA WG may specify=20 more than one PT to meet the requirements of different deployment scenarios.=20 The NEA WG will specify at least one mandatory to implement PT protocol. =20 =20 One commonly discussed issue with NEA systems is how to handle=20 compromised endpoints, whose reports of their own posture may not be=20 accurate. Detecting or handling such endpoints is out of scope of the=20 NEA WG. Work on PA will focus on attributes useful for assessing=20 posture of those endpoints reporting accurate information. However, the=20 protocols developed by the NEA WG must be designed to accommodate=20 emerging technologies for identifying and dealing with lying endpoints.=20 =20 Note that NEA is not chartered to develop standard protocols for=20 remediation. NEA is intended to be used with new or existing tools that=20 can be used in the absence of NEA. NEA is applicable to computing=20 enterprise environments, where endpoints accessing the enterprise's=20 network are owned and/or expected to conform to the policies set forth=20 by the organization that owns and operates the network. All other=20 cases are outside the scope of the NEA charter, since we do not know=20 that NEA would be useful in such cases. NEA applicability and security=20 considerations will be described in the appropriate NEA documents.=20 =20 Further work in the NEA WG will be considered via the rechartering=20 process after the completion of these milestones. Milestones Sep 2009 Call for proposals for the PT protocol Oct 2009 Proposals due=20 Nov 2009 Review PT protocol proposals at IETF 76 Decide how to resolve differences and issues Dec 2009 Post first WG version of PT protocol(s) Jan 2009 Review and resolve issues=20 Feb 2009 Post second WG version of PT protocol(s) Mar 2009 WG Last Call on PT protocol(s) Resolve issues from WG Last Call at IETF 77 Apr 2009 Post third WG version of PT protocol(s) May 2009 Submit PT protocol(s) to IESG =20 =20 ------_=_NextPart_001_01C9EBAE.8614D3DC Content-Type: text/plain; name="nea-charter-changebar.txt" Content-Transfer-Encoding: base64 Content-Description: nea-charter-changebar.txt Content-Disposition: attachment; filename="nea-charter-changebar.txt" IE5ldHdvcmsgRW5kcG9pbnQgQXNzZXNzbWVudCAoTkVBKSBhcmNoaXRlY3R1cmVzIGhhdmUgYmVl biBpbXBsZW1lbnRlZA0KIGluIHRoZSBpbmR1c3RyeSB0byBhc3Nlc3MgdGhlICJwb3N0dXJlIiBv ZiBlbmRwb2ludCBkZXZpY2VzIGZvciB0aGUNCiBwdXJwb3NlcyBvZiBtb25pdG9yaW5nIGNvbXBs aWFuY2UgdG8gYW4gb3JnYW5pemF0aW9uJ3MgcG9zdHVyZSBwb2xpY3kNCiBhbmQgb3B0aW9uYWxs eSByZXN0cmljdGluZyBhY2Nlc3MgdW50aWwgdGhlIGVuZHBvaW50IGhhcyBiZWVuIHVwZGF0ZWQN CiB0byBzYXRpc2Z5IHRoZSBwb3N0dXJlIHJlcXVpcmVtZW50cy4gQW4gZW5kcG9pbnQgdGhhdCBk b2VzIG5vdCBjb21wbHkNCiB3aXRoIHBvc3R1cmUgcG9saWN5IG1heSBiZSB2dWxuZXJhYmxlIHRv IGEgbnVtYmVyIG9mIGtub3duIHRocmVhdHMgdGhhdA0KIG1heSBleGlzdCBvbiB0aGUgbmV0d29y ay4gVGhlIGludGVudCBvZiBORUEgaXMgdG8gZmFjaWxpdGF0ZSBjb3JyZWN0aXZlDQogYWN0aW9u cyB0byBhZGRyZXNzIHRoZXNlIGtub3duIHZ1bG5lcmFiaWxpdGllcyBiZWZvcmUgYSBob3N0IGlz IGV4cG9zZWQNCiB0byBwb3RlbnRpYWwgYXR0YWNrLiBOb3RlIHRoYXQgYW4gZW5kcG9pbnQgdGhh dCBpcyBkZWVtZWQgY29tcGxpYW50IG1heQ0KIHN0aWxsIGJlIHZ1bG5lcmFibGUgdG8gdGhyZWF0 cyB0aGF0IG1heSBleGlzdCBvbiB0aGUgbmV0d29yay4gVGhlDQogbmV0d29yayBtYXkgdGh1cyBj b250aW51ZSB0byBiZSBleHBvc2VkIHRvIHN1Y2ggdGhyZWF0cyBhcyB3ZWxsIGFzIHRoZQ0KIHJh bmdlIG9mIG90aGVyIHRocmVhdHMgbm90IGFkZHJlc3NlZCBieSBtYWludGFpbmluZyBlbmRwb2lu dA0KIGNvbXBsaWFuY2UuDQogDQogUG9zdHVyZSByZWZlcnMgdG8gdGhlIGhhcmR3YXJlIG9yIHNv ZnR3YXJlIGNvbmZpZ3VyYXRpb24gb2YgYW4gZW5kcG9pbnQNCiBhcyBpdCBwZXJ0YWlucyB0byBh biBvcmdhbml6YXRpb24ncyBzZWN1cml0eSBwb2xpY3kuIFBvc3R1cmUgbWF5DQogaW5jbHVkZSBr bm93bGVkZ2UgdGhhdCBzb2Z0d2FyZSBpbnN0YWxsZWQgdG8gcHJvdGVjdCB0aGUgbWFjaGluZSAo ZS5nLg0KIHBhdGNoIG1hbmFnZW1lbnQgc29mdHdhcmUsIGFudGktdmlydXMgc29mdHdhcmUsIGhv c3QgZmlyZXdhbGwgc29mdHdhcmUsDQogaG9zdCBpbnRydXNpb24gcHJvdGVjdGlvbiBzb2Z0d2Fy ZSBvciBhbnkgY3VzdG9tIHNvZnR3YXJlKSBpcyBlbmFibGVkDQogYW5kIHVwLXRvLWRhdGUuIEFu IGVuZHBvaW50IHN1cHBvcnRpbmcgTkVBIHByb3RvY29scyBjYW4gYmUgcXVlcmllZCBmb3INCiBw b3N0dXJlIGluZm9ybWF0aW9uLg0KIA0KIEFuIG9yZ2FuaXphdGlvbiBtYXkgbWFrZSBhIHJhbmdl IG9mIHBvbGljeSBkZWNpc2lvbnMgYmFzZWQgb24gdGhlDQogcG9zdHVyZSBvZiBhbiBlbmRwb2lu dC4gTkVBIGlzIG5vdCBpbnRlbmRlZCB0byBiZSBwcmVzY3JpcHRpdmUgaW4gdGhpcw0KIHJlZ2Fy ZC4gU3VwcG9ydGVkIGRlcGxveW1lbnQgc2NlbmFyaW9zIHdpbGwgaW5jbHVkZSwgYnV0IGFyZSBu b3QNCiBsaW1pdGVkIHRvLCBwcm92aWRpbmcgbm9ybWFsIGFjY2VzcyByZWdhcmRsZXNzIG9mIGNv bXBsaWFuY2UgcmVzdWx0DQogYWxvbmcgd2l0aCBhbnkgcmVjb21tZW5kYXRpb25zIGZvciByZW1l ZGlhdGlvbiAoImFkdmlzb3J5IG1vZGUiKSwgYXMNCiB3ZWxsIGFzIHByb3ZpZGluZyByZXN0cmlj dGVkIGFjY2VzcyBzdWZmaWNpZW50IGZvciByZW1lZGlhdGlvbiBwdXJwb3Nlcw0KIGFuZCBhbnkg ZXNzZW50aWFsIHNlcnZpY2VzIHVudGlsIGFuIGVuZHBvaW50IGlzIGluIGNvbXBsaWFuY2UNCiAo Im1hbmRhdG9yeSBtb2RlIikuIFNwZWNpZnlpbmcgbWVjaGFuaXNtcyBmb3IgcHJvdmlkaW5nIHJl c3RyaWN0ZWQNCiBhY2Nlc3MgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhlIE5FQSBXRy4NCiAN CiBTaW5jZSBORUEgaW52b2x2ZXMgbWFueSBkaWZmZXJlbnQgY29tcG9uZW50cyBmcm9tIGRpZmZl cmVudCB2ZW5kb3JzLA0KfGludGVyb3BlcmFiaWxpdHkgaXMgaW1wb3J0YW50LiBUaGUgTkVBIHdv cmtpbmcgZ3JvdXAgd2lsbA0KfGRldmVsb3Agc3RhbmRhcmQgcHJvdG9jb2xzIGF0IHRoZSBmb2xs b3dpbmcgdGhyZWUgIGxheWVycyBpbiB0aGUgYXJjaGl0ZWN0dXJlOg0KfHRoZSBQb3N0dXJlIEF0 dHJpYnV0ZSBwcm90b2NvbCAoUEEpLCAgdGhlIFBvc3R1cmUgQnJva2VyIHByb3RvY29sDQp8KFBC KSwgYW5kIHRoZSBQb3N0dXJlIFRyYW5zcG9ydCBwcm90b2NvbCAoUFQpLiBQQSBhbmQgUEIgd2ls bCBiZSBkZXNpZ25lZCB0bw0KfHN1cHBvcnQgYSB2YXJpZXR5IG9mIFBUIHByb3RvY29scy4gVG9n ZXRoZXIsICBQQSwgUEIgYW5kIHRoZSBtYW5kYXRvcnkgdG8NCnxpbXBsZW1lbnQgUFQgcHJvdG9j b2xzIHdpbGwgYWxsb3cgaW50ZXJvcGVyYWJpbGl0eSBiZXR3ZWVuIGFuIE5FQSBDbGllbnQNCnxm cm9tIG9uZSB2ZW5kb3IgYW5kIGFuIE5FQSBTZXJ2ZXIgZnJvbSBhbm90aGVyLg0KIA0KfFNpbmNl IHRoZXJlIGFyZSBhbHJlYWR5IHNldmVyYWwgbm9uLXN0YW5kYXJkIHByb3RvY29scyBhdCB0aGVz ZQ0KIGxheWVycywgdGhlIE5FQSB3b3JraW5nIGdyb3VwIHdpbGwgY29uc2lkZXIgdGhlc2UgZXhp c3RpbmcgcHJvdG9jb2xzIGFzDQogY2FuZGlkYXRlcyBmb3IgdGhlIHN0YW5kYXJkIHByb3RvY29s cy4gQSByZXF1aXJlbWVudHMgZG9jdW1lbnQgd2lsbCBiZQ0KIHdyaXR0ZW4gYW5kIHVzZWQgYXMg YSBiYXNpcyBmb3IgZXZhbHVhdGluZyB0aGUgY2FuZGlkYXRlIHByb3RvY29scy4gVGhlDQogd29y a2luZyBncm91cCBtYXkgZGVjaWRlIHRvIHN0YW5kYXJkaXplIG9uZSBvZiB0aGUgY2FuZGlkYXRl IHByb3RvY29scywNCiB1c2Ugb25lIG9mIHRoZW0gYXMgYSBiYXNpcyBmb3IgYSBuZXcgb3IgcmV2 aXNlZCBwcm90b2NvbCwgb3IgZGVjaWRlDQogdGhhdCBhIG5ldyBwcm90b2NvbCBpcyBuZWVkZWQu DQogDQogVGhlIE5FQSBSZXF1aXJlbWVudHMgZG9jdW1lbnQgd2lsbCBpbmNsdWRlIGEgcHJvYmxl bSBzdGF0ZW1lbnQsDQogZGVmaW5pdGlvbiBvZiB0ZXJtcywgcmVxdWlyZW1lbnRzIGZvciB0aGUg UEEgYW5kIFBCIHByb3RvY29scywgYW5kIGFuDQogb3ZlcmFsbCBzZWN1cml0eSBhbmFseXNpcy4g SXQgd2lsbCBhbHNvIGluY2x1ZGUgZ2VuZXJpYyByZXF1aXJlbWVudHMNCiBmb3IgdGhlIHByb3Rv Y29sIHRyYW5zcG9ydGluZyBQQSwgUEI6IHRoZSBQb3N0dXJlIFRyYW5zcG9ydCBwcm90b2NvbA0K fChQVCkuDQogDQogVGhlIFBBIChQb3N0dXJlIEF0dHJpYnV0ZSkgcHJvdG9jb2wgY29uc2lzdHMg b2YgcG9zdHVyZSBhdHRyaWJ1dGVzIHRoYXQNCiBhcmUgY2FycmllZCBiZXR3ZWVuIGEgcGFydGlj dWxhciBQb3N0dXJlIENvbGxlY3RvciBpbiBhIE5FQSBjbGllbnQgYW5kDQogYSBwYXJ0aWN1bGFy IFBvc3R1cmUgVmFsaWRhdG9yIGluIGEgTkVBIFNlcnZlci4gVGhlIFBBIHByb3RvY29sIGlzDQog Y2FycmllZCBpbnNpZGUgdGhlIFBCIHByb3RvY29sLiBBIGJhc2Ugc2V0IG9mIHN0YW5kYXJkIHBv c3R1cmUNCiBhdHRyaWJ1dGVzIHdpbGwgYmUgc3BlY2lmaWVkIHRoYXQgYXJlIGV4cGVjdGVkIHRv IGFkZHJlc3MgbWFueSBjb21tb24NCiBwb3N0dXJlIHBvbGljaWVzLiBWZW5kb3Itc3BlY2lmaWMg YXR0cmlidXRlcyB3aWxsIGFsc28gYmUgc3VwcG9ydGVkOw0KIHZlbmRvci1zcGVjaWZpYyBhdHRy aWJ1dGVzIHdpbGwgYmUgaWRlbnRpZmllZCBieSBhIHByaXZhdGUgZW50ZXJwcmlzZQ0KIG51bWJl ciBhbmQgYSB2ZW5kb3IgYXNzaWduZWQgdmFsdWUuIFZlbmRvcnMgYXJlIHN0cm9uZ2x5IGVuY291 cmFnZWQgdG8NCiBkb2N1bWVudCB2ZW5kb3Itc3BlY2lmaWMgYXR0cmlidXRlcyBpbiBhbiBSRkMu IFRoZSBORUEgV0cgd2lsbA0KIGludmVzdGlnYXRlIHRoZSB1c2Ugb2YgYSBzdGFuZGFyZCBzeW50 YXggZm9yIGFsbCBhdHRyaWJ1dGVzLg0KIA0KIFRoZSBQQiAoUG9zdHVyZSBCcm9rZXIpIHByb3Rv Y29sIGFnZ3JlZ2F0ZXMgcG9zdHVyZSBhdHRyaWJ1dGVzIGZyb20gb25lDQogb3IgbW9yZSBQb3N0 dXJlIENvbGxlY3RvcnMgaW4gYW4gTkVBIGNsaWVudCBhbmQgc2VuZHMgdGhlbSB0byB0aGUgTkVB DQogc2VydmVyIGZvciBhc3Nlc3NtZW50IGJ5IG9uZSBvciBtb3JlIFBvc3R1cmUgVmFsaWRhdG9y cy4NCiANCnxUaGUgUFQgKFBvc3R1cmUgVHJhbnNwb3J0KSBwcm90b2NvbCBjYXJyaWVzIHRoZSBQ QiBwcm90b2NvbC4gVGhlIGV4cGVjdGF0aW9uDQp8aXMgdGhhdCB0aGUgUFQgcHJvdG9jb2wgaXMg YSBzaGltIHByb3RvY29sIHRoYXQgZGVmaW5lcyBhbiBlbmNhcHN1bGF0aW9uIG9mIFBCDQp8d2l0 aGluIGFuIGV4aXN0aW5nIHN0YW5kYXJkIHRyYW5zcG9ydCBwcm90b2NvbC4gRXhpc3Rpbmcgc3Rh bmRhcmQgdHJhbnNwb3J0DQp8cHJvdG9jb2xzIHdpbGwgYmUgbGV2ZXJhZ2VkIHRvIHRoZSBleHRl bnQgcG9zc2libGUuIFRoZSBORUEgV0cgbWF5IHNwZWNpZnkNCnxtb3JlIHRoYW4gb25lIFBUIHRv IG1lZXQgdGhlIHJlcXVpcmVtZW50cyBvZiBkaWZmZXJlbnQgZGVwbG95bWVudCBzY2VuYXJpb3Mu DQp8VGhlIE5FQSBXRyB3aWxsIHNwZWNpZnkgYXQgbGVhc3Qgb25lIG1hbmRhdG9yeSB0byBpbXBs ZW1lbnQgUFQgcHJvdG9jb2wuDQogDQogT25lIGNvbW1vbmx5IGRpc2N1c3NlZCBpc3N1ZSB3aXRo IE5FQSBzeXN0ZW1zIGlzIGhvdyB0byBoYW5kbGUNCiBjb21wcm9taXNlZCBlbmRwb2ludHMsIHdo b3NlIHJlcG9ydHMgb2YgdGhlaXIgb3duIHBvc3R1cmUgbWF5IG5vdCBiZQ0KIGFjY3VyYXRlLiBE ZXRlY3Rpbmcgb3IgaGFuZGxpbmcgc3VjaCBlbmRwb2ludHMgaXMgb3V0IG9mIHNjb3BlIG9mIHRo ZQ0KIE5FQSBXRy4gV29yayBvbiBQQSB3aWxsIGZvY3VzIG9uIGF0dHJpYnV0ZXMgdXNlZnVsIGZv ciBhc3Nlc3NpbmcNCiBwb3N0dXJlIG9mIHRob3NlIGVuZHBvaW50cyByZXBvcnRpbmcgYWNjdXJh dGUgaW5mb3JtYXRpb24uIEhvd2V2ZXIsIHRoZQ0KIHByb3RvY29scyBkZXZlbG9wZWQgYnkgdGhl IE5FQSBXRyBtdXN0IGJlIGRlc2lnbmVkIHRvIGFjY29tbW9kYXRlDQogZW1lcmdpbmcgdGVjaG5v bG9naWVzIGZvciBpZGVudGlmeWluZyBhbmQgZGVhbGluZyB3aXRoIGx5aW5nIGVuZHBvaW50cy4N CiANCiBOb3RlIHRoYXQgTkVBIGlzIG5vdCBjaGFydGVyZWQgdG8gZGV2ZWxvcCBzdGFuZGFyZCBw cm90b2NvbHMgZm9yDQogcmVtZWRpYXRpb24uIE5FQSBpcyBpbnRlbmRlZCB0byBiZSB1c2VkIHdp dGggbmV3IG9yIGV4aXN0aW5nIHRvb2xzIHRoYXQNCiBjYW4gYmUgdXNlZCBpbiB0aGUgYWJzZW5j ZSBvZiBORUEuIE5FQSBpcyBhcHBsaWNhYmxlIHRvIGNvbXB1dGluZw0KIGVudGVycHJpc2UgZW52 aXJvbm1lbnRzLCB3aGVyZSBlbmRwb2ludHMgYWNjZXNzaW5nIHRoZSBlbnRlcnByaXNlJ3MNCiBu ZXR3b3JrIGFyZSBvd25lZCBhbmQvb3IgZXhwZWN0ZWQgdG8gY29uZm9ybSB0byB0aGUgcG9saWNp ZXMgc2V0IGZvcnRoDQogYnkgdGhlIG9yZ2FuaXphdGlvbiB0aGF0IG93bnMgYW5kIG9wZXJhdGVz IHRoZSBuZXR3b3JrLiBBbGwgb3RoZXINCiBjYXNlcyBhcmUgb3V0c2lkZSB0aGUgc2NvcGUgb2Yg dGhlIE5FQSBjaGFydGVyLCBzaW5jZSB3ZSBkbyBub3Qga25vdw0KIHRoYXQgTkVBIHdvdWxkIGJl IHVzZWZ1bCBpbiBzdWNoIGNhc2VzLiBORUEgYXBwbGljYWJpbGl0eSBhbmQgc2VjdXJpdHkNCiBj b25zaWRlcmF0aW9ucyB3aWxsIGJlIGRlc2NyaWJlZCBpbiB0aGUgYXBwcm9wcmlhdGUgTkVBIGRv Y3VtZW50cy4NCiANCiBGdXJ0aGVyIHdvcmsgaW4gdGhlIE5FQSBXRyB3aWxsIGJlIGNvbnNpZGVy ZWQgdmlhIHRoZSByZWNoYXJ0ZXJpbmcNCiBwcm9jZXNzIGFmdGVyIHRoZSBjb21wbGV0aW9uIG9m IHRoZXNlIG1pbGVzdG9uZXMuDQp8DQp8TWlsZXN0b25lcw0KfA0KfFNlcCAyMDA5ICAgIENhbGwg Zm9yIHByb3Bvc2FscyBmb3IgdGhlIFBUIHByb3RvY29sDQp8T2N0IDIwMDkgICAgUHJvcG9zYWxz IGR1ZQ0KfE5vdiAyMDA5ICAgIFJldmlldyBQVCBwcm90b2NvbCBwcm9wb3NhbHMgYXQgSUVURiA3 Ng0KfCAgICAgICAgICAgIERlY2lkZSBob3cgdG8gcmVzb2x2ZSBkaWZmZXJlbmNlcyBhbmQgaXNz dWVzDQp8RGVjIDIwMDkgICAgUG9zdCBmaXJzdCBXRyB2ZXJzaW9uIG9mIFBUIHByb3RvY29sKHMp DQp8SmFuIDIwMDkgICAgUmV2aWV3IGFuZCByZXNvbHZlIGlzc3Vlcw0KfEZlYiAyMDA5ICAgIFBv c3Qgc2Vjb25kIFdHIHZlcnNpb24gb2YgUFQgcHJvdG9jb2wocykNCnxNYXIgMjAwOSAgICBXRyBM YXN0IENhbGwgb24gUFQgcHJvdG9jb2wocykNCnwgICAgICAgICAgICBSZXNvbHZlIGlzc3VlcyBm cm9tIFdHIExhc3QgQ2FsbCBhdCBJRVRGIDc3DQp8QXByIDIwMDkgICAgUG9zdCB0aGlyZCBXRyB2 ZXJzaW9uIG9mIFBUIHByb3RvY29sKHMpDQp8TWF5IDIwMDkgICAgU3VibWl0IFBUIHByb3RvY29s KHMpIHRvIElFU0cNCg== ------_=_NextPart_001_01C9EBAE.8614D3DC-- From scott.brim@gmail.com Wed Jun 17 06:34:08 2009 Return-Path: X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8170428C275; Wed, 17 Jun 2009 06:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLQaCl0j+HHd; Wed, 17 Jun 2009 06:34:07 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.25]) by core3.amsl.com (Postfix) with ESMTP id 06E3F28C28C; Wed, 17 Jun 2009 06:33:56 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 3so208348qwe.31 for ; Wed, 17 Jun 2009 06:33:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=x4xpKl410qrB8rx1Utn1mf51bYjgI8H2/tTx2Q8Ho44=; b=DD7NfkbCxi5Av57hTgcmrlAhydbdPGDJ3mdlu6Nxox4ZXKIySHlKsHCYdiM6GtwIX4 bhE5acd9qTMNoRNzT9EPP/TJbbyttm5MtlEBYxwZFXxm2XKifNYDzhnZVXxSq3NzEMTv c+DebFBEpbjQ+wdCQfUQ5xOqxEKcXTNLZy8Do= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=m5nnFTDrh3Am+/HuoK0CqUj4RFlIv1gTOp0GFNlZehw7GYai5fEv46H+M8c5r5S8Gh RdTAAfpwYKd2UjXImuNA+kghnP03J+BioON0rTerGJoHrUsgK1zphR6LVM2HdHgdnFrH HzJcfBiLQ8tOTglproNNQt3ejoBiyOTfXntgw= Received: by 10.224.73.206 with SMTP id r14mr137056qaj.315.1245245628387; Wed, 17 Jun 2009 06:33:48 -0700 (PDT) Received: from sbrim-mbp.local (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id 5sm255349qwh.41.2009.06.17.06.33.46 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 17 Jun 2009 06:33:47 -0700 (PDT) Message-ID: <4A38F0B8.9010409@gmail.com> Date: Wed, 17 Jun 2009 09:33:44 -0400 From: Scott Brim User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: gen-art@ietf.org, kaushik@cisco.com, Paul_Sangster@symantec.com, nea@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 17 Jun 2009 08:49:53 -0700 Subject: [Nea] gen-art review of draft-ietf-nea-pa-tnc-04 X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 13:34:08 -0000 I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please wait for direction from your document shepherd or AD before posting a new version of the draft. Document: draft-ietf-nea-pa-tnc-04 Reviewer: Scott Brim Review Date: Jun 17, 2009 Summary: This draft is ready for publication as a Proposed Standard. Comments: Because this draft is primarily meant to clone a standard from outside of the IETF, I have essentially nothing to say about the content. It seems internally consistent, but I cannot compare it to the original. However, a major goal is to "avoid the development of multiple incompatible standards in this area", and every time you have multiple authoritative copies of something you run the risk of divergence. It would be great if the protocol specification sections were not published at all and people were referred to the base standard! That runs into IETF procedural mud, so instead I suggest an explicit statement along the lines of: This document is not authoritative on the protocol described. The authoritative document is, and will be, the Trusted Computing Group standard [6]. Thoughts? Scott From kaushik@cisco.com Wed Jun 17 16:14:03 2009 Return-Path: X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D7143A6B4F; Wed, 17 Jun 2009 16:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QnHmf8nPf-TP; Wed, 17 Jun 2009 16:14:02 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id B49693A690F; Wed, 17 Jun 2009 16:14:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,239,1243814400"; d="scan'208";a="170864167" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 17 Jun 2009 23:14:11 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n5HNEBP4002859; Wed, 17 Jun 2009 16:14:11 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n5HNEAJd021727; Wed, 17 Jun 2009 23:14:11 GMT Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Jun 2009 16:14:10 -0700 Received: from 171.69.75.173 ([171.69.75.173]) by xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) with Microsoft Exchange Server HTTP-DAV ; Wed, 17 Jun 2009 23:14:10 +0000 User-Agent: Microsoft-Entourage/12.12.0.080729 Date: Wed, 17 Jun 2009 16:14:02 -0700 From: kaushik To: Scott Brim , , , Message-ID: Thread-Topic: gen-art review of draft-ietf-nea-pa-tnc-04 Thread-Index: AcnvoU0nBRiLHRwnDkqYjhNKnqtRCQ== In-Reply-To: <4A38F0B8.9010409@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 17 Jun 2009 23:14:10.0921 (UTC) FILETIME=[52791590:01C9EFA1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1880; t=1245280451; x=1246144451; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kaushik@cisco.com; z=From:=20kaushik=20 |Subject:=20Re=3A=20gen-art=20review=20of=20draft-ietf-nea- pa-tnc-04 |Sender:=20; bh=HOQX/4NX4gsXKDfmEaXOeCmDc+A3h41Xr8TNp9myPVc=; b=QhIB3hJ02FM0BK965xz548uchDHxjz5KH/l34nWxiAQucYKwjTHSR+TPrs E/o64Qr29jVd2/+Am1OoUtkhnsQLgFGYZ97xvU76toY1vmsbivcK3KHktS6l M2ZvJTNaACxXYcqwYdci5Rrno7t0g4LgFUbUpYVMJGv0CyEJDgf94=; Authentication-Results: sj-dkim-1; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [Nea] gen-art review of draft-ietf-nea-pa-tnc-04 X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 23:14:03 -0000 Hi Scott, The IETF specification is authoritative as far as the PA & PB protocols defined by the NEA WG since it represents work done by the IETF community on the -00 version of the specification that was submitted by TNC. Contributors to the PA & PB protocols in the NEA-WG include individuals who are not part of TNC. TNC has decided to closely track the IETF specification to avoid incompatibilities. Regards, kaushik On 6/17/09 6:33 AM, "Scott Brim" wrote: > I have been selected as the General Area Review Team (Gen-ART) > reviewer for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > > Please wait for direction from your document shepherd > or AD before posting a new version of the draft. > > Document: draft-ietf-nea-pa-tnc-04 > Reviewer: Scott Brim > Review Date: Jun 17, 2009 > > Summary: This draft is ready for publication as a Proposed Standard. > > Comments: > > Because this draft is primarily meant to clone a standard from outside > of the IETF, I have essentially nothing to say about the content. It > seems internally consistent, but I cannot compare it to the original. > > However, a major goal is to "avoid the development of multiple > incompatible standards in this area", and every time you have multiple > authoritative copies of something you run the risk of divergence. It > would be great if the protocol specification sections were not published > at all and people were referred to the base standard! That runs into > IETF procedural mud, so instead I suggest an explicit statement along > the lines of: > > This document is not authoritative on the protocol described. The > authoritative document is, and will be, the Trusted Computing Group > standard [6]. > > Thoughts? > > Scott > From scott.brim@gmail.com Thu Jun 18 05:04:22 2009 Return-Path: X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 223D63A6EBF; Thu, 18 Jun 2009 05:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytnVHna4trHH; Thu, 18 Jun 2009 05:04:21 -0700 (PDT) Received: from mail-qy0-f176.google.com (mail-qy0-f176.google.com [209.85.221.176]) by core3.amsl.com (Postfix) with ESMTP id 2729E3A6CB9; Thu, 18 Jun 2009 05:04:21 -0700 (PDT) Received: by qyk6 with SMTP id 6so130165qyk.29 for ; Thu, 18 Jun 2009 05:04:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=At1nUt4pH8FIr8N0Pq+gpPligML+IUzvScTSDKYWjUI=; b=eHE2iP5GHnw3KJLTE+MweEioNqYHiUNvlbgizqmRw/EYuz2ny/NqsPbJEoRYKrAMOe I43tumHv+A/izil1pt/4Dlq9SL4Vd3uooTkECcRWCKPAk/e4h0mT6KEfa++3rbz+5hIC JIXrokCWTSsxYtBJf+dJpxAzc4/E33Bvh5uOs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=irltRG5xvLPsucxoV0Z8vNb/K9Mj1Iclbzv2whZM8lZA6xPze/L4BjOgf6+vETZCcU 7dlo9syHm8zfrHp5QGSbaH3uqpaDJJvJiqS/5ILpWiVsyedM12ipHVkfr0XcHPHWVZ9c JVfsn5EtUKucrfMa97TcIRXhRVxpmsdYADAMA= Received: by 10.224.2.138 with SMTP id 10mr1204700qaj.299.1245326669795; Thu, 18 Jun 2009 05:04:29 -0700 (PDT) Received: from sbrim-mbp.local (198-135-0-233.cisco.com [198.135.0.233]) by mx.google.com with ESMTPS id 4sm739320qwe.37.2009.06.18.05.04.28 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 18 Jun 2009 05:04:29 -0700 (PDT) Message-ID: <4A3A2D4B.9070509@gmail.com> Date: Thu, 18 Jun 2009 08:04:27 -0400 From: Scott Brim User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: kaushik References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 18 Jun 2009 05:28:29 -0700 Cc: gen-art@ietf.org, nea@ietf.org, Paul_Sangster@symantec.com Subject: Re: [Nea] gen-art review of draft-ietf-nea-pa-tnc-04 X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 12:04:22 -0000 kaushik allegedly wrote on 06/17/2009 7:14 PM: > Hi Scott, > > The IETF specification is authoritative as far as the PA & PB protocols > defined by the NEA WG since it represents work done by the IETF community on > the -00 version of the specification that was submitted by TNC. Contributors > to the PA & PB protocols in the NEA-WG include individuals who are not part > of TNC. TNC has decided to closely track the IETF specification to avoid > incompatibilities. > > Regards, > kaushik OK, in that case the IETF spec is authoritative, but the draft says In order to avoid the development of multiple incompatible standards in this area, the TCG offered several of its TNC standards to the IETF as candidates for standardization in the IETF also. This document is one of those standards, known in the IETF as PA-TNC and in the TCG as IF-M 1.0. PA-TNC and IF-M 1.0 are equivalent. Maybe I misunderstood the wording. The way I read it, the TCG offered its standards for standardization in the IETF "also" ("also" means both organizations work on it) and this document "is" one of those standards (meaning this document does not include further development, it simply "is" what was given to the IETF). Are you saying that when they "offered" their standard, they also handed over authority for its further development? That would be fine. organizations working on a single protocol, and I always want one of them to clearly "hold the pen". Even when one is "closely tracking" the other, parallel standards can lead to ambiguities in how certain fields are used, for example. It's better to have one authority, and one document. Anyway, as I said I believe it's ready for standardization, but I hope you take steps to avoid future ambiguity. Thanks ... Scott From shanna@juniper.net Thu Jun 25 22:25:44 2009 Return-Path: X-Original-To: nea@core3.amsl.com Delivered-To: nea@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F8DD3A6993 for ; Thu, 25 Jun 2009 22:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7VCSdDSsgJ6i for ; Thu, 25 Jun 2009 22:25:42 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id BBBB93A68C1 for ; Thu, 25 Jun 2009 22:25:41 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKSkRasRzmGXLwwb0DoAMWG20suGNloxRO@postini.com; Thu, 25 Jun 2009 22:26:00 PDT Received: from p-emfe02-wf.jnpr.net (172.28.145.25) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.1.375.2; Thu, 25 Jun 2009 22:16:04 -0700 Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe02-wf.jnpr.net ([fe80::c126:c633:d2dc:8090%11]) with mapi; Fri, 26 Jun 2009 01:16:03 -0400 From: Stephen Hanna To: "Susan Thomson (sethomso)" , "nea@ietf.org" Date: Fri, 26 Jun 2009 01:15:49 -0400 Thread-Topic: [Nea] Draft of proposed updates to NEA charter to include work on PT protocol --- Please Review Thread-Index: AcnrroWFUVu2NFr+R3W3uw7XQuIFWAKbkTnA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Nea] Draft of proposed updates to NEA charter to include work on PT protocol --- Please Review X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 05:25:44 -0000 I support these changes. Now that the NEA WG is finishing up our work on the upper layers in the protocol stack, we need to move on to PT. Without standards for PT, we will not achieve our goal of interoperability. Of course, the last few milestones below should have dates in 2010. Thanks, Steve > -----Original Message----- > From: nea-bounces@ietf.org [mailto:nea-bounces@ietf.org] On=20 > Behalf Of Susan Thomson (sethomso) > Sent: Friday, June 12, 2009 3:39 PM > To: nea@ietf.org > Subject: [Nea] Draft of proposed updates to NEA charter to=20 > include work on PT protocol --- Please Review >=20 > As discussed at the last IETF, we need to update the NEA WG=20 > charter and > the milestones to work on the PT protocol. =20 >=20 > A draft proposed update to the charter is included in this email. > Changes include: > - Specification of one or more PT protocols to encapsulate PB > - At least one mandatory to implement PT > - Updated milestones >=20 > Please review and provide feedback on the proposed updates=20 > over the next > two weeks, by Fri Jun 26. If you support the changes, please indicate > that too. A one-word message indicating support is sufficient. =20 >=20 > Note: The scope of the charter updates is limited to the PT protocol > only at this time. Other work items may be added in the future. The > intent is to complete the initial goal laid out in the=20 > original charter > which is to support interoperability between a NEA client and server. > Hence, the changes to the charter have been minimized. >=20 > The proposed draft text is below as well as in the attachment. The > attachment includes changebars derived from the IETF rfcdiff tool > showing which paragraphs have changed from the original charter. >=20 > Thanks > Susan > ---------------- >=20 > Network Endpoint Assessment (NEA) architectures have been implemented=20 > in the industry to assess the "posture" of endpoint devices for the=20 > purposes of monitoring compliance to an organization's posture policy=20 > and optionally restricting access until the endpoint has been updated=20 > to satisfy the posture requirements. An endpoint that does not comply=20 > with posture policy may be vulnerable to a number of known=20 > threats that=20 > may exist on the network. The intent of NEA is to facilitate=20 > corrective=20 > actions to address these known vulnerabilities before a host=20 > is exposed=20 > to potential attack. Note that an endpoint that is deemed=20 > compliant may=20 > still be vulnerable to threats that may exist on the network. The=20 > network may thus continue to be exposed to such threats as=20 > well as the=20 > range of other threats not addressed by maintaining endpoint=20 > compliance.=20 > =20 > Posture refers to the hardware or software configuration of=20 > an endpoint=20 > as it pertains to an organization's security policy. Posture may=20 > include knowledge that software installed to protect the=20 > machine (e.g.=20 > patch management software, anti-virus software, host firewall=20 > software,=20 > host intrusion protection software or any custom software) is enabled=20 > and up-to-date. An endpoint supporting NEA protocols can be=20 > queried for=20 > posture information.=20 > =20 > An organization may make a range of policy decisions based on the=20 > posture of an endpoint. NEA is not intended to be=20 > prescriptive in this=20 > regard. Supported deployment scenarios will include, but are not=20 > limited to, providing normal access regardless of compliance result=20 > along with any recommendations for remediation ("advisory mode"), as=20 > well as providing restricted access sufficient for=20 > remediation purposes=20 > and any essential services until an endpoint is in compliance=20 > ("mandatory mode"). Specifying mechanisms for providing restricted=20 > access is outside the scope of the NEA WG.=20 > =20 > Since NEA involves many different components from different vendors,=20 > interoperability is important. The NEA working group will=20 > develop standard protocols at the following three layers in the > architecture:=20 > the Posture Attribute protocol (PA), the Posture Broker protocol=20 > (PB), and the Posture Transport protocol (PT). PA and PB will be > designed to=20 > support a variety of PT protocols. Together, PA, PB and the mandatory > to=20 > implement PT protocols will allow interoperability between an=20 > NEA Client >=20 > from one vendor and an NEA Server from another.=20 > =20 > Since there are already several non-standard protocols at these =20 > layers, the NEA working group will consider these existing=20 > protocols as=20 > candidates for the standard protocols. A requirements=20 > document will be=20 > written and used as a basis for evaluating the candidate=20 > protocols. The=20 > working group may decide to standardize one of the candidate=20 > protocols,=20 > use one of them as a basis for a new or revised protocol, or decide=20 > that a new protocol is needed.=20 > =20 > The NEA Requirements document will include a problem statement,=20 > definition of terms, requirements for the PA and PB protocols, and an=20 > overall security analysis. It will also include generic requirements=20 > for the protocol transporting PA, PB: the Posture Transport protocol=20 > (PT). =20 >=20 > =20 > The PA (Posture Attribute) protocol consists of posture=20 > attributes that=20 > are carried between a particular Posture Collector in a NEA=20 > client and=20 > a particular Posture Validator in a NEA Server. The PA protocol is=20 > carried inside the PB protocol. A base set of standard posture=20 > attributes will be specified that are expected to address many common=20 > posture policies. Vendor-specific attributes will also be supported;=20 > vendor-specific attributes will be identified by a private enterprise=20 > number and a vendor assigned value. Vendors are strongly=20 > encouraged to=20 > document vendor-specific attributes in an RFC. The NEA WG will=20 > investigate the use of a standard syntax for all attributes.=20 > =20 > The PB (Posture Broker) protocol aggregates posture=20 > attributes from one=20 > or more Posture Collectors in an NEA client and sends them to the NEA=20 > server for assessment by one or more Posture Validators.=20 > =20 > The PT (Posture Transport) protocol carries the PB protocol. The > expectation=20 > is that the PT protocol is a shim protocol that defines an=20 > encapsulation > of PB=20 > within an existing standard transport protocol. Existing standard > transport=20 > protocols will be leveraged to the extent possible. The NEA WG may > specify=20 > more than one PT to meet the requirements of different deployment > scenarios.=20 > The NEA WG will specify at least one mandatory to implement=20 > PT protocol. >=20 > =20 > =20 > One commonly discussed issue with NEA systems is how to handle=20 > compromised endpoints, whose reports of their own posture may not be=20 > accurate. Detecting or handling such endpoints is out of scope of the=20 > NEA WG. Work on PA will focus on attributes useful for assessing=20 > posture of those endpoints reporting accurate information.=20 > However, the=20 > protocols developed by the NEA WG must be designed to accommodate=20 > emerging technologies for identifying and dealing with lying=20 > endpoints.=20 > =20 > Note that NEA is not chartered to develop standard protocols for=20 > remediation. NEA is intended to be used with new or existing=20 > tools that=20 > can be used in the absence of NEA. NEA is applicable to computing=20 > enterprise environments, where endpoints accessing the enterprise's=20 > network are owned and/or expected to conform to the policies=20 > set forth=20 > by the organization that owns and operates the network. All other=20 > cases are outside the scope of the NEA charter, since we do not know=20 > that NEA would be useful in such cases. NEA applicability and=20 > security=20 > considerations will be described in the appropriate NEA documents.=20 > =20 > Further work in the NEA WG will be considered via the rechartering=20 > process after the completion of these milestones. >=20 > Milestones >=20 > Sep 2009 Call for proposals for the PT protocol > Oct 2009 Proposals due=20 > Nov 2009 Review PT protocol proposals at IETF 76 > Decide how to resolve differences and issues > Dec 2009 Post first WG version of PT protocol(s) > Jan 2009 Review and resolve issues=20 > Feb 2009 Post second WG version of PT protocol(s) > Mar 2009 WG Last Call on PT protocol(s) > Resolve issues from WG Last Call at IETF 77 > Apr 2009 Post third WG version of PT protocol(s) > May 2009 Submit PT protocol(s) to IESG > =20 > =20 >=20 >=20 > =