From nea-bounces@ietf.org Mon Oct 02 08:49:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUNET-0001NR-FE; Mon, 02 Oct 2006 08:49:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUNER-0001NL-P1 for nea@ietf.org; Mon, 02 Oct 2006 08:49:15 -0400 Received: from mout.perfora.net ([217.160.230.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUNER-0001wK-BC for nea@ietf.org; Mon, 02 Oct 2006 08:49:15 -0400 Received: from [85.102.133.248] (helo=IBM52A5038A94F) by mrelay.perfora.net (node=mrelayus0) with ESMTP (Nemesis), id 0MKoyl-1GUNEM0uky-0000qv; Mon, 02 Oct 2006 08:49:14 -0400 From: "Alper Yegin" To: "'Stephen Hanna'" , Subject: RE: [Nea] Draft updated NEA charter for review Date: Mon, 2 Oct 2006 15:49:05 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-index: AcbebcNmzFoENWnHQb62GvkytxVXogAKpsPgAIPbvbABXjNR4A== In-reply-to: Message-ID: <0MKoyl-1GUNEM0uky-0000qv@mrelay.perfora.net> X-Provags-ID: perfora.net abuse@perfora.net login:abf7a4bb310ea4dfc9b6841113e2970f X-Spam-Score: 0.0 (/) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b 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 Steve, > PT is the transport for PA and PB. EAP (with accompanying > EAP methods) is one option (but not the only one) for PT. > This has always been the case. Does the PT stack stop at the EAP layer at the bottom? I was under the impression that it'd also include the EAP lower layer (the transport protocol(s) for EAP). One way or the other, it'd be good to clarify what layers are covered by the PT. Alper > > The NEA BOF in Montreal agreed to add a requirement for > the NEA WG to identify a Mandatory To Implement PT. > With that addition to our charter, it seems clear that > we shouldn't try to identify the MTI PT now or build > into the charter any assumptions about what that protocol > will be. Deciding on the MTI PT is the work of the NEA WG. > > Thanks, > > Steve > > -----Original Message----- > From: Alper Yegin [mailto:alper.yegin@yegin.org] > Sent: Friday, September 22, 2006 6:45 PM > To: 'Susan Thomson (sethomso)'; nea@ietf.org > Subject: RE: [Nea] Draft updated NEA charter for review > > > Hi Susan, > > The charter text does not mention "EAP", though it was mentioned in the > earlier version and also in your updates list. Is the solution stack > still > based on EAP? Also, what exact layers are covered by "PT"? > > Thanks. > > Alper > > > -----Original Message----- > > From: Susan Thomson (sethomso) [mailto:sethomso@cisco.com] > > Sent: Friday, September 22, 2006 8:37 PM > > To: nea@ietf.org > > Subject: [Nea] Draft updated NEA charter for review > > > > A draft updated charter is included below. It has been updated in > > consultation with the security AD, Russ Housley, and includes the > > outcome of consensus questions posed at the last BOF (first 3 items > > below). > > > > The charter is the one reviewed prior to the last BOF with the > following > > updates: > > * Vendor-specific attributes are required to be documented > > * Identify mandatory-to-implement PT for interoperability > > * Accommodate technologies for detecting lying endpoints > > * Omit specific PT requirements re EAP > > (given the inclusion of mandatory-to-implement PT above) > > * Clarifications that deployment modes may be "advisory" (no impact on > > network access) or "mandatory" (network access impacted) > > * Clarifications that remediation protocols not in scope > > > > Please let us know of issues as soon as possible, preferably no later > > than Wed 9/27. > > > > Note that the milestone dates have NOT been updated yet. > > > > The charter will enter the review cycle in IESG shortly and a decision > > taken re WG > > formation. > > > > Apologies for delay and thanks for your patience. > > > > Thanks > > Steve and Susan > > > > ------------------------------------------------ > > Proposed NEA WG Charter > > September 21, 2006 Version > > > > Network Endpoint Assessment (NEA) architectures have been implemented > in > > the industry to assess the "posture" of endpoint devices for the > > purposes of monitoring compliance to an organization's posture policy > > and optionally restricting access until the endpoint has been updated > to > > satisfy the posture requirements. An endpoint that does not comply > with > > posture policy may be vulnerable to a number of known threats that may > > exist on the network. The intent of NEA is to facilitate corrective > > actions > > to address these known vulnerabilities before a host is exposed to > > potential attack. > > Two deployment scenarios will be supported: advisory mode and > mandatory > > mode. > > In advisory mode, an endpoint may be advised of the result of posture > > assessment > > and any recommended remediation actions, but is provided normal > network > > access > > regardless of the result. In mandatory mode, a non-compliant endpoint > is > > given > > restricted access to the network sufficient for remediation purposes > and > > any essential > > services or denied access completely. > > > > Posture refers to the hardware or software configuration of an > > endpoint as it pertains to an organization's security 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. > > On network access and while connected, an endpoint supporting NEA > > protocols can be > > queried for such posture information in either advisory or mandatory > > modes. > > > > Since NEA involves many different components from different vendors, > > interoperation is highly desirable. The priority of the NEA working > > group is to > > standardize protocols at the higher layers in the architectures: > > the Posture Attribute protocol (PA) and the Posture Broker protocol > > (PB). > > PA and PB will be designed to support a variety of lower layer > > protocols. > > When used with standards for lower layers, these new protocols will > > allow > > interoperability between an NEA Client from one vendor and an NEA > Server > > from another. > > > > Since there are already several non-standard protocols at these higher > > layers, the NEA working group will consider these existing protocols > > as candidates for standardization. A requirements document will be > > written and used as a basis for evaluating the candidate protocols. > > The working group may decide to standardize one of the candidate > > protocols, use one of them as a basis for a new or revised protocol, > > or decide that a new protocol is needed. > > > > The NEA Requirements document will include a problem statement, > > definition of terms, requirements for 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 one mandatory to implement PT protocol to ensure > > interoperability. > > > > PA, the Posture Attribute protocol, consists of posture attributes > > that are carried between a particular Posture Collector in a NEA > > client and a particular Posture Validator in a NEA Server. The PA > > protocol is carried inside the PB protocol. Certain posture attributes > > will be standardized to ensure interoperability but vendor-specific > > attributes will also be supported. Vendor-specific attributes must > > be documented in an RFC. > > > > 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 (or stack of protocols) is > suitable > > for carrying > > the PB protocol at the time of network connection, or shortly after. > > > > The NEA working group will not work on standardizing protocols other > > than PA and PB at this time. Further work in the NEA WG or in other > WGs > > will be considered via the standard rechartering process after the > > completion of these milestones. > > > > 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 intending to standardize protocols for > remediation. > > > > NEA is intended to be used with new or existing tools that can be used > > in > > the absence of NEA. There is an open issue with respect to NEA > > applicability > > in deployment scenarios where the endpoint is owned by a party that is > > different > > from the organization providing network access. > > > > Milestones: > > > > NOTE: DATES TO BE UPDATED. > > > > June 2006: > > * Submit first version of NEA Requirements I-D > > > > July 2006: > > * Agree on charter and milestones at IETF 66 > > > > September 2006: > > * WG Last Call on NEA Requirements I-D > > > > October 2006: > > * Deadline for submission of candidate specs for PA and PB > > * Submit first version of NEA Evaluation I-D > > > > November 2006: > > * At IETF 67, review NEA Evaluation I-D > > > > December 2006: > > * WG Last Call on NEA Evaluation I-D > > > > January 2007: > > * Submit NEA Requirements I-D and Evaluation I-D to IESG as Info RFC > > * Submit first draft of PA and PB specs for review > > > > March 2007: > > * Discuss unresolved issues with PA and PB specs at IETF 68 > > * Agree on solutions to unresolved issues with PA and PB specs > > > > April 2007: > > * Submit revised draft of PA and PB specs > > > > June 2007 > > * WG Last Call on PA and PB specs > > > > July 2007 > > * Resolve outstanding Last Call comments on requirements I-D at IETF > 69 > > > > August 2007: > > * Submit PA and PB specs to IESG for publication as Proposed > > > > _______________________________________________ > > Nea mailing list > > Nea@ietf.org > > https://www1.ietf.org/mailman/listinfo/nea > > > _______________________________________________ > 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 Oct 02 10:30:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUOoX-0007v8-Is; Mon, 02 Oct 2006 10:30:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUOoU-0007r6-BG; Mon, 02 Oct 2006 10:30:34 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUOoU-00014M-7U; Mon, 02 Oct 2006 10:30:34 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GUOoS-0004vt-TL; Mon, 02 Oct 2006 10:30:34 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 8440B175A0; Mon, 2 Oct 2006 14:30:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GUOny-0008Cu-0d; Mon, 02 Oct 2006 10:30:02 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: ietf-announce@ietf.org From: IESG Secretary Message-Id: Date: Mon, 02 Oct 2006 10:30:02 -0400 X-Spam-Score: -4.5 (----) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Cc: nea@ietf.org Subject: [Nea] WG Review: Network Endpoint Assessment (nea) X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org A new IETF working group has been proposed in the Security Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by October 9. +++ Network Endpoint Assessment (nea) ====================================== Current Status: Proposed Working Group Chair(s): TBD Security Area Director(s): Russ Housley Sam Hartman Security Area Advisor: Russ Housley Mailing List: nea@ietf.org Description of Working Group: Network Endpoint Assessment (NEA) architectures have been implemented in the industry 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. An endpoint that does not comply with posture policy may be vulnerable to a number of known threats that may exist on the network. The intent of NEA is to facilitate corrective actions to address these known vulnerabilities before a host is exposed to potential attack. Two deployment scenarios will be supported: advisory mode and mandatory mode. In advisory mode, an endpoint may be advised of the result of posture assessment and any recommended remediation actions, but is provided normal network access regardless of the result. In mandatory mode, a non-compliant endpoint is given restricted access to the network sufficient for remediation purposes and any essential services or denied access completely. Posture refers to the hardware or software configuration of an endpoint as it pertains to an organization's security 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. On network access and while connected, an endpoint supporting NEA protocols can be queried for such posture information in either advisory or mandatory modes. Since NEA involves many different components from different vendors, interoperation is highly desirable. The priority of the NEA working group is to standardize protocols at the higher layers in the architectures: the Posture Attribute protocol (PA) and the Posture Broker protocol (PB). PA and PB will be designed to support a variety of lower layer protocols. When used with standards for lower layers, these new protocols will allow interoperability between an NEA Client from one vendor and an NEA Server from another. Since there are already several non-standard protocols at these higher layers, the NEA working group will consider these existing protocols as candidates for standardization. A requirements document will be written and used as a basis for evaluating the candidate protocols. The working group may decide to standardize one of the candidate protocols, use one of them as a basis for a new or revised protocol, or decide that a new protocol is needed. The NEA Requirements document will include a problem statement, definition of terms, requirements for 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 one mandatory to implement PT protocol to ensure interoperability. PA, the Posture Attribute protocol, consists of posture attributes that are carried between a particular Posture Collector in a NEA client and a particular Posture Validator in a NEA Server. The PA protocol is carried inside the PB protocol. Certain posture attributes will be standardized to ensure interoperability but vendor-specific attributes will also be supported. Vendor-specific attributes must be documented in an RFC. 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 (or stack of protocols) is suitable for carrying the PB protocol at the time of network connection, or shortly after. 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 standardize protocols for remediation. NEA is intended to be used with new or existing tools that can be used in the absence of NEA. There is an open issue with respect to NEA applicability in deployment scenarios where the endpoint is owned by a party that is different from the organization providing network access. Further work in the NEA WG will be considered via the standard rechartering process after the completion of these milestones. Milestones: June 2006: * Submit first version of NEA Requirements I-D July 2006: * Agree on charter and milestones at IETF 66 October 2006: * Submit first draft of NEA Requirements I-D November 2006: * At IETF 67, discuss issues with NEA Requirements I-D * Agree on solutions to issues with NEA Requirements I-D December 2006: * Deadline for submission of candidate specs for PA and PB * Submit first version of NEA Evaluation I-D January 2007: * WG Last Call on NEA Evaluation I-D February 2007: * Submit NEA Requirements I-D and Evaluation I-D to IESG as Info RFC * Submit first draft of PA and PB specs for review March 2007: * Discuss unresolved issues with PA and PB specs at IETF 68 * Agree on solutions to unresolved issues with PA and PB specs April 2007: * Submit revised draft of PA and PB specs June 2007 * WG Last Call on PA and PB specs July 2007 * Resolve outstanding WGLC comments on PA and PB specs at IETF 69 August 2007: * Submit PA and PB specs to IESG for publication as Proposed September 2007: * Decide how to address MTI PT, recharter if needed _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Oct 02 12:19:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUQVT-0001ED-Bb; Mon, 02 Oct 2006 12:19:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUQVR-0001A2-1h for nea@ietf.org; Mon, 02 Oct 2006 12:19:01 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUQVP-0006rV-DA for nea@ietf.org; Mon, 02 Oct 2006 12:19:01 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 02 Oct 2006 12:18:59 -0400 X-IronPort-AV: i="4.09,245,1157342400"; d="scan'208"; a="105394426:sNHT40686220" 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.20060308/8.12.11) with ESMTP id k92GIxOl025323; Mon, 2 Oct 2006 12:18:59 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k92GIwdO009215; Mon, 2 Oct 2006 12:18:59 -0400 (EDT) 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); Mon, 2 Oct 2006 12:18:58 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] Draft updated NEA charter for review Date: Mon, 2 Oct 2006 12:18:57 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Draft updated NEA charter for review Thread-Index: AcbebcNmzFoENWnHQb62GvkytxVXogAKpsPgAIPbvbABXjNR4AAHNI3A From: "Susan Thomson \(sethomso\)" To: "Alper Yegin" , "Stephen Hanna" , X-OriginalArrivalTime: 02 Oct 2006 16:18:58.0842 (UTC) FILETIME=[772CBFA0:01C6E63E] DKIM-Signature: a=rsa-sha1; q=dns; l=11288; t=1159805939; x=1160669939; 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:RE=3A=20[Nea]=20Draft=20updated=20NEA=20charter=20for=20review |To:=22Alper=20Yegin=22=20, =0A=20=20=20=20=20=20=20=2 0=22Stephen=20Hanna=22=20,=20; X=v=3Dcisco.com=3B=20h=3Ds40vgcYczXbQucLdTWPfZ1XeaDE=3D; b=TC8JwAnPSDh+IfBbkWIUM12kZHK8RCfYFNZrLffCJ0LowxCw44VbwJbKpXSo/Tt4luUk0d7s RlrYTsIXl0+dMOIo4ZKtt85ErFT5YmYgL0uRudLEogxzl2jCZsLwkFbj; Authentication-Results: rtp-dkim-2.cisco.com; header.From=sethomso@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a1dc446dc7ac353b90b60743d0e479e3 Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Hi Alper For MTI purposes, PT is defined to be the protocol that encapsulates PB. It is up to the PT specification iself to identify what underlying carriers are supported.=20 To avoid confusion, we could remove the words "or stack of protocols" from the definition of PT in the charter text. Thanks Susan > -----Original Message----- > From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 > Sent: Monday, October 02, 2006 8:49 AM > To: 'Stephen Hanna'; nea@ietf.org > Subject: RE: [Nea] Draft updated NEA charter for review >=20 > Steve, >=20 > > PT is the transport for PA and PB. EAP (with accompanying > > EAP methods) is one option (but not the only one) for PT. > > This has always been the case. >=20 > Does the PT stack stop at the EAP layer at the bottom? I was under the > impression that it'd also include the EAP lower layer (the transport > protocol(s) for EAP). One way or the other, it'd be good to=20 > clarify what > layers are covered by the PT. >=20 > Alper >=20 >=20 >=20 >=20 >=20 >=20 > >=20 > > The NEA BOF in Montreal agreed to add a requirement for > > the NEA WG to identify a Mandatory To Implement PT. > > With that addition to our charter, it seems clear that > > we shouldn't try to identify the MTI PT now or build > > into the charter any assumptions about what that protocol > > will be. Deciding on the MTI PT is the work of the NEA WG. > >=20 > > Thanks, > >=20 > > Steve > >=20 > > -----Original Message----- > > From: Alper Yegin [mailto:alper.yegin@yegin.org] > > Sent: Friday, September 22, 2006 6:45 PM > > To: 'Susan Thomson (sethomso)'; nea@ietf.org > > Subject: RE: [Nea] Draft updated NEA charter for review > >=20 > >=20 > > Hi Susan, > >=20 > > The charter text does not mention "EAP", though it was=20 > mentioned in the > > earlier version and also in your updates list. Is the solution stack > > still > > based on EAP? Also, what exact layers are covered by "PT"? > >=20 > > Thanks. > >=20 > > Alper > >=20 > > > -----Original Message----- > > > From: Susan Thomson (sethomso) [mailto:sethomso@cisco.com] > > > Sent: Friday, September 22, 2006 8:37 PM > > > To: nea@ietf.org > > > Subject: [Nea] Draft updated NEA charter for review > > > > > > A draft updated charter is included below. It has been updated in > > > consultation with the security AD, Russ Housley, and includes the > > > outcome of consensus questions posed at the last BOF=20 > (first 3 items > > > below). > > > > > > The charter is the one reviewed prior to the last BOF with the > > following > > > updates: > > > * Vendor-specific attributes are required to be documented > > > * Identify mandatory-to-implement PT for interoperability > > > * Accommodate technologies for detecting lying endpoints > > > * Omit specific PT requirements re EAP > > > (given the inclusion of mandatory-to-implement PT above) > > > * Clarifications that deployment modes may be "advisory"=20 > (no impact on > > > network access) or "mandatory" (network access impacted) > > > * Clarifications that remediation protocols not in scope > > > > > > Please let us know of issues as soon as possible,=20 > preferably no later > > > than Wed 9/27. > > > > > > Note that the milestone dates have NOT been updated yet. > > > > > > The charter will enter the review cycle in IESG shortly=20 > and a decision > > > taken re WG > > > formation. > > > > > > Apologies for delay and thanks for your patience. > > > > > > Thanks > > > Steve and Susan > > > > > > ------------------------------------------------ > > > Proposed NEA WG Charter > > > September 21, 2006 Version > > > > > > Network Endpoint Assessment (NEA) architectures have been=20 > implemented > > in > > > the industry to assess the "posture" of endpoint devices for the > > > purposes of monitoring compliance to an organization's=20 > posture policy > > > and optionally restricting access until the endpoint has=20 > been updated > > to > > > satisfy the posture requirements. An endpoint that does not comply > > with > > > posture policy may be vulnerable to a number of known=20 > threats that may > > > exist on the network. The intent of NEA is to facilitate=20 > corrective > > > actions > > > to address these known vulnerabilities before a host is exposed to > > > potential attack. > > > Two deployment scenarios will be supported: advisory mode and > > mandatory > > > mode. > > > In advisory mode, an endpoint may be advised of the=20 > result of posture > > > assessment > > > and any recommended remediation actions, but is provided normal > > network > > > access > > > regardless of the result. In mandatory mode, a=20 > non-compliant endpoint > > is > > > given > > > restricted access to the network sufficient for=20 > remediation purposes > > and > > > any essential > > > services or denied access completely. > > > > > > Posture refers to the hardware or software configuration of an > > > endpoint as it pertains to an organization's security=20 > policy. Posture > > > may include knowledge that software installed to protect=20 > the machine > > > (e.g. patch management software, anti-virus software,=20 > host firewall > > > software, > > > host intrusion protection software or any custom=20 > software) is enabled > > > and up-to-date. > > > On network access and while connected, an endpoint supporting NEA > > > protocols can be > > > queried for such posture information in either advisory=20 > or mandatory > > > modes. > > > > > > Since NEA involves many different components from=20 > different vendors, > > > interoperation is highly desirable. The priority of the=20 > NEA working > > > group is to > > > standardize protocols at the higher layers in the architectures: > > > the Posture Attribute protocol (PA) and the Posture=20 > Broker protocol > > > (PB). > > > PA and PB will be designed to support a variety of lower layer > > > protocols. > > > When used with standards for lower layers, these new=20 > 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=20 > these higher > > > layers, the NEA working group will consider these=20 > existing protocols > > > as candidates for standardization. A requirements document will be > > > written and used as a basis for evaluating the candidate=20 > protocols. > > > The working group may decide to standardize one of the candidate > > > protocols, use one of them as a basis for a new or=20 > 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=20 > protocols, and an > > > overall > > > security analysis. It will also include generic=20 > requirements for the > > > protocol > > > transporting PA, PB: the Posture Transport protocol (PT).=20 > PT protocols > > > may be > > > standardized in other WGs since these protocols may not=20 > be specific to > > > NEA. The NEA WG > > > will identify one mandatory to implement PT protocol to ensure > > > interoperability. > > > > > > PA, the Posture Attribute protocol, consists of posture attributes > > > that are carried between a particular Posture Collector in a NEA > > > client and a particular Posture Validator in a NEA Server. The PA > > > protocol is carried inside the PB protocol. Certain=20 > posture attributes > > > will be standardized to ensure interoperability but=20 > vendor-specific > > > attributes will also be supported. Vendor-specific attributes must > > > be documented in an RFC. > > > > > > The PB (Posture Broker) protocol aggregates posture attributes > > > from one or more Posture Collectors in an NEA client and=20 > sends them to > > > the NEA server for assessment by one or more Posture Validators. > > > > > > The PT (Posture Transport) protocol (or stack of protocols) is > > suitable > > > for carrying > > > the PB protocol at the time of network connection, or=20 > shortly after. > > > > > > The NEA working group will not work on standardizing=20 > protocols other > > > than PA and PB at this time. Further work in the NEA WG=20 > or in other > > WGs > > > will be considered via the standard rechartering process after the > > > completion of these milestones. > > > > > > One commonly discussed issue with NEA systems is how to handle > > > compromised endpoints, whose reports of their own posture=20 > 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=20 > for assessing > > > posture of those endpoints reporting accurate=20 > information. However, > > > the protocols developed by the NEA WG must be designed to=20 > accommodate > > > emerging technologies for identifying and dealing with lying > > endpoints. > > > > > > Note that NEA is not intending to standardize protocols for > > remediation. > > > > > > NEA is intended to be used with new or existing tools=20 > that can be used > > > in > > > the absence of NEA. There is an open issue with respect to NEA > > > applicability > > > in deployment scenarios where the endpoint is owned by a=20 > party that is > > > different > > > from the organization providing network access. > > > > > > Milestones: > > > > > > NOTE: DATES TO BE UPDATED. > > > > > > June 2006: > > > * Submit first version of NEA Requirements I-D > > > > > > July 2006: > > > * Agree on charter and milestones at IETF 66 > > > > > > September 2006: > > > * WG Last Call on NEA Requirements I-D > > > > > > October 2006: > > > * Deadline for submission of candidate specs for PA and PB > > > * Submit first version of NEA Evaluation I-D > > > > > > November 2006: > > > * At IETF 67, review NEA Evaluation I-D > > > > > > December 2006: > > > * WG Last Call on NEA Evaluation I-D > > > > > > January 2007: > > > * Submit NEA Requirements I-D and Evaluation I-D to IESG=20 > as Info RFC > > > * Submit first draft of PA and PB specs for review > > > > > > March 2007: > > > * Discuss unresolved issues with PA and PB specs at IETF 68 > > > * Agree on solutions to unresolved issues with PA and PB specs > > > > > > April 2007: > > > * Submit revised draft of PA and PB specs > > > > > > June 2007 > > > * WG Last Call on PA and PB specs > > > > > > July 2007 > > > * Resolve outstanding Last Call comments on requirements=20 > I-D at IETF > > 69 > > > > > > August 2007: > > > * Submit PA and PB specs to IESG for publication as Proposed > > > > > > _______________________________________________ > > > Nea mailing list > > > Nea@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nea > >=20 > >=20 > > _______________________________________________ > > Nea mailing list > > Nea@ietf.org > > https://www1.ietf.org/mailman/listinfo/nea >=20 >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Oct 04 12:48:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV9up-00065r-LW; Wed, 04 Oct 2006 12:48:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV9uo-00065E-Qn; Wed, 04 Oct 2006 12:48:14 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV9uo-0006DZ-64; Wed, 04 Oct 2006 12:48:14 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k94GmA5Y013581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 4 Oct 2006 09:48:13 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k94Gkp9v024148; Wed, 4 Oct 2006 09:48:10 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 09:48:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea) Date: Wed, 4 Oct 2006 09:48:11 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] WG Review: Network Endpoint Assessment (nea) thread-index: AcbmL2OwptAyLGTBRR6xqHVKCI1vhwBpJQLg From: "Narayanan, Vidya" To: X-OriginalArrivalTime: 04 Oct 2006 16:48:09.0324 (UTC) FILETIME=[DF5E9AC0:01C6E7D4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 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, Comments on the charter inline below. =20 > -----Original Message----- > From: IESG Secretary [mailto:iesg-secretary@ietf.org]=20 > Sent: Monday, October 02, 2006 7:30 AM > To: ietf-announce@ietf.org > Cc: nea@ietf.org > Subject: [Nea] WG Review: Network Endpoint Assessment (nea)=20 >=20 > A new IETF working group has been proposed in the Security Area. =20 > The IESG has not made any determination as yet. The following=20 > draft charter was submitted, and is provided for=20 > informational purposes only. > Please send your comments to the IESG mailing list=20 > (iesg@ietf.org) by October 9. >=20 > +++ >=20 > Network Endpoint Assessment (nea) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Current Status: Proposed Working Group >=20 > Chair(s):=20 > TBD >=20 > Security Area Director(s): > Russ Housley > Sam Hartman >=20 > Security Area Advisor: > Russ Housley >=20 > Mailing List: nea@ietf.org >=20 > Description of Working Group: >=20 > Network Endpoint Assessment (NEA) architectures have been=20 > implemented in the industry to assess the "posture" of=20 > endpoint devices for the purposes of monitoring compliance to=20 > an organization's posture policy and optionally restricting=20 > access until the endpoint has been updated to satisfy the=20 > posture requirements. An endpoint that does not comply with=20 > posture policy may be vulnerable to a number of known threats=20 > that may exist on the network. The intent of NEA is to=20 > facilitate corrective actions to address these known=20 > vulnerabilities before a host is exposed to potential attack. Is it fair to then say that NEA is attempting to protect the endhost and not necessarily the network? That is not immediately clear in the charter. Obviously, the network must deal with all kinds of known and unknown threats and a process like NEA is inadequate to protect it at any acceptable level. That is why we employ a number of other mechanisms like firewalls, access control, packet filters, IDS/IPS, etc. in any combination to appropriately protect the networks.=20 So, stating that NEA is not attempting to protect the network at large would bring a lot of clarity to the charter.=20 > Two deployment scenarios will be supported: advisory mode and=20 > mandatory mode. > In advisory mode, an endpoint may be advised of the result of=20 > posture assessment and any recommended remediation actions,=20 > but is provided normal network access regardless of the=20 > result. In mandatory mode, a non-compliant endpoint is given=20 > restricted access to the network sufficient for remediation=20 > purposes and any essential services or denied access completely. >=20 It is unclear how the advisory vs mandatory model relates to the NEA procedures itself. NEA is attempting to provide a vehicle to perform some compliance tests on acceptable "postures". What the network decides to do with that information seems entirely dependent on the policy of the network and the extent of non-compliance, etc. What does it mean to say that NEA *allows* an advisory and/or a mandatory model?=20 > Posture refers to the hardware or software configuration of=20 > an endpoint as it pertains to an organization's security=20 > policy. Posture may include knowledge that software installed=20 > to protect the machine (e.g. patch management software,=20 > anti-virus software, host firewall software, host intrusion=20 > protection software or any custom software) is enabled and up-to-date. > On network access and while connected, an endpoint supporting=20 > NEA protocols can be queried for such posture information in=20 > either advisory or mandatory modes. >=20 Again, what does it mean to be queried in a particular mode?=20 > Since NEA involves many different components from different=20 > vendors, interoperation s/interoperation/interoperability > is highly desirable. The priority of=20 > the NEA working group is to standardize protocols at the=20 > higher layers in the architectures: > the Posture Attribute protocol (PA) and the Posture Broker=20 > protocol (PB). > PA and PB will be designed to support a variety of lower=20 > layer protocols. > When used with standards for lower layers, these new=20 > protocols will allow interoperability between an NEA Client=20 > from one vendor and an NEA Server from another. >=20 This seems like an optimistic goal. Given that only a subset of attributes are envisioned to be standardized and given that the kind of attributes are likely to be ever increasing, considering that posture refers to hardware/software configuration of an endpoint, I fail to see how we would practically get NEA clients and NEA servers from different vendors to perform any meaningful NEA procedures. In theory, I can see how this can be slated to be a goal - but, I have to believe that reality would be different.=20 > Since there are already several non-standard protocols at=20 > these higher layers, the NEA working group will consider=20 > these existing protocols as candidates for standardization. A=20 > requirements document will be written and used as a basis for=20 > evaluating the candidate protocols. > The working group may decide to standardize one of the=20 > candidate protocols, use one of them as a basis for a new or=20 > revised protocol, or decide that a new protocol is needed. >=20 > The NEA Requirements document will include a problem=20 > statement, definition of terms, requirements for the PA and=20 > PB protocols, and an overall security analysis. It will also=20 > include generic requirements for the protocol transporting=20 > PA, PB: the Posture Transport protocol (PT). PT protocols may=20 > be standardized in other WGs since these protocols may not be=20 > specific to NEA. The NEA WG will identify one mandatory to=20 > implement PT protocol to ensure interoperability. >=20 I assume that the mandatory to implement PT protocol must satisfy the criteria that will allow the NEA process to be triggered at any time (i.e., during or after network access). Clarifying this would be good.=20 > PA, the Posture Attribute protocol, consists of posture=20 > attributes that are carried between a particular Posture=20 > Collector in a NEA client and a particular Posture Validator=20 > in a NEA Server. The PA protocol is carried inside the PB=20 > protocol. Certain posture attributes will be standardized to=20 > ensure interoperability but vendor-specific attributes will=20 > also be supported. Vendor-specific attributes must be=20 > documented in an RFC. >=20 This goes back to my comment on interoperability. Unless it is expected that there will be ongoing efforts to continually standardize attributes of significance to the community as the hardware/software configurations of devices evolve, I am afraid that we won't have interoperability of any significance.=20 > The PB (Posture Broker) protocol aggregates posture=20 > attributes from one or more Posture Collectors in an NEA=20 > client and sends them to the NEA server for assessment by one=20 > or more Posture Validators. >=20 > The PT (Posture Transport) protocol (or stack of protocols)=20 > is suitable for carrying the PB protocol at the time of=20 > network connection, or shortly after. >=20 > The NEA working group will not specify protocols other than=20 > PA and PB at this time. The expectation is that an existing=20 > protocol can be used for the PT. >=20 >=20 > One commonly discussed issue with NEA systems is how to=20 > handle compromised endpoints, whose reports of their own=20 > posture may not be accurate. Detecting or handling such=20 > endpoints is out of scope of the NEA WG. Work on PA will=20 > focus on attributes useful for assessing posture of those=20 > endpoints reporting accurate information. However, the=20 > protocols developed by the NEA WG must be designed to=20 > accommodate emerging technologies for identifying and dealing=20 > with lying endpoints. >=20 I'm not sure what the last sentence means here - everything in this paragraph alludes to the fact that lying endpoints are out of scope. If the last sentence is alluding to the TCG efforts, why is it cryptic? As currently stated, it doesn't seem to add any value. If we say that in order for NEA to have a meaningful use case, it must work together with some of the TCG stuff, then, perhaps that is effort that the WG must ensure gets done.=20 > Note that NEA is not chartered to standardize 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. There is an open issue=20 > with respect to NEA applicability in deployment scenarios=20 > where the endpoint is owned by a party that is different from=20 > the organization providing network access. >=20 Why is this an open issue? When the endpoint and the organization providing network access are owned by different parties, it simply does not seem to be viable to do any kind of configuration assessment on the endpoint. I think this should be stated rather clearly along these lines:=20 "NEA is limited in applicability to the case where the endpoint is owned by the organization providing network access and performing the assessment. In the cases where the two belong to a different party, it is practically infeasible for an organization providing network access to perform any kind of posture assessment or related compliance tests on the endpoint." Thanks, Vidya > Further work in the NEA WG will be considered via the=20 > standard rechartering process after the completion of these=20 > milestones. >=20 > Milestones: >=20 > June 2006: > * Submit first version of NEA Requirements I-D >=20 > July 2006: > * Agree on charter and milestones at IETF 66 >=20 > October 2006: > * Submit first draft of NEA Requirements I-D >=20 > November 2006: > * At IETF 67, discuss issues with NEA Requirements I-D > * Agree on solutions to issues with NEA Requirements I-D >=20 > December 2006: > * Deadline for submission of candidate specs for PA and PB > * Submit first version of NEA Evaluation I-D >=20 > January 2007: > * WG Last Call on NEA Evaluation I-D >=20 > February 2007: > * Submit NEA Requirements I-D and Evaluation I-D to IESG as Info RFC > * Submit first draft of PA and PB specs for review >=20 > March 2007: > * Discuss unresolved issues with PA and PB specs at IETF 68 > * Agree on solutions to unresolved issues with PA and PB specs >=20 > April 2007: > * Submit revised draft of PA and PB specs >=20 > June 2007 > * WG Last Call on PA and PB specs >=20 > July 2007 > * Resolve outstanding WGLC comments on PA and PB specs at IETF 69 >=20 > August 2007: > * Submit PA and PB specs to IESG for publication as Proposed >=20 > September 2007: > * Decide how to address MTI PT, recharter if needed >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Oct 04 12:58:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVA4V-00074S-Dl; Wed, 04 Oct 2006 12:58:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVA4S-0006q3-8n; Wed, 04 Oct 2006 12:58:12 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVA4P-00080h-Hy; Wed, 04 Oct 2006 12:58:12 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k94Gw7ta025161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 4 Oct 2006 09:58:08 -0700 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k94GtEGO014378; Wed, 4 Oct 2006 09:58:05 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 09:58:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea) Date: Wed, 4 Oct 2006 09:58:02 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] WG Review: Network Endpoint Assessment (nea) thread-index: AcbmL2OwptAyLGTBRR6xqHVKCI1vhwBpsntg From: "Narayanan, Vidya" To: , X-OriginalArrivalTime: 04 Oct 2006 16:58:03.0376 (UTC) FILETIME=[4173BF00:01C6E7D6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org =20 All, Comments on the charter inline below. =20 > -----Original Message----- > From: IESG Secretary [mailto:iesg-secretary@ietf.org] > Sent: Monday, October 02, 2006 7:30 AM > To: ietf-announce@ietf.org > Cc: nea@ietf.org > Subject: [Nea] WG Review: Network Endpoint Assessment (nea) >=20 > A new IETF working group has been proposed in the Security Area. =20 > The IESG has not made any determination as yet. The following draft=20 > charter was submitted, and is provided for informational purposes=20 > only. > Please send your comments to the IESG mailing list > (iesg@ietf.org) by October 9. >=20 > +++ >=20 > Network Endpoint Assessment (nea) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Current Status: Proposed Working Group >=20 > Chair(s):=20 > TBD >=20 > Security Area Director(s): > Russ Housley > Sam Hartman >=20 > Security Area Advisor: > Russ Housley >=20 > Mailing List: nea@ietf.org >=20 > Description of Working Group: >=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 threats=20 > that may exist on the network. The intent of NEA is to facilitate=20 > corrective actions to address these known vulnerabilities before a=20 > host is exposed to potential attack. Is it fair to then say that NEA is attempting to protect the endhost and not necessarily the network? That is not immediately clear in the charter. Obviously, the network must deal with all kinds of known and unknown threats and a process like NEA is inadequate to protect it at any acceptable level. That is why we employ a number of other mechanisms like firewalls, access control, packet filters, IDS/IPS, etc. in any combination to appropriately protect the networks.=20 So, stating that NEA is not attempting to protect the network at large would bring a lot of clarity to the charter.=20 > Two deployment scenarios will be supported: advisory mode and=20 > mandatory mode. > In advisory mode, an endpoint may be advised of the result of posture=20 > assessment and any recommended remediation actions, but is provided=20 > normal network access regardless of the result. In mandatory mode, a=20 > non-compliant endpoint is given restricted access to the network=20 > sufficient for remediation purposes and any essential services or=20 > denied access completely. >=20 It is unclear how the advisory vs mandatory model relates to the NEA procedures itself. NEA is attempting to provide a vehicle to perform some compliance tests on acceptable "postures". What the network decides to do with that information seems entirely dependent on the policy of the network and the extent of non-compliance, etc. What does it mean to say that NEA *allows* an advisory and/or a mandatory model?=20 > Posture refers to the hardware or software configuration of an=20 > endpoint as it pertains to an organization's security policy. Posture=20 > may include knowledge that software installed to protect the machine=20 > (e.g. patch management software, anti-virus software, host firewall=20 > software, host intrusion protection software or any custom software)=20 > is enabled and up-to-date. > On network access and while connected, an endpoint supporting NEA=20 > protocols can be queried for such posture information in either=20 > advisory or mandatory modes. >=20 Again, what does it mean to be queried in a particular mode?=20 > Since NEA involves many different components from different vendors,=20 > interoperation s/interoperation/interoperability > is highly desirable. The priority of > the NEA working group is to standardize protocols at the higher layers > in the architectures: > the Posture Attribute protocol (PA) and the Posture Broker protocol=20 > (PB). > PA and PB will be designed to support a variety of lower layer=20 > protocols. > When used with standards for lower layers, these new protocols will=20 > allow interoperability between an NEA Client from one vendor and an=20 > NEA Server from another. >=20 This seems like an optimistic goal. Given that only a subset of attributes are envisioned to be standardized and given that the kind of attributes are likely to be ever increasing, considering that posture refers to hardware/software configuration of an endpoint, I fail to see how we would practically get NEA clients and NEA servers from different vendors to perform any meaningful NEA procedures. In theory, I can see how this can be slated to be a goal - but, I have to believe that reality would be different.=20 > Since there are already several non-standard protocols at=20 > these higher layers, the NEA working group will consider=20 > these existing protocols as candidates for standardization. A=20 > requirements document will be written and used as a basis for=20 > evaluating the candidate protocols. > The working group may decide to standardize one of the=20 > candidate protocols, use one of them as a basis for a new or=20 > revised protocol, or decide that a new protocol is needed. >=20 > The NEA Requirements document will include a problem=20 > statement, definition of terms, requirements for the PA and=20 > PB protocols, and an overall security analysis. It will also=20 > include generic requirements for the protocol transporting=20 > PA, PB: the Posture Transport protocol (PT). PT protocols may=20 > be standardized in other WGs since these protocols may not be=20 > specific to NEA. The NEA WG will identify one mandatory to=20 > implement PT protocol to ensure interoperability. >=20 I assume that the mandatory to implement PT protocol must satisfy the criteria that will allow the NEA process to be triggered at any time (i.e., during or after network access). Clarifying this would be good.=20 > PA, the Posture Attribute protocol, consists of posture=20 > attributes that are carried between a particular Posture=20 > Collector in a NEA client and a particular Posture Validator=20 > in a NEA Server. The PA protocol is carried inside the PB=20 > protocol. Certain posture attributes will be standardized to=20 > ensure interoperability but vendor-specific attributes will=20 > also be supported. Vendor-specific attributes must be=20 > documented in an RFC. >=20 This goes back to my comment on interoperability. Unless it is expected that there will be ongoing efforts to continually standardize attributes of significance to the community as the hardware/software configurations of devices evolve, I am afraid that we won't have interoperability of any significance.=20 > The PB (Posture Broker) protocol aggregates posture=20 > attributes from one or more Posture Collectors in an NEA=20 > client and sends them to the NEA server for assessment by one=20 > or more Posture Validators. >=20 > The PT (Posture Transport) protocol (or stack of protocols)=20 > is suitable for carrying the PB protocol at the time of=20 > network connection, or shortly after. >=20 > The NEA working group will not specify protocols other than=20 > PA and PB at this time. The expectation is that an existing=20 > protocol can be used for the PT. >=20 >=20 > One commonly discussed issue with NEA systems is how to=20 > handle compromised endpoints, whose reports of their own=20 > posture may not be accurate. Detecting or handling such=20 > endpoints is out of scope of the NEA WG. Work on PA will=20 > focus on attributes useful for assessing posture of those=20 > endpoints reporting accurate information. However, the=20 > protocols developed by the NEA WG must be designed to=20 > accommodate emerging technologies for identifying and dealing=20 > with lying endpoints. >=20 I'm not sure what the last sentence means here - everything in this paragraph alludes to the fact that lying endpoints are out of scope. If the last sentence is alluding to the TCG efforts, why is it cryptic? As currently stated, it doesn't seem to add any value. If we say that in order for NEA to have a meaningful use case, it must work together with some of the TCG stuff, then, perhaps that is effort that the WG must ensure gets done.=20 > Note that NEA is not chartered to standardize 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. There is an open issue=20 > with respect to NEA applicability in deployment scenarios=20 > where the endpoint is owned by a party that is different from=20 > the organization providing network access. >=20 Why is this an open issue? When the endpoint and the organization providing network access are owned by different parties, it simply does not seem to be viable to do any kind of configuration assessment on the endpoint. I think this should be stated rather clearly along these lines:=20 "NEA is limited in applicability to the case where the endpoint is owned by the organization providing network access and performing the assessment. In the cases where the two belong to a different party, it is practically infeasible for an organization providing network access to perform any kind of posture assessment or related compliance tests on the endpoint." Thanks, Vidya > Further work in the NEA WG will be considered via the=20 > standard rechartering process after the completion of these=20 > milestones. >=20 > Milestones: >=20 > June 2006: > * Submit first version of NEA Requirements I-D >=20 > July 2006: > * Agree on charter and milestones at IETF 66 >=20 > October 2006: > * Submit first draft of NEA Requirements I-D >=20 > November 2006: > * At IETF 67, discuss issues with NEA Requirements I-D > * Agree on solutions to issues with NEA Requirements I-D >=20 > December 2006: > * Deadline for submission of candidate specs for PA and PB > * Submit first version of NEA Evaluation I-D >=20 > January 2007: > * WG Last Call on NEA Evaluation I-D >=20 > February 2007: > * Submit NEA Requirements I-D and Evaluation I-D to IESG as Info RFC > * Submit first draft of PA and PB specs for review >=20 > March 2007: > * Discuss unresolved issues with PA and PB specs at IETF 68 > * Agree on solutions to unresolved issues with PA and PB specs >=20 > April 2007: > * Submit revised draft of PA and PB specs >=20 > June 2007 > * WG Last Call on PA and PB specs >=20 > July 2007 > * Resolve outstanding WGLC comments on PA and PB specs at IETF 69 >=20 > August 2007: > * Submit PA and PB specs to IESG for publication as Proposed >=20 > September 2007: > * Decide how to address MTI PT, recharter if needed >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Oct 05 10:02:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVToB-000332-HV; Thu, 05 Oct 2006 10:02:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVFTb-0001zJ-WC; Wed, 04 Oct 2006 18:44:32 -0400 Received: from elasmtp-kukur.atl.sa.earthlink.net ([209.86.89.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVFTZ-0000Rs-8S; Wed, 04 Oct 2006 18:44:31 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=F8N6ax2WdW+y2mvN5AwBZY5N3X3osct6DgNQmLf/rjs/vnBZ2oiiv/Jbc99n1iMt; 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.48.170] (helo=gw) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GVFTV-0000sQ-W0; Wed, 04 Oct 2006 18:44:28 -0400 Message-ID: <00c601c6e806$a60d11c0$aa30f604@home.glassey.com> From: "todd glassey" To: "Narayanan, Vidya" , , References: Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Date: Wed, 4 Oct 2006 14:31:36 -0700 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: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec798eba759da7ced7f4ef88a8f3db29d985350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.246.48.170 X-Spam-Score: 0.0 (/) X-Scan-Signature: e3901bdd61b234d82da85cc76f05a7e8 X-Mailman-Approved-At: Thu, 05 Oct 2006 10:02:42 -0400 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Vidya good commentary, maybe I can add some more. The NEA, per the charter-need's justification statement says: > > Network Endpoint Assessment (NEA) architectures have been implemented > in the industry to assess the "posture" of endpoint devices Ah two new terms of Art - "Posture" and "Devices". > for the > purposes of monitoring compliance to an organization's posture policy here again we have Posturing... but now its a policy. The policy of dancing or what? so is this posture relative to the Security Policy? or how about the Operations Integrity Policy? And is the Posture erect or is it rolling on the floor laughing ones ... > and optionally restricting access until the endpoint has been updated This is a statement of effect rather than describing the thing itself. This comment is specific to what the design of the NEA would do and not what the NEA is but what the hey... So then this 'thingee', the 'Posture manager', is something that is an agent that lives in the computer to make sure its doing what its supposed to and has all of the stuff its supposed to be, right? So the NEA seems to be an integrity management and compliance agent right? Which means you want to go to blows with Tripwire and the Change Management Integrity of Operations people too? Nice... Tripwire and Aide seem to be things that do that - Fremont and COPS too. The configuration management is Titan and YASSP or other hardening scripts. The logging and setup for managing the logging is already in place too. So where does this 'compliance assurance thingee' live in that array? > to satisfy the posture requirements. Again - I gotta mention that you are doing alot of posturing there... So guys - here we go again - which posture is it this time??? bent over backwards or what? > An endpoint that does not comply > with posture policy may be vulnerable to a number of known threats > that may exist on the network. And here we have the justification for the service proposed in the charter statement... come on guys... > The intent of NEA is to facilitate > corrective actions to address these known vulnerabilities before a > host is exposed to potential attack. Ahhh... Inline and continuous hardening and reporting. So then is this the creation of the IETF's version of an embedded Titan or YASSP? Does that real make sense. If it does, why not just run Titan and YASSP through SNMP, or buy Tripwire, or use Aide and SNORT, or ... you get my point I hope. Try this: "The NEA is a process and methodology to integrate ongoing integrity and process refinement into the operations of network services. The principal goal of the NEA is a higher set of reporting models to support those required by today's network operators for their IT Infrastructure Integrity Programs" And the process statement: "To facilitate this goal, the NEA provides Audit and Systemic Integrity/Change Management as integrated features and provides proper evidentiary models to support this under whatever level of scrutiny is required. Scrutiny including as formal evidence with Chain of Custody issues to address as well" and finally: "To accomplish these ends, the NEA may use pieces of other services or technologies in creating this Open Framework for operating integrity and its evidentiary documentation." Todd Glassey ----- Original Message ----- From: "Narayanan, Vidya" To: ; Cc: Sent: Wednesday, October 04, 2006 9:58 AM Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea) All, Comments on the charter inline below. > -----Original Message----- > From: IESG Secretary [mailto:iesg-secretary@ietf.org] > Sent: Monday, October 02, 2006 7:30 AM > To: ietf-announce@ietf.org > Cc: nea@ietf.org > Subject: [Nea] WG Review: Network Endpoint Assessment (nea) > > A new IETF working group has been proposed in the Security Area. > The IESG has not made any determination as yet. The following draft > charter was submitted, and is provided for informational purposes > only. > Please send your comments to the IESG mailing list > (iesg@ietf.org) by October 9. > > +++ > > Network Endpoint Assessment (nea) > ====================================== > > Current Status: Proposed Working Group > > Chair(s): > TBD > > Security Area Director(s): > Russ Housley > Sam Hartman > > Security Area Advisor: > Russ Housley > > Mailing List: nea@ietf.org > > Description of Working Group: > > Network Endpoint Assessment (NEA) architectures have been implemented > in the industry 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. An endpoint that does not comply > with posture policy may be vulnerable to a number of known threats > that may exist on the network. The intent of NEA is to facilitate > corrective actions to address these known vulnerabilities before a > host is exposed to potential attack. Is it fair to then say that NEA is attempting to protect the endhost and not necessarily the network? That is not immediately clear in the charter. Obviously, the network must deal with all kinds of known and unknown threats and a process like NEA is inadequate to protect it at any acceptable level. That is why we employ a number of other mechanisms like firewalls, access control, packet filters, IDS/IPS, etc. in any combination to appropriately protect the networks. So, stating that NEA is not attempting to protect the network at large would bring a lot of clarity to the charter. > Two deployment scenarios will be supported: advisory mode and > mandatory mode. > In advisory mode, an endpoint may be advised of the result of posture > assessment and any recommended remediation actions, but is provided > normal network access regardless of the result. In mandatory mode, a > non-compliant endpoint is given restricted access to the network > sufficient for remediation purposes and any essential services or > denied access completely. > It is unclear how the advisory vs mandatory model relates to the NEA procedures itself. NEA is attempting to provide a vehicle to perform some compliance tests on acceptable "postures". What the network decides to do with that information seems entirely dependent on the policy of the network and the extent of non-compliance, etc. What does it mean to say that NEA *allows* an advisory and/or a mandatory model? > Posture refers to the hardware or software configuration of an > endpoint as it pertains to an organization's security 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. > On network access and while connected, an endpoint supporting NEA > protocols can be queried for such posture information in either > advisory or mandatory modes. > Again, what does it mean to be queried in a particular mode? > Since NEA involves many different components from different vendors, > interoperation s/interoperation/interoperability > is highly desirable. The priority of > the NEA working group is to standardize protocols at the higher layers > in the architectures: > the Posture Attribute protocol (PA) and the Posture Broker protocol > (PB). > PA and PB will be designed to support a variety of lower layer > protocols. > When used with standards for lower layers, these new protocols will > allow interoperability between an NEA Client from one vendor and an > NEA Server from another. > This seems like an optimistic goal. Given that only a subset of attributes are envisioned to be standardized and given that the kind of attributes are likely to be ever increasing, considering that posture refers to hardware/software configuration of an endpoint, I fail to see how we would practically get NEA clients and NEA servers from different vendors to perform any meaningful NEA procedures. In theory, I can see how this can be slated to be a goal - but, I have to believe that reality would be different. > Since there are already several non-standard protocols at > these higher layers, the NEA working group will consider > these existing protocols as candidates for standardization. A > requirements document will be written and used as a basis for > evaluating the candidate protocols. > The working group may decide to standardize one of the > candidate protocols, use one of them as a basis for a new or > revised protocol, or decide that a new protocol is needed. > > The NEA Requirements document will include a problem > statement, definition of terms, requirements for 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 one mandatory to > implement PT protocol to ensure interoperability. > I assume that the mandatory to implement PT protocol must satisfy the criteria that will allow the NEA process to be triggered at any time (i.e., during or after network access). Clarifying this would be good. > PA, the Posture Attribute protocol, consists of posture > attributes that are carried between a particular Posture > Collector in a NEA client and a particular Posture Validator > in a NEA Server. The PA protocol is carried inside the PB > protocol. Certain posture attributes will be standardized to > ensure interoperability but vendor-specific attributes will > also be supported. Vendor-specific attributes must be > documented in an RFC. > This goes back to my comment on interoperability. Unless it is expected that there will be ongoing efforts to continually standardize attributes of significance to the community as the hardware/software configurations of devices evolve, I am afraid that we won't have interoperability of any significance. > 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 (or stack of protocols) > is suitable for carrying the PB protocol at the time of > network connection, or shortly after. > > 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. > I'm not sure what the last sentence means here - everything in this paragraph alludes to the fact that lying endpoints are out of scope. If the last sentence is alluding to the TCG efforts, why is it cryptic? As currently stated, it doesn't seem to add any value. If we say that in order for NEA to have a meaningful use case, it must work together with some of the TCG stuff, then, perhaps that is effort that the WG must ensure gets done. > Note that NEA is not chartered to standardize protocols for > remediation. > NEA is intended to be used with new or existing tools that > can be used in the absence of NEA. There is an open issue > with respect to NEA applicability in deployment scenarios > where the endpoint is owned by a party that is different from > the organization providing network access. > Why is this an open issue? When the endpoint and the organization providing network access are owned by different parties, it simply does not seem to be viable to do any kind of configuration assessment on the endpoint. I think this should be stated rather clearly along these lines: "NEA is limited in applicability to the case where the endpoint is owned by the organization providing network access and performing the assessment. In the cases where the two belong to a different party, it is practically infeasible for an organization providing network access to perform any kind of posture assessment or related compliance tests on the endpoint." Thanks, Vidya > Further work in the NEA WG will be considered via the > standard rechartering process after the completion of these > milestones. > > Milestones: > > June 2006: > * Submit first version of NEA Requirements I-D > > July 2006: > * Agree on charter and milestones at IETF 66 > > October 2006: > * Submit first draft of NEA Requirements I-D > > November 2006: > * At IETF 67, discuss issues with NEA Requirements I-D > * Agree on solutions to issues with NEA Requirements I-D > > December 2006: > * Deadline for submission of candidate specs for PA and PB > * Submit first version of NEA Evaluation I-D > > January 2007: > * WG Last Call on NEA Evaluation I-D > > February 2007: > * Submit NEA Requirements I-D and Evaluation I-D to IESG as Info RFC > * Submit first draft of PA and PB specs for review > > March 2007: > * Discuss unresolved issues with PA and PB specs at IETF 68 > * Agree on solutions to unresolved issues with PA and PB specs > > April 2007: > * Submit revised draft of PA and PB specs > > June 2007 > * WG Last Call on PA and PB specs > > July 2007 > * Resolve outstanding WGLC comments on PA and PB specs at IETF 69 > > August 2007: > * Submit PA and PB specs to IESG for publication as Proposed > > September 2007: > * Decide how to address MTI PT, recharter if needed > > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Oct 05 15:22:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVYnh-00085J-JB; Thu, 05 Oct 2006 15:22:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVYng-00080k-8J; Thu, 05 Oct 2006 15:22:32 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVYnd-0006Ja-C3; Thu, 05 Oct 2006 15:22:32 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 05 Oct 2006 12:22:28 -0700 X-IronPort-AV: i="4.09,266,1157353200"; d="scan'208"; a="328494662:sNHT1109905858" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k95JMRBX020865; Thu, 5 Oct 2006 12:22:27 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k95JM6Ot024014; Thu, 5 Oct 2006 12:22:26 -0700 (PDT) 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, 5 Oct 2006 15:22:20 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea) Date: Thu, 5 Oct 2006 15:22:18 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] WG Review: Network Endpoint Assessment (nea) Thread-Index: AcbmL2OwptAyLGTBRR6xqHVKCI1vhwBpJQLgAAGgagA= From: "Susan Thomson \(sethomso\)" To: "Narayanan, Vidya" X-OriginalArrivalTime: 05 Oct 2006 19:22:20.0440 (UTC) FILETIME=[93E0A180:01C6E8B3] DKIM-Signature: a=rsa-sha1; q=dns; l=15484; t=1160076147; x=1160940147; c=relaxed/simple; s=sjdkim7002; 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:RE=3A=20[Nea]=20WG=20Review=3A=20Network=20Endpoint=20Assessment=20(nea) =20; X=v=3Dcisco.com=3B=20h=3D24OPQ/hDvxMphtVazzHvPsPXVFg=3D; b=NKm9qKbD8A7ecz72QW/cC7T5l9x0oE1WHo10wlU0E2/G8eqXLkR04UM6ujElAE4wLMmkfxbU 1T9Yp23jlLyg7gkj198mOCn/6tXIhh6GfKrLCwdbshWVAzak0ctvstsd; Authentication-Results: sj-dkim-7.cisco.com; header.From=sethomso@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 715d0e6950aaebd45af78ef9318d0186 Cc: nea@ietf.org, iesg@ietf.org, ietf@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 Vidya Thanks for your comments. Inline ... > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com]=20 > Sent: Wednesday, October 04, 2006 12:48 PM > To: iesg@ietf.org > Cc: nea@ietf.org > Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea)=20 >=20 >=20 > All, > Comments on the charter inline below. =20 >=20 > > -----Original Message----- > > From: IESG Secretary [mailto:iesg-secretary@ietf.org]=20 > > Sent: Monday, October 02, 2006 7:30 AM > > To: ietf-announce@ietf.org > > Cc: nea@ietf.org > > Subject: [Nea] WG Review: Network Endpoint Assessment (nea)=20 > >=20 > > A new IETF working group has been proposed in the Security Area. =20 > > The IESG has not made any determination as yet. The following=20 > > draft charter was submitted, and is provided for=20 > > informational purposes only. > > Please send your comments to the IESG mailing list=20 > > (iesg@ietf.org) by October 9. > >=20 > > +++ > >=20 > > Network Endpoint Assessment (nea) > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > Current Status: Proposed Working Group > >=20 > > Chair(s):=20 > > TBD > >=20 > > Security Area Director(s): > > Russ Housley > > Sam Hartman > >=20 > > Security Area Advisor: > > Russ Housley > >=20 > > Mailing List: nea@ietf.org > >=20 > > Description of Working Group: > >=20 > > Network Endpoint Assessment (NEA) architectures have been=20 > > implemented in the industry to assess the "posture" of=20 > > endpoint devices for the purposes of monitoring compliance to=20 > > an organization's posture policy and optionally restricting=20 > > access until the endpoint has been updated to satisfy the=20 > > posture requirements. An endpoint that does not comply with=20 > > posture policy may be vulnerable to a number of known threats=20 > > that may exist on the network. The intent of NEA is to=20 > > facilitate corrective actions to address these known=20 > > vulnerabilities before a host is exposed to potential attack. >=20 >=20 > Is it fair to then say that NEA is attempting to protect the=20 > endhost and > not necessarily the network?=20 Yes, this is the focus.=20 > That is not immediately clear in the > charter. Obviously, the network must deal with all kinds of known and > unknown threats and a process like NEA is inadequate to protect it at > any acceptable level. That is why we employ a number of other=20 > mechanisms > like firewalls, access control, packet filters, IDS/IPS, etc. in any > combination to appropriately protect the networks.=20 >=20 > So, stating that NEA is not attempting to protect the network at large > would bring a lot of clarity to the charter.=20 >=20 Since we have been around the block a few times on this section, could you suggest precise text that you would like to see to make this clearer? =20 >=20 > > Two deployment scenarios will be supported: advisory mode and=20 > > mandatory mode. > > In advisory mode, an endpoint may be advised of the result of=20 > > posture assessment and any recommended remediation actions,=20 > > but is provided normal network access regardless of the=20 > > result. In mandatory mode, a non-compliant endpoint is given=20 > > restricted access to the network sufficient for remediation=20 > > purposes and any essential services or denied access completely. > >=20 >=20 > It is unclear how the advisory vs mandatory model relates to the NEA > procedures itself. NEA is attempting to provide a vehicle to perform > some compliance tests on acceptable "postures". What the=20 > network decides > to do with that information seems entirely dependent on the policy of > the network and the extent of non-compliance, etc. What does=20 > it mean to > say that NEA *allows* an advisory and/or a mandatory model?=20 >=20 >=20 Yes, it is a matter of policy. We have had other input as well that indicates this text is causing confusion. We added this text in consultation with our AD to re-inforce the notion that NEA did not necessarily imply enforcement, and that things like emergency services could be made available regardless of the outcome of posture assessment. The intention is not to be prescriptive about an organization's policy in any way. Bearing the original motivation in mind, would the following work better? "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. For example,=20 potential deployment scenarios may include,but are not limited to,=20 providing normal access regardless of compliance with 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").=20 > > Posture refers to the hardware or software configuration of=20 > > an endpoint as it pertains to an organization's security=20 > > policy. Posture may include knowledge that software installed=20 > > to protect the machine (e.g. patch management software,=20 > > anti-virus software, host firewall software, host intrusion=20 > > protection software or any custom software) is enabled and=20 > up-to-date. > > On network access and while connected, an endpoint supporting=20 > > NEA protocols can be queried for such posture information in=20 > > either advisory or mandatory modes. > >=20 >=20 > Again, what does it mean to be queried in a particular mode?=20 >=20 Based on consensus re the above, reference to the "modes" may be able to be dropped. > > Since NEA involves many different components from different=20 > > vendors, interoperation >=20 > s/interoperation/interoperability >=20 OK. > > is highly desirable. The priority of=20 > > the NEA working group is to standardize protocols at the=20 > > higher layers in the architectures: > > the Posture Attribute protocol (PA) and the Posture Broker=20 > > protocol (PB). > > PA and PB will be designed to support a variety of lower=20 > > layer protocols. > > When used with standards for lower layers, these new=20 > > protocols will allow interoperability between an NEA Client=20 > > from one vendor and an NEA Server from another. > >=20 >=20 > This seems like an optimistic goal. Given that only a subset of > attributes are envisioned to be standardized and given that=20 > the kind of > attributes are likely to be ever increasing, considering that posture > refers to hardware/software configuration of an endpoint, I=20 > fail to see > how we would practically get NEA clients and NEA servers from=20 > different > vendors to perform any meaningful NEA procedures. In theory, I can see > how this can be slated to be a goal - but, I have to believe that > reality would be different.=20 >=20 This was discussed at last BOF, and resolution was to require that vendor-specific attributes be documented in a RFC.=20 Its also possible that components of a client and components of a server are provided by same or different vendors, i.e. interoperability is not necessarily an all or nothing proposition.=20 >=20 > > Since there are already several non-standard protocols at=20 > > these higher layers, the NEA working group will consider=20 > > these existing protocols as candidates for standardization. A=20 > > requirements document will be written and used as a basis for=20 > > evaluating the candidate protocols. > > The working group may decide to standardize one of the=20 > > candidate protocols, use one of them as a basis for a new or=20 > > revised protocol, or decide that a new protocol is needed. > >=20 > > The NEA Requirements document will include a problem=20 > > statement, definition of terms, requirements for the PA and=20 > > PB protocols, and an overall security analysis. It will also=20 > > include generic requirements for the protocol transporting=20 > > PA, PB: the Posture Transport protocol (PT). PT protocols may=20 > > be standardized in other WGs since these protocols may not be=20 > > specific to NEA. The NEA WG will identify one mandatory to=20 > > implement PT protocol to ensure interoperability. > >=20 >=20 > I assume that the mandatory to implement PT protocol must satisfy the > criteria that will allow the NEA process to be triggered at any time > (i.e., during or after network access). Clarifying this would=20 > be good.=20 >=20 There is text in a few paragraphs above that says "on network access and while connected, an endpoint supporting NEA protocols can be queried for such posture information". Is this not sufficient? >=20 > > PA, the Posture Attribute protocol, consists of posture=20 > > attributes that are carried between a particular Posture=20 > > Collector in a NEA client and a particular Posture Validator=20 > > in a NEA Server. The PA protocol is carried inside the PB=20 > > protocol. Certain posture attributes will be standardized to=20 > > ensure interoperability but vendor-specific attributes will=20 > > also be supported. Vendor-specific attributes must be=20 > > documented in an RFC. > >=20 >=20 > This goes back to my comment on interoperability. Unless it=20 > is expected > that there will be ongoing efforts to continually standardize=20 > attributes > of significance to the community as the hardware/software=20 > configurations > of devices evolve, I am afraid that we won't have interoperability of > any significance.=20 >=20 Ongoing standardization of attributes can be done as necessary.=20 >=20 > > The PB (Posture Broker) protocol aggregates posture=20 > > attributes from one or more Posture Collectors in an NEA=20 > > client and sends them to the NEA server for assessment by one=20 > > or more Posture Validators. > >=20 > > The PT (Posture Transport) protocol (or stack of protocols)=20 > > is suitable for carrying the PB protocol at the time of=20 > > network connection, or shortly after. > >=20 > > The NEA working group will not specify protocols other than=20 > > PA and PB at this time. The expectation is that an existing=20 > > protocol can be used for the PT. > >=20 > >=20 > > One commonly discussed issue with NEA systems is how to=20 > > handle compromised endpoints, whose reports of their own=20 > > posture may not be accurate. Detecting or handling such=20 > > endpoints is out of scope of the NEA WG. Work on PA will=20 > > focus on attributes useful for assessing posture of those=20 > > endpoints reporting accurate information. However, the=20 > > protocols developed by the NEA WG must be designed to=20 > > accommodate emerging technologies for identifying and dealing=20 > > with lying endpoints. > >=20 >=20 >=20 > I'm not sure what the last sentence means here - everything in this > paragraph alludes to the fact that lying endpoints are out of=20 > scope. If > the last sentence is alluding to the TCG efforts, why is it=20 > cryptic? As > currently stated, it doesn't seem to add any value. If we say that in > order for NEA to have a meaningful use case, it must work=20 > together with > some of the TCG stuff, then, perhaps that is effort that the WG must > ensure gets done.=20 >=20 The last sentence was added as a result of the consensus reached at the last BOF. The intent is to make sure that NEA is compatible with emerging technologies to address "lying endpoints" so that they can be used together if a user chooses to do so.=20 TCG is one example that could place requirements on NEA to ensure compatibility, but need not be the only one. My understanding (although I am no expert) is that requirements include providing a multi-round sequenced message exchange with authentication of the server, confidentiality, and integrity protection. Such requirements are not expected to be onerous.=20 >=20 > > Note that NEA is not chartered to standardize 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. There is an open issue=20 > > with respect to NEA applicability in deployment scenarios=20 > > where the endpoint is owned by a party that is different from=20 > > the organization providing network access. > >=20 >=20 >=20 > Why is this an open issue? When the endpoint and the organization > providing network access are owned by different parties, it=20 > simply does > not seem to be viable to do any kind of configuration=20 > assessment on the > endpoint. I think this should be stated rather clearly along these > lines:=20 >=20 > "NEA is limited in applicability to the case where the=20 > endpoint is owned > by the organization providing network access and performing the > assessment. In the cases where the two belong to a different party, it > is practically infeasible for an organization providing network access > to perform any kind of posture assessment or related=20 > compliance tests on > the endpoint." >=20 The reason we left it open is to allow the working group to spend more time exploring the range of use cases in this area to better determine requirements and applicability. For example, it may be useful to classify endpoints as network-managed versus user-managed versus 3rd-party managed. A user-managed endpoint may want the choice to opt in or opt out, say. Thanks Susan > Thanks, > Vidya >=20 >=20 > > Further work in the NEA WG will be considered via the=20 > > standard rechartering process after the completion of these=20 > > milestones. > >=20 > > Milestones: > >=20 > > June 2006: > > * Submit first version of NEA Requirements I-D > >=20 > > July 2006: > > * Agree on charter and milestones at IETF 66 > >=20 > > October 2006: > > * Submit first draft of NEA Requirements I-D > >=20 > > November 2006: > > * At IETF 67, discuss issues with NEA Requirements I-D > > * Agree on solutions to issues with NEA Requirements I-D > >=20 > > December 2006: > > * Deadline for submission of candidate specs for PA and PB > > * Submit first version of NEA Evaluation I-D > >=20 > > January 2007: > > * WG Last Call on NEA Evaluation I-D > >=20 > > February 2007: > > * Submit NEA Requirements I-D and Evaluation I-D to IESG as Info RFC > > * Submit first draft of PA and PB specs for review > >=20 > > March 2007: > > * Discuss unresolved issues with PA and PB specs at IETF 68 > > * Agree on solutions to unresolved issues with PA and PB specs > >=20 > > April 2007: > > * Submit revised draft of PA and PB specs > >=20 > > June 2007 > > * WG Last Call on PA and PB specs > >=20 > > July 2007 > > * Resolve outstanding WGLC comments on PA and PB specs at IETF 69 > >=20 > > August 2007: > > * Submit PA and PB specs to IESG for publication as Proposed > >=20 > > September 2007: > > * Decide how to address MTI PT, recharter if needed > >=20 > > _______________________________________________ > > Nea mailing list > > Nea@ietf.org > > https://www1.ietf.org/mailman/listinfo/nea > >=20 >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Oct 06 08:12:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVoZD-0001ID-RZ; Fri, 06 Oct 2006 08:12:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVgsa-0005Eu-36; Fri, 06 Oct 2006 00:00:08 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVgsY-00050K-Qr; Fri, 06 Oct 2006 00:00:08 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id E2430E012C; Thu, 5 Oct 2006 23:59:53 -0400 (EDT) From: Sam Hartman To: "Susan Thomson (sethomso)" Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) References: Date: Thu, 05 Oct 2006 23:59:53 -0400 In-Reply-To: (Susan Thomson's message of "Thu, 5 Oct 2006 15:22:18 -0400") 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: 7d33c50f3756db14428398e2bdedd581 X-Mailman-Approved-At: Fri, 06 Oct 2006 08:12:38 -0400 Cc: nea@ietf.org, iesg@ietf.org, ietf@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 >>>>> "Susan" == Susan Thomson (sethomso) writes: Susan> regard. For example, potential deployment scenarios may Susan> include,but are not limited to, providing normal access Drop the may include. You want to have at least one or two deployments that you commit to solving to check your requirements against. You can have include but are not limited if you like. Susan> Susan> regardless of compliance with recommendations for Susan> remediation ("advisory mode"), as well as providing Susan> restricted access sufficient for remediation purposes and Susan> any essential services until an endpoint is in compliance Susan> ("mandatory mode"). I express no preference on whether or not the new or old text is better. I just want to commit to at least one deployment. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Oct 06 16:49:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVwdM-0001AF-J7; Fri, 06 Oct 2006 16:49:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVwdL-0001A3-Jz; Fri, 06 Oct 2006 16:49:27 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVwdK-0006XN-Mf; Fri, 06 Oct 2006 16:49:27 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k96KnO8A029522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 6 Oct 2006 13:49:25 -0700 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k96KnLPo003966; Fri, 6 Oct 2006 13:49:23 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Oct 2006 13:49:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea) Date: Fri, 6 Oct 2006 13:49:11 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] WG Review: Network Endpoint Assessment (nea) thread-index: AcbmL2OwptAyLGTBRR6xqHVKCI1vhwBpJQLgAAGgagAAZuh3YA== From: "Narayanan, Vidya" To: "Susan Thomson \(sethomso\)" X-OriginalArrivalTime: 06 Oct 2006 20:49:20.0691 (UTC) FILETIME=[E5CD7830:01C6E988] X-Spam-Score: 0.0 (/) X-Scan-Signature: dc7bd83d90806aed39f33478866e2683 Cc: nea@ietf.org, iesg@ietf.org, ietf@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 Susan, Please see inline. =20 > -----Original Message----- > From: Susan Thomson (sethomso) [mailto:sethomso@cisco.com]=20 > Sent: Thursday, October 05, 2006 12:22 PM > To: Narayanan, Vidya > Cc: nea@ietf.org; iesg@ietf.org; ietf@ietf.org > Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea)=20 >=20 > Hi Vidya >=20 > Thanks for your comments. >=20 > Inline ... >=20 > > -----Original Message----- > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > Sent: Wednesday, October 04, 2006 12:48 PM > > To: iesg@ietf.org > > Cc: nea@ietf.org > > Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea) > >=20 > >=20 > > All, > > Comments on the charter inline below. =20 > >=20 > > > -----Original Message----- > > > From: IESG Secretary [mailto:iesg-secretary@ietf.org] > > > Sent: Monday, October 02, 2006 7:30 AM > > > To: ietf-announce@ietf.org > > > Cc: nea@ietf.org > > > Subject: [Nea] WG Review: Network Endpoint Assessment (nea) > > >=20 > > > A new IETF working group has been proposed in the Security Area. =20 > > > The IESG has not made any determination as yet. The=20 > following draft=20 > > > charter was submitted, and is provided for informational purposes=20 > > > only. > > > Please send your comments to the IESG mailing list > > > (iesg@ietf.org) by October 9. > > >=20 > > > +++ > > >=20 > > > Network Endpoint Assessment (nea) > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > >=20 > > > Current Status: Proposed Working Group > > >=20 > > > Chair(s):=20 > > > TBD > > >=20 > > > Security Area Director(s): > > > Russ Housley > > > Sam Hartman > > >=20 > > > Security Area Advisor: > > > Russ Housley > > >=20 > > > Mailing List: nea@ietf.org > > >=20 > > > Description of Working Group: > > >=20 > > > Network Endpoint Assessment (NEA) architectures have been=20 > > > implemented in the industry to assess the "posture" of endpoint=20 > > > devices for the purposes of monitoring compliance to an=20 > > > organization's posture policy and optionally restricting access=20 > > > until the endpoint has been updated to satisfy the posture=20 > > > requirements. An endpoint that does not comply with=20 > posture policy=20 > > > may be vulnerable to a number of known threats that may=20 > exist on the=20 > > > network. The intent of NEA is to facilitate corrective actions to=20 > > > address these known vulnerabilities before a host is exposed to=20 > > > potential attack. > >=20 > >=20 > > Is it fair to then say that NEA is attempting to protect=20 > the endhost=20 > > and not necessarily the network? >=20 > Yes, this is the focus.=20 >=20 > > That is not immediately clear in the > > charter. Obviously, the network must deal with all kinds of=20 > known and=20 > > unknown threats and a process like NEA is inadequate to=20 > protect it at=20 > > any acceptable level. That is why we employ a number of other=20 > > mechanisms like firewalls, access control, packet filters, IDS/IPS,=20 > > etc. in any combination to appropriately protect the networks. > >=20 > > So, stating that NEA is not attempting to protect the=20 > network at large=20 > > would bring a lot of clarity to the charter. > >=20 >=20 > Since we have been around the block a few times on this=20 > section, could you suggest precise text that you would like=20 > to see to make this clearer? =20 >=20 How about adding this text - "It should be noted that the networks at large are exposed to attacks from lying endpoints and external entities attaching to the networks as well as any problems arising from unknown vulnerabilities on NEA compliant endpoints. Hence, NEA must not be considered a protection mechanism for networks. Further, mechanisms needed to protect the network from all kinds of vulnerabilities are expected to be a superset of any protection that may be achieved by employing NEA"?=20 > >=20 > > > Two deployment scenarios will be supported: advisory mode and=20 > > > mandatory mode. > > > In advisory mode, an endpoint may be advised of the result of=20 > > > posture assessment and any recommended remediation=20 > actions, but is=20 > > > provided normal network access regardless of the result. In=20 > > > mandatory mode, a non-compliant endpoint is given=20 > restricted access=20 > > > to the network sufficient for remediation purposes and=20 > any essential=20 > > > services or denied access completely. > > >=20 > >=20 > > It is unclear how the advisory vs mandatory model relates=20 > to the NEA=20 > > procedures itself. NEA is attempting to provide a vehicle=20 > to perform=20 > > some compliance tests on acceptable "postures". What the network=20 > > decides to do with that information seems entirely dependent on the=20 > > policy of the network and the extent of non-compliance,=20 > etc. What does=20 > > it mean to say that NEA *allows* an advisory and/or a=20 > mandatory model? > >=20 > >=20 > Yes, it is a matter of policy. We have had other input as=20 > well that indicates this text is causing confusion. We added=20 > this text in consultation with our AD to re-inforce the=20 > notion that NEA did not necessarily imply enforcement, and=20 > that things like emergency services could be made available=20 > regardless of the outcome of posture assessment. >=20 > The intention is not to be prescriptive about an=20 > organization's policy in any way. >=20 > Bearing the original motivation in mind, would the following=20 > work better? > "An organization may make a range of policy decisions based=20 > on the posture of an endpoint. NEA is not intended to be=20 > prescriptive in this regard. For example, potential=20 > deployment scenarios may include,but are not limited to,=20 > providing normal access regardless of compliance with=20 > recommendations for remediation ("advisory mode"), as well as=20 > providing restricted access sufficient for remediation=20 > purposes and any essential services until an endpoint is in=20 > compliance ("mandatory mode").=20 >=20 I'm not sure that the charter actually needs to get into the modes at all - I'm guessing what happens after NEA (i.e., what is done with the results from NEA) has zero impact on any work being done in NEA itself. So, why not simply state something like "Once NEA is conducted on an endpoint, the results may be used by an organization in accordance with any policies of the organization itself."?=20 > > > Posture refers to the hardware or software configuration of an=20 > > > endpoint as it pertains to an organization's security policy.=20 > > > Posture may include knowledge that software installed to=20 > protect the=20 > > > machine (e.g. patch management software, anti-virus=20 > software, host=20 > > > firewall software, host intrusion protection software or=20 > any custom=20 > > > software) is enabled and > > up-to-date. > > > On network access and while connected, an endpoint supporting NEA=20 > > > protocols can be queried for such posture information in either=20 > > > advisory or mandatory modes. > > >=20 > >=20 > > Again, what does it mean to be queried in a particular mode?=20 > >=20 >=20 > Based on consensus re the above, reference to the "modes" may=20 > be able to be dropped. >=20 > > > Since NEA involves many different components from=20 > different vendors,=20 > > > interoperation > >=20 > > s/interoperation/interoperability > >=20 >=20 > OK. >=20 > > > is highly desirable. The priority of the NEA working group is to=20 > > > standardize protocols at the higher layers in the architectures: > > > the Posture Attribute protocol (PA) and the Posture=20 > Broker protocol=20 > > > (PB). > > > PA and PB will be designed to support a variety of lower layer=20 > > > protocols. > > > When used with standards for lower layers, these new=20 > protocols will=20 > > > allow interoperability between an NEA Client from one=20 > vendor and an=20 > > > NEA Server from another. > > >=20 > >=20 > > This seems like an optimistic goal. Given that only a subset of=20 > > attributes are envisioned to be standardized and given that=20 > the kind=20 > > of attributes are likely to be ever increasing, considering that=20 > > posture refers to hardware/software configuration of an endpoint, I=20 > > fail to see how we would practically get NEA clients and=20 > NEA servers=20 > > from different vendors to perform any meaningful NEA procedures. In=20 > > theory, I can see how this can be slated to be a goal -=20 > but, I have to=20 > > believe that reality would be different. > >=20 >=20 > This was discussed at last BOF, and resolution was to require=20 > that vendor-specific attributes be documented in a RFC.=20 >=20 > Its also possible that components of a client and components=20 > of a server are provided by same or different vendors, i.e.=20 > interoperability is not necessarily an all or nothing proposition.=20 >=20 I realize that. I guess some people are convinced that the subset standardized will be sufficient for some meaningful interoperability. I will have to wait to see the interoperable deployments to be convinced of that :)=20 > >=20 > > > Since there are already several non-standard protocols at these=20 > > > higher layers, the NEA working group will consider these existing=20 > > > protocols as candidates for standardization. A=20 > requirements document=20 > > > will be written and used as a basis for evaluating the candidate=20 > > > protocols. > > > The working group may decide to standardize one of the candidate=20 > > > protocols, use one of them as a basis for a new or=20 > revised protocol,=20 > > > or decide that a new protocol is needed. > > >=20 > > > The NEA Requirements document will include a problem statement,=20 > > > definition of terms, requirements for the PA and PB=20 > protocols, and=20 > > > an overall security analysis. It will also include generic=20 > > > requirements for the protocol transporting PA, PB: the Posture=20 > > > Transport protocol (PT). PT protocols may be standardized=20 > in other=20 > > > WGs since these protocols may not be specific to NEA. The NEA WG=20 > > > will identify one mandatory to implement PT protocol to ensure=20 > > > interoperability. > > >=20 > >=20 > > I assume that the mandatory to implement PT protocol must=20 > satisfy the=20 > > criteria that will allow the NEA process to be triggered at=20 > any time=20 > > (i.e., during or after network access). Clarifying this=20 > would be good. > >=20 >=20 > There is text in a few paragraphs above that says "on network=20 > access and while connected, an endpoint supporting NEA=20 > protocols can be queried for such posture information". Is=20 > this not sufficient? >=20 That is not necessarily putting any requirements in the choice of the mandatory to implement protocol itself, as I see it. I believe that stating something like "The mandatory to implement PT protocol must be generic enough to allow the execution of the NEA procedure without forcing the need to re-execute network access procedures".=20 > >=20 > > > PA, the Posture Attribute protocol, consists of posture=20 > attributes=20 > > > that are carried between a particular Posture Collector in a NEA=20 > > > client and a particular Posture Validator in a NEA Server. The PA=20 > > > protocol is carried inside the PB protocol. Certain posture=20 > > > attributes will be standardized to ensure interoperability but=20 > > > vendor-specific attributes will also be supported.=20 > Vendor-specific=20 > > > attributes must be documented in an RFC. > > >=20 > >=20 > > This goes back to my comment on interoperability. Unless it is=20 > > expected that there will be ongoing efforts to continually=20 > standardize=20 > > attributes of significance to the community as the=20 > hardware/software=20 > > configurations of devices evolve, I am afraid that we won't have=20 > > interoperability of any significance. > >=20 >=20 > Ongoing standardization of attributes can be done as necessary.=20 >=20 This, to me, indicates that this is a WG that may never actually close :) Again, I'll have to wait for deployments to convince myself!=20 > >=20 > > > The PB (Posture Broker) protocol aggregates posture=20 > attributes from=20 > > > one or more Posture Collectors in an NEA client and sends them to=20 > > > the NEA server for assessment by one or more Posture Validators. > > >=20 > > > The PT (Posture Transport) protocol (or stack of protocols) is=20 > > > suitable for carrying the PB protocol at the time of network=20 > > > connection, or shortly after. > > >=20 > > > The NEA working group will not specify protocols other=20 > than PA and=20 > > > PB at this time. The expectation is that an existing=20 > protocol can be=20 > > > used for the PT. > > >=20 > > >=20 > > > One commonly discussed issue with NEA systems is how to handle=20 > > > compromised endpoints, whose reports of their own posture=20 > may not be=20 > > > accurate. Detecting or handling such endpoints is out of scope of=20 > > > the NEA WG. Work on PA will focus on attributes useful=20 > for assessing=20 > > > posture of those endpoints reporting accurate=20 > information. However,=20 > > > the protocols developed by the NEA WG must be designed to=20 > > > accommodate emerging technologies for identifying and=20 > dealing with=20 > > > lying endpoints. > > >=20 > >=20 > >=20 > > I'm not sure what the last sentence means here - everything in this=20 > > paragraph alludes to the fact that lying endpoints are out=20 > of scope.=20 > > If the last sentence is alluding to the TCG efforts, why is it=20 > > cryptic? As currently stated, it doesn't seem to add any=20 > value. If we=20 > > say that in order for NEA to have a meaningful use case, it=20 > must work=20 > > together with some of the TCG stuff, then, perhaps that is=20 > effort that=20 > > the WG must ensure gets done. > >=20 >=20 > The last sentence was added as a result of the consensus=20 > reached at the last BOF. The intent is to make sure that NEA=20 > is compatible with emerging technologies to address "lying=20 > endpoints" so that they can be used together if a user=20 > chooses to do so.=20 >=20 > TCG is one example that could place requirements on NEA to=20 > ensure compatibility, but need not be the only one. My=20 > understanding (although I am no expert) is that requirements=20 > include providing a multi-round sequenced message exchange=20 > with authentication of the server, confidentiality, and=20 > integrity protection. Such requirements are not expected to=20 > be onerous.=20 >=20 I guess the text leaves it so open-ended that it fails to add any value. Unless we know what technologies NEA must be able to work with, how can the protocols be designed to work with those technologies? I am completely missing the point of this text.=20 > >=20 > > > Note that NEA is not chartered to standardize protocols for=20 > > > remediation. > > > NEA is intended to be used with new or existing tools that can be=20 > > > used in the absence of NEA. There is an open issue with=20 > respect to=20 > > > NEA applicability in deployment scenarios where the endpoint is=20 > > > owned by a party that is different from the organization=20 > providing=20 > > > network access. > > >=20 > >=20 > >=20 > > Why is this an open issue? When the endpoint and the organization=20 > > providing network access are owned by different parties, it simply=20 > > does not seem to be viable to do any kind of configuration=20 > assessment=20 > > on the endpoint. I think this should be stated rather clearly along=20 > > these > > lines:=20 > >=20 > > "NEA is limited in applicability to the case where the endpoint is=20 > > owned by the organization providing network access and=20 > performing the=20 > > assessment. In the cases where the two belong to a=20 > different party, it=20 > > is practically infeasible for an organization providing=20 > network access=20 > > to perform any kind of posture assessment or related=20 > compliance tests=20 > > on the endpoint." > >=20 >=20 > The reason we left it open is to allow the working group to spend more > time exploring the range of use cases in this area to better determine > requirements and applicability. For example, it may be useful to > classify endpoints as network-managed versus user-managed versus > 3rd-party managed. A user-managed endpoint may want the=20 > choice to opt in > or opt out, say. >=20 Not only do I not see anything in the charter or milestones that indicates that the WG is going to spend time exploring this, I strongly believe this WG should not be spending any time looking at this. The trust models for the cases where the devices are not owned by the organization performing NEA are hugely different and can take up its own WG to actually find something that applies there, if at all. For one, this could be considered a violation of privacy by the user of the device. Secondly, the end user's perspective of attacks may be entirely different from the organization's perspective in this case. Third, I simply can't see what the organization's interests would be in protecting a device that doesn't even belong to it. Last but not the least, this requires the endpoint to be running an NEA client (that is interoperable with the NEA server of the organization) - which in itself is often an unrealistic requirement.=20 Organizations that provide services in their networks to end users are worried about protecting their resources (i.e., networks, servers, etc.). As we have agreed, NEA does not protect such resources anyway. Plus, there is absolutely no reason such organizations should believe that devices they don't own are in fact, truthful endpoints.=20 So, thinking that this WG must be looking into resolving this seems flawed at several levels. In the interest of having a focused WG that can get something useful accomplished, this does not make sense.=20 Thanks, Vidya > Thanks > Susan >=20 > > Thanks, > > Vidya > >=20 > >=20 > > > Further work in the NEA WG will be considered via the=20 > > > standard rechartering process after the completion of these=20 > > > milestones. > > >=20 > > > Milestones: > > >=20 > > > June 2006: > > > * Submit first version of NEA Requirements I-D > > >=20 > > > July 2006: > > > * Agree on charter and milestones at IETF 66 > > >=20 > > > October 2006: > > > * Submit first draft of NEA Requirements I-D > > >=20 > > > November 2006: > > > * At IETF 67, discuss issues with NEA Requirements I-D > > > * Agree on solutions to issues with NEA Requirements I-D > > >=20 > > > December 2006: > > > * Deadline for submission of candidate specs for PA and PB > > > * Submit first version of NEA Evaluation I-D > > >=20 > > > January 2007: > > > * WG Last Call on NEA Evaluation I-D > > >=20 > > > February 2007: > > > * Submit NEA Requirements I-D and Evaluation I-D to IESG=20 > as Info RFC > > > * Submit first draft of PA and PB specs for review > > >=20 > > > March 2007: > > > * Discuss unresolved issues with PA and PB specs at IETF 68 > > > * Agree on solutions to unresolved issues with PA and PB specs > > >=20 > > > April 2007: > > > * Submit revised draft of PA and PB specs > > >=20 > > > June 2007 > > > * WG Last Call on PA and PB specs > > >=20 > > > July 2007 > > > * Resolve outstanding WGLC comments on PA and PB specs at IETF 69 > > >=20 > > > August 2007: > > > * Submit PA and PB specs to IESG for publication as Proposed > > >=20 > > > September 2007: > > > * Decide how to address MTI PT, recharter if needed > > >=20 > > > _______________________________________________ > > > Nea mailing list > > > Nea@ietf.org > > > https://www1.ietf.org/mailman/listinfo/nea > > >=20 > >=20 > > _______________________________________________ > > Nea mailing list > > Nea@ietf.org > > https://www1.ietf.org/mailman/listinfo/nea > >=20 >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Sat Oct 07 13:42:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWGCB-0000Y8-A3; Sat, 07 Oct 2006 13:42:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWGC9-0000Xx-Op; Sat, 07 Oct 2006 13:42:41 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWGC8-0003In-DU; Sat, 07 Oct 2006 13:42:41 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k97HgZw0015395 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 7 Oct 2006 10:42:36 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-68-22.qualcomm.com [10.50.68.22]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k97HgXbr003803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 7 Oct 2006 10:42:34 -0700 (PDT) Message-Id: <7.0.1.0.2.20061007100953.059f1120@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sat, 07 Oct 2006 10:42:31 -0700 To: Harald Alvestrand , "Narayanan, Vidya" From: Lakshminath Dondeti Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) In-Reply-To: <4527685D.1090904@alvestrand.no> References: <4527685D.1090904@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: nea@ietf.org, iesg@ietf.org, ietf@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 01:42 AM 10/7/2006, Harald Alvestrand wrote: >> >Many universities require their students to buy their own laptops, >but prohibit certain types of activity from those laptops (like >spamming, DDOS-attacks and the like). They would love to have the >ability to run some kind of NEA procedure to ensure that laptops are >reasonably virus-free and free from known vulnerabilities, and are >important enough in their students' lives that they can probably >enforce it without a complaint about "violation of privacy". > >Just pointing out that there's one use case with user-managed >endpoints where NEA is not obviously a bad idea. My email ventures into a bit of non-IETF territory, but we are discussing use cases, and so I guess it's on topic. Universities should be the last places to try antics like NEA. Whereas an operational network would be a priority to them, it is also important that they allow students to experiment with new applications. If we are believing that general purpose computing will be taken away from college students, we are indeed talking about a different world. In any event, the bottomline is NEA as a solution to "network protection" is a leaky bucket at best. NEA at best *may* raise the bar in attacking a "closed" network where endpoints are owned and tightly controlled by the organization that owns the network. Lakshminath > Harald > > >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Sat Oct 07 15:17:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWHg6-0007j9-BW; Sat, 07 Oct 2006 15:17:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWDql-0007mn-4l; Sat, 07 Oct 2006 11:12:27 -0400 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWDqj-0004Ua-QW; Sat, 07 Oct 2006 11:12:27 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ICU85jg8S9IA06UVuM6CaMI77CUczUKcshmviwf+Cn4+e5sndc1hu9MICc9yYj/t; 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.48.107] (helo=gw) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GWDqe-0004vX-Cz; Sat, 07 Oct 2006 11:12:24 -0400 Message-ID: <002101c6ea23$01f69510$010aa8c0@home.glassey.com> From: "todd glassey" To: "Harald Alvestrand" , "Narayanan, Vidya" References: <4527685D.1090904@alvestrand.no> Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Date: Sat, 7 Oct 2006 07:40:56 -0700 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: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec7958970a48a3a00d08d310e86c5584d83a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.246.48.107 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-Mailman-Approved-At: Sat, 07 Oct 2006 15:17:41 -0400 Cc: nea@ietf.org, iesg@ietf.org, ietf@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 Harald - get Microsoft to buy into this idea and its done. Todd Glassey ----- Original Message ----- From: "Harald Alvestrand" To: "Narayanan, Vidya" Cc: ; ; Sent: Saturday, October 07, 2006 1:42 AM Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) > > > > Not only do I not see anything in the charter or milestones that > > indicates that the WG is going to spend time exploring this, I strongly > > believe this WG should not be spending any time looking at this. The > > trust models for the cases where the devices are not owned by the > > organization performing NEA are hugely different and can take up its own > > WG to actually find something that applies there, if at all. For one, > > this could be considered a violation of privacy by the user of the > > device. Secondly, the end user's perspective of attacks may be entirely > > different from the organization's perspective in this case. Third, I > > simply can't see what the organization's interests would be in > > protecting a device that doesn't even belong to it. Last but not the > > least, this requires the endpoint to be running an NEA client (that is > > interoperable with the NEA server of the organization) - which in itself > > is often an unrealistic requirement. > > Many universities require their students to buy their own laptops, but > prohibit certain types of activity from those laptops (like spamming, > DDOS-attacks and the like). They From nea-bounces@ietf.org Sat Oct 07 15:17:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWHg6-0007j9-BW; Sat, 07 Oct 2006 15:17:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWDql-0007mn-4l; Sat, 07 Oct 2006 11:12:27 -0400 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWDqj-0004Ua-QW; Sat, 07 Oct 2006 11:12:27 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ICU85jg8S9IA06UVuM6CaMI77CUczUKcshmviwf+Cn4+e5sndc1hu9MICc9yYj/t; 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.48.107] (helo=gw) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GWDqe-0004vX-Cz; Sat, 07 Oct 2006 11:12:24 -0400 Message-ID: <002101c6ea23$01f69510$010aa8c0@home.glassey.com> From: "todd glassey" To: "Harald Alvestrand" , "Narayanan, Vidya" References: <4527685D.1090904@alvestrand.no> Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Date: Sat, 7 Oct 2006 07:40:56 -0700 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: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec7958970a48a3a00d08d310e86c5584d83a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.246.48.107 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-Mailman-Approved-At: Sat, 07 Oct 2006 15:17:41 -0400 Cc: nea@ietf.org, iesg@ietf.org, ietf@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 Harald - get Microsoft to buy into this idea and its done. Todd Glassey ----- Original Message ----- From: "Harald Alvestrand" To: "Narayanan, Vidya" Cc: ; ; Sent: Saturday, October 07, 2006 1:42 AM Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) > > > > Not only do I not see anything in the charter or milestones that > > indicates that the WG is going to spend time exploring this, I strongly > > believe this WG should not be spending any time looking at this. The > > trust models for the cases where the devices are not owned by the > > organization performing NEA are hugely different and can take up its own > > WG to actually find something that applies there, if at all. For one, > > this could be considered a violation of privacy by the user of the > > device. Secondly, the end user's perspective of attacks may be entirely > > different from the organization's perspective in this case. Third, I > > simply can't see what the organization's interests would be in > > protecting a device that doesn't even belong to it. Last but not the > > least, this requires the endpoint to be running an NEA client (that is > > interoperable with the NEA server of the organization) - which in itself > > is often an unrealistic requirement. > > Many universities require their students to buy their own laptops, but > prohibit certain types of activity from those laptops (like spamming, > DDOS-attacks and the like). They would love to have the ability to run > some kind of NEA procedure to ensure that laptops are reasonably > virus-free and free from known vulnerabilities, and are important enough > in their students' lives that they can probably enforce it without a > complaint about "violation of privacy". > > Just pointing out that there's one use case with user-managed endpoints > where NEA is not obviously a bad idea. > > Harald > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Sat Oct 07 15:17:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWHg6-0007j4-81; Sat, 07 Oct 2006 15:17:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GW7tW-0005jr-NB; Sat, 07 Oct 2006 04:50:54 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GW7lC-0005cU-7D; Sat, 07 Oct 2006 04:42:19 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0935925817F; Sat, 7 Oct 2006 10:39:44 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04953-03; Sat, 7 Oct 2006 10:39:36 +0200 (CEST) Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9EC2E2580EE; Sat, 7 Oct 2006 10:39:36 +0200 (CEST) Message-ID: <4527685D.1090904@alvestrand.no> Date: Sat, 07 Oct 2006 10:42:05 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.7 (X11/20060921) MIME-Version: 1.0 To: "Narayanan, Vidya" Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-Mailman-Approved-At: Sat, 07 Oct 2006 15:17:41 -0400 Cc: nea@ietf.org, iesg@ietf.org, ietf@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 reason we left it open is to allow the working group to spend more > > time exploring the range of use cases in this area to better determine > > requirements and applicability. For example, it may be useful to > > classify endpoints as network-managed versus user-managed versus > > 3rd-party managed. A user-managed endpoint may want the > > choice to opt in > > or opt out, say. > > > > > Not only do I not see anything in the charter or milestones that > indicates that the WG is going to spend time exploring this, I strongly > believe this WG should not be spending any time looking at this. The > trust models for the cases where the devices are not owned by the > organization performing NEA are hugely different and can take up its own > WG to actually find something that applies there, if at all. For one, > this could be considered a violation of privacy by the user of the > device. Secondly, the end user's perspective of attacks may be entirely > different from the organization's perspective in this casewould love to have the ability to run > some kind of NEA procedure to ensure that laptops are reasonably > virus-free and free from known vulnerabilities, and are important enough > in their students' lives that they can probably enforce it without a > complaint about "violation of privacy". > > Just pointing out that there's one use case with user-managed endpoints > where NEA is not obviously a bad idea. > > Harald > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Sat Oct 07 15:17:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWHg6-0007j4-81; Sat, 07 Oct 2006 15:17:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GW7tW-0005jr-NB; Sat, 07 Oct 2006 04:50:54 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GW7lC-0005cU-7D; Sat, 07 Oct 2006 04:42:19 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 0935925817F; Sat, 7 Oct 2006 10:39:44 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04953-03; Sat, 7 Oct 2006 10:39:36 +0200 (CEST) Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 9EC2E2580EE; Sat, 7 Oct 2006 10:39:36 +0200 (CEST) Message-ID: <4527685D.1090904@alvestrand.no> Date: Sat, 07 Oct 2006 10:42:05 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.7 (X11/20060921) MIME-Version: 1.0 To: "Narayanan, Vidya" Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-Mailman-Approved-At: Sat, 07 Oct 2006 15:17:41 -0400 Cc: nea@ietf.org, iesg@ietf.org, ietf@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 reason we left it open is to allow the working group to spend more > > time exploring the range of use cases in this area to better determine > > requirements and applicability. For example, it may be useful to > > classify endpoints as network-managed versus user-managed versus > > 3rd-party managed. A user-managed endpoint may want the > > choice to opt in > > or opt out, say. > > > > > Not only do I not see anything in the charter or milestones that > indicates that the WG is going to spend time exploring this, I strongly > believe this WG should not be spending any time looking at this. The > trust models for the cases where the devices are not owned by the > organization performing NEA are hugely different and can take up its own > WG to actually find something that applies there, if at all. For one, > this could be considered a violation of privacy by the user of the > device. Secondly, the end user's perspective of attacks may be entirely > different from the organization's perspective in this case. Third, I > simply can't see what the organization's interests would be in > protecting a device that doesn't even belong to it. Last but not the > least, this requires the endpoint to be running an NEA client (that is > interoperable with the NEA server of the organization) - which in itself > is often an unrealistic requirement. Many universities require their students to buy their own laptops, but prohibit certain types of activity from those laptops (like spamming, DDOS-attacks and the like). They would love to have the ability to run some kind of NEA procedure to ensure that laptops are reasonably virus-free and free from known vulnerabilities, and are important enough in their students' lives that they can probably enforce it without a complaint about "violation of privacy". Just pointing out that there's one use case with user-managed endpoints where NEA is not obviously a bad idea. Harald _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea . Third, I > simply can't see what the organization's interests would be in > protecting a device that doesn't even belong to it. Last but not the > least, this requires the endpoint to be running an NEA client (that is > interoperable with the NEA server of the organization) - which in itself > is often an unrealistic requirement. Many universities require their students to buy their own laptops, but prohibit certain types of activity from those laptops (like spamming, DDOS-attacks and the like). They would love to have the ability to run some kind of NEA procedure to ensure that laptops are reasonably virus-free and free from known vulnerabilities, and are important enough in their students' lives that they can probably enforce it without a complaint about "violation of privacy". Just pointing out that there's one use case with user-managed endpoints where NEA is not obviously a bad idea. Harald _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Sat Oct 07 20:04:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWM9L-0002mf-LK; Sat, 07 Oct 2006 20:04:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWM9J-0002mN-KD for nea@ietf.org; Sat, 07 Oct 2006 20:04:09 -0400 Received: from nf-out-0910.google.com ([64.233.182.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWM9H-0001oM-4o for nea@ietf.org; Sat, 07 Oct 2006 20:04:09 -0400 Received: by nf-out-0910.google.com with SMTP id l23so1601339nfc for ; Sat, 07 Oct 2006 17:04:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qWraId5MsOnHDjuXPwwVfVDU4MLDFfXiU5Fdf2PLKpeX6IvXtLNOK+g5RyAIR4nNqkpbBvF53ZGD2tHfmuEntZ9S1vjCFk7A+hL23p4BKPyVOsqC2zdlJFiK4PD2+kk4ksa3oxWj1SSJrvHkTuYsxsXt6YXUgWYEdhhd7UGBY0Q= Received: by 10.49.8.4 with SMTP id l4mr576570nfi; Sat, 07 Oct 2006 17:04:06 -0700 (PDT) Received: by 10.49.22.11 with HTTP; Sat, 7 Oct 2006 17:04:05 -0700 (PDT) Message-ID: Date: Sat, 7 Oct 2006 20:04:05 -0400 From: "Susmit Panjwani" To: "Harald Alvestrand" Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) In-Reply-To: <4527685D.1090904@alvestrand.no> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4527685D.1090904@alvestrand.no> X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: nea@ietf.org, iesg@ietf.org, ietf@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 Third, I > > simply can't see what the organization's interests would be in > > protecting a device that doesn't even belong to it. An organization might not be interested in protecting a device that does not belong to it but would definitely be interested in preventing the attacks originating from such device (if compromised) when it joins the organization network. To cite a study that we performed at UMD: we did a cost-benefit analysis based on the captured attacks from within the organization, and it turns out that the organization would benefit significantly if they implement any trusted network access technology. I do realize that there would be issues in terms of user privacy and interoperability(which this charter is trying to tackle) but just wanted to mention that there would be significant benefits if they can implement it. This is especially true for university environment. As a matter of fact I am aware of some universities/departments that were planning to implement a home grown solution for this. Susmit -- Susmit Panjwani PhD Candidate, Center for Risk and Reliability, University of Maryland Cell: 240-460-9782 On 10/7/06, Harald Alvestrand wrote: > > > > The reason we left it open is to allow the working group to spend more > > > time exploring the range of use cases in this area to better determine > > > requirements and applicability. For example, it may be useful to > > > classify endpoints as network-managed versus user-managed versus > > > 3rd-party managed. A user-managed endpoint may want the > > > choice to opt in > > > or opt out, say. > > > > > > > > > Not only do I not see anything in the charter or milestones that > > indicates that the WG is going to spend time exploring this, I strongly > > believe this WG should not be spending any time looking at this. The > > trust models for the cases where the devices are not owned by the > > organization performing NEA are hugely different and can take up its own > > WG to actually find something that applies there, if at all. For one, > > this could be considered a violation of privacy by the user of the > > device. Secondly, the end user's perspective of attacks may be entirely > > different from the organization's perspective in this case. Third, I > > simply can't see what the organization's interests would be in > > protecting a device that doesn't even belong to it. Last but not the > > least, this requires the endpoint to be running an NEA client (that is > > interoperable with the NEA server of the organization) - which in itself > > is often an unrealistic requirement. > Many universities require their students to buy their own laptops, but > prohibit certain types of activity from those laptops (like spamming, > DDOS-attacks and the like). They would love to have the ability to run > some kind of NEA procedure to ensure that laptops are reasonably > virus-free and free from known vulnerabilities, and are important enough > in their students' lives that they can probably enforce it without a > complaint about "violation of privacy". > > Just pointing out that there's one use case with user-managed endpoints > where NEA is not obviously a bad idea. > > Harald > > > _______________________________________________ > 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 Sun Oct 08 13:05:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWc5V-0005fl-Dp; Sun, 08 Oct 2006 13:05:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWc5U-0005fZ-Mb; Sun, 08 Oct 2006 13:05:16 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWc5T-0006Jm-3t; Sun, 08 Oct 2006 13:05:16 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k98H5753017943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 8 Oct 2006 10:05:08 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k98H55lH022417; Sun, 8 Oct 2006 10:05:06 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 8 Oct 2006 10:05:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea) Date: Sun, 8 Oct 2006 10:05:03 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] WG Review: Network Endpoint Assessment (nea) thread-index: AcbqbkOTiRjr9dBtSFCoMFOj9yQzUQAjAdgg From: "Narayanan, Vidya" To: "Susmit Panjwani" , "Harald Alvestrand" X-OriginalArrivalTime: 08 Oct 2006 17:05:05.0968 (UTC) FILETIME=[E6FD2B00:01C6EAFB] X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: nea@ietf.org, iesg@ietf.org, ietf@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org =20 > -----Original Message----- > From: Susmit Panjwani [mailto:susmit@gmail.com]=20 > Sent: Saturday, October 07, 2006 5:04 PM > To: Harald Alvestrand > Cc: Narayanan, Vidya; nea@ietf.org; iesg@ietf.org; ietf@ietf.org > Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) >=20 > Third, I > > simply can't see what the organization's=20 > interests would be in > > > protecting a device that doesn't even belong to it. >=20 > An organization might not be interested in protecting a=20 > device that does not belong to it but would definitely be=20 > interested in preventing the attacks originating from such=20 > device (if compromised) when it joins the organization=20 > network. =20 It appears that the NEA charter is completely misleading to some people from what is stated in this email. As the NEA charter alludes to, NEA does nothing to protect against compromised devices. Also, as has been agreed, NEA is not a protection mechanism for the network - it is meant to be a protection mechanism for compliant, truthful and as yet uncompromised end hosts against known vulnerabilities.=20 Any network, in its own best interests, must assume that it has lying and compromised endpoints connecting to it and that there are unknown vulnerabilities on any NEA-compliant devices connecting to it. Any kind of protection that addresses these general threats that the network may be exposed to at any time will simply obviate the need for NEA from the network perspective.=20 A network operator that thinks the network is getting any protection by employing NEA is clearly ignoring the obvious real threats that the network is exposed to at any time.=20 This is what I meant when I said that the charter is unclear and it must explicitly state that NEA is not meant as a protection mechanism of any sort for the network.=20 Vidya > To cite a study that we performed at > UMD: we did a cost-benefit analysis based on the captured=20 > attacks from within the organization, and it turns out that=20 > the organization would benefit significantly if they =20 > implement any trusted network access technology. >=20 > I do realize that there would be issues in terms of user=20 > privacy and interoperability(which this charter is trying to=20 > tackle) but just wanted to mention that there would be=20 > significant benefits if they can implement it. This is=20 > especially true for university environment. As a matter of=20 > fact I am aware of some universities/departments that were=20 > planning to implement a home grown solution for this. >=20 > Susmit >=20 > -- > Susmit Panjwani >=20 > PhD Candidate, > Center for Risk and Reliability, > University of Maryland > Cell: 240-460-9782 >=20 >=20 > On 10/7/06, Harald Alvestrand wrote: > > > > > > The reason we left it open is to allow the working group to spend=20 > > > more > > > > time exploring the range of use cases in this area to better=20 > > > > determine requirements and applicability. For example,=20 > it may be=20 > > > > useful to classify endpoints as network-managed versus=20 > > > > user-managed versus 3rd-party managed. A user-managed=20 > endpoint may=20 > > > > want the choice to opt in or opt out, say. > > > > > > > > > > > > > Not only do I not see anything in the charter or milestones that=20 > > > indicates that the WG is going to spend time exploring this, I=20 > > > strongly believe this WG should not be spending any time=20 > looking at=20 > > > this. The trust models for the cases where the devices=20 > are not owned=20 > > > by the organization performing NEA are hugely different=20 > and can take=20 > > > up its own WG to actually find something that applies=20 > there, if at=20 > > > all. For one, this could be considered a violation of=20 > privacy by the=20 > > > user of the device. Secondly, the end user's perspective=20 > of attacks=20 > > > may be entirely different from the organization's perspective in=20 > > > this case. Third, I simply can't see what the organization's=20 > > > interests would be in protecting a device that doesn't=20 > even belong=20 > > > to it. Last but not the least, this requires the endpoint to be=20 > > > running an NEA client (that is interoperable with the NEA=20 > server of=20 > > > the organization) - which in itself is often an=20 > unrealistic requirement. > > Many universities require their students to buy their own=20 > laptops, but=20 > > prohibit certain types of activity from those laptops (like=20 > spamming,=20 > > DDOS-attacks and the like). They would love to have the=20 > ability to run=20 > > some kind of NEA procedure to ensure that laptops are reasonably=20 > > virus-free and free from known vulnerabilities, and are important=20 > > enough in their students' lives that they can probably enforce it=20 > > without a complaint about "violation of privacy". > > > > Just pointing out that there's one use case with user-managed=20 > > endpoints where NEA is not obviously a bad idea. > > > > Harald > > > > > > _______________________________________________ > > Nea mailing list > > Nea@ietf.org > > https://www1.ietf.org/mailman/listinfo/nea > > >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Sun Oct 08 13:14:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWcEk-0002tv-Dl; Sun, 08 Oct 2006 13:14:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWcEj-0002tj-NV; Sun, 08 Oct 2006 13:14:49 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWcEi-0007Av-Ap; Sun, 08 Oct 2006 13:14:49 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k98HEiVS009439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 8 Oct 2006 10:14:44 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.na.qualcomm.com [10.46.92.109]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k98HEg1Z019146; Sun, 8 Oct 2006 10:14:43 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 8 Oct 2006 10:14:42 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea) Date: Sun, 8 Oct 2006 10:14:41 -0700 Message-ID: In-Reply-To: <7.0.1.0.2.20061007100953.059f1120@qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] WG Review: Network Endpoint Assessment (nea) thread-index: AcbqN/rYa/tLhOHyS/OgistR6nbqowAxBQIg From: "Narayanan, Vidya" To: "Dondeti, Lakshminath" , "Harald Alvestrand" X-OriginalArrivalTime: 08 Oct 2006 17:14:42.0717 (UTC) FILETIME=[3EC214D0:01C6EAFD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: nea@ietf.org, iesg@ietf.org, ietf@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org =20 > -----Original Message----- > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]=20 > Sent: Saturday, October 07, 2006 10:43 AM > To: Harald Alvestrand; Narayanan, Vidya > Cc: nea@ietf.org; iesg@ietf.org; ietf@ietf.org > Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) >=20 > At 01:42 AM 10/7/2006, Harald Alvestrand wrote: > >> > >Many universities require their students to buy their own=20 > laptops, but=20 > >prohibit certain types of activity from those laptops (like=20 > spamming,=20 > >DDOS-attacks and the like). They would love to have the=20 > ability to run=20 > >some kind of NEA procedure to ensure that laptops are reasonably=20 > >virus-free and free from known vulnerabilities, and are important=20 > >enough in their students' lives that they can probably enforce it=20 > >without a complaint about "violation of privacy". > > > >Just pointing out that there's one use case with=20 > user-managed endpoints=20 > >where NEA is not obviously a bad idea. >=20 > My email ventures into a bit of non-IETF territory, but we=20 > are discussing use cases, and so I guess it's on topic. =20 > Universities should be the last places to try antics like=20 > NEA. Whereas an operational network would be a priority to=20 > them, it is also important that they allow students to=20 > experiment with new applications. If we are believing that=20 > general purpose computing will be taken away from college=20 > students, we are indeed talking about a different world. >=20 I agree. Even in a controlled environment, there is bound to be software/hardware that does not quite support NEA or specific posture attributes. In a university environment, while some basic posture reporting is feasible, there is bound to be a lot of software/hardware that does not support any NEA parameters. The protection that even the endhost may be getting from NEA is quite limited.=20 > In any event, the bottomline is NEA as a solution to "network=20 > protection" is a leaky bucket at best. >=20 The charter must be clarified to dispel this myth about NEA protecting the network from anything. =20 Vidya > NEA at best *may* raise the bar in attacking a "closed"=20 > network where endpoints are owned and tightly controlled by=20 > the organization that owns the network. >=20 > Lakshminath >=20 >=20 > > Harald > > > > > >_______________________________________________ > >Ietf mailing list > >Ietf@ietf.org > >https://www1.ietf.org/mailman/listinfo/ietf >=20 >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Sun Oct 08 17:20:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWg4l-0002DY-U3; Sun, 08 Oct 2006 17:20:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWg4k-0002DN-B0 for nea@ietf.org; Sun, 08 Oct 2006 17:20:46 -0400 Received: from relay01.ispone.net.au ([124.254.72.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWg4i-0005qQ-Hl for nea@ietf.org; Sun, 08 Oct 2006 17:20:46 -0400 Received: from oscar.sleepycat.com.au (124-254-74-144-static-dsl.ispone.net.au [124.254.74.144]) by relay01.ispone.net.au (8.13.6/8.13.6/Debian-1) with ESMTP id k98LKfsi025224 for ; Mon, 9 Oct 2006 07:20:42 +1000 Message-Id: <200610082120.k98LKfsi025224@relay01.ispone.net.au> 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 1GWg4e-0004Km-KL for nea@ietf.org; Mon, 09 Oct 2006 07:20:41 +1000 Received: (qmail 14944 invoked by uid 453); 8 Oct 2006 20:41:19 -0000 Received: from speedy.dhs (HELO speedy) (192.168.0.8) by dhs (qpsmtpd/0.31-dev) with ESMTP; Mon, 09 Oct 2006 06:41:18 +1000 From: "Darryl \(Dassa\) Lynch" To: Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea) Date: Mon, 9 Oct 2006 07:20:27 +1000 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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 thread-index: AcbqbkOTiRjr9dBtSFCoMFOj9yQzUQAjAdggAAjmGFA= X-Spam-Score: 0.0 (/) 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: Hi Vidya Narayanan, Vidya wrote: >>> Content analysis details: (0.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: nea@ietf.org 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 Hi Vidya Narayanan, Vidya wrote: >>> -----Original Message----- >>> From: Susmit Panjwani [mailto:susmit@gmail.com] >>> Sent: Saturday, October 07, 2006 5:04 PM >>> To: Harald Alvestrand >>> Cc: Narayanan, Vidya; nea@ietf.org; iesg@ietf.org; ietf@ietf.org >>> Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) >>> >>>>> Third, I simply can't see what the organization's interests would be in >>>>> protecting a device that doesn't even belong to it. >>> >>>> An organization might not be interested in protecting a device that >>>> does not belong to it but would definitely be interested in >>>> preventing the attacks originating from such device (if >>>> compromised) when it joins the organization network. >> >> It appears that the NEA charter is completely misleading to >> some people from what is stated in this email. As the NEA >> charter alludes to, NEA does nothing to protect against >> compromised devices. Also, as has been agreed, NEA is not a >> protection mechanism for the network - it is meant to be a >> protection mechanism for compliant, truthful and as yet >> uncompromised end hosts against known vulnerabilities. True the NEA doesn't "do" anything to protect against compromised devices but it does assist in limiting the known compromises on endpoint devices by being a mechanism for the checking and reporting on compliance to what ever network policy is in place including virus and patch levels. As a network administrator I already deploy mechanisms for doing just this, but at a higher level than the NEA charter indicates. To me the difference is between being reactive or proactive. Compliance testing I already run occurs after an end node has joined the network, with NEA the possibility is for compliance checking before being allowed onto the network so isolation and immediate remediation is possible. >> Any network, in its own best interests, must assume that it >> has lying and compromised endpoints connecting to it and >> that there are unknown vulnerabilities on any NEA-compliant >> devices connecting to it. Any kind of protection that >> addresses these general threats that the network may be >> exposed to at any time will simply obviate the need for NEA from the >> network perspective. Reliance on one protection or reporting mechanism is not enough. We need a lot of varied tools to cover all the bases and minimise risk. >> A network operator that thinks the network is getting any >> protection by employing NEA is clearly ignoring the obvious >> real threats that the network is exposed to at any time. No, NEA would just be one more tool used to improve overall security and minimise risk. It would be at a different level to the tools some of already deploy. >> This is what I meant when I said that the charter is unclear >> and it must explicitly state that NEA is not meant as a >> protection mechanism of any sort for the network. I don't believe the Charter needs to delve into this at all. If some people see it as part of their protection mechanisms, so be it. Darryl (Dassa) Lynch _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Sun Oct 08 18:26:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWh6f-0007Li-Ev; Sun, 08 Oct 2006 18:26:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWh6e-0007KA-Qi; Sun, 08 Oct 2006 18:26:48 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWh6c-0001j6-6t; Sun, 08 Oct 2006 18:26:48 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 08 Oct 2006 15:26:45 -0700 X-IronPort-AV: i="4.09,277,1157353200"; d="scan'208"; a="329291022:sNHT60988960" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k98MQjaf000679; Sun, 8 Oct 2006 15:26:45 -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.12.10/8.12.6) with ESMTP id k98MQibF000610; Sun, 8 Oct 2006 15:26:45 -0700 (PDT) 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); Sun, 8 Oct 2006 18:26:44 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea) Date: Sun, 8 Oct 2006 18:26:44 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [Nea] WG Review: Network Endpoint Assessment (nea) Thread-Index: AcbrKNWUzo//GYi9Rkekvc6zVIfDgA== From: "Susan Thomson \(sethomso\)" To: "Narayanan, Vidya" X-OriginalArrivalTime: 08 Oct 2006 22:26:44.0541 (UTC) FILETIME=[D5D5B6D0:01C6EB28] DKIM-Signature: a=rsa-sha1; q=dns; l=4844; t=1160346405; x=1161210405; c=relaxed/relaxed; s=sjdkim8002; 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:RE=3A=20[Nea]=20WG=20Review=3A=20Network=20Endpoint=20Assessment=20(nea) =20; X=v=3Dcisco.com=3B=20h=3D24OPQ/hDvxMphtVazzHvPsPXVFg=3D; b=br6whDAxHx6xuGRfXsg0gUplKeFCVIL3oKO6YG0jvZ051eRRxFRhrH+1hWFAzwtqTeTAmqO1 Cowv7ZYgkmeJXws6tIQkOYutfOgIF01BPTVwAWr/SrxgJL6NRjppuIBq; Authentication-Results: sj-dkim-8.cisco.com; header.From=sethomso@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: nea@ietf.org, iesg@ietf.org, ietf@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 Vidya Inline ... >=20 > How about adding this text - "It should be noted that the networks at > large are exposed to attacks from lying endpoints and=20 > external entities > attaching to the networks as well as any problems arising from unknown > vulnerabilities on NEA compliant endpoints. Hence, NEA must not be > considered a protection mechanism for networks. Further, mechanisms > needed to protect the network from all kinds of vulnerabilities are > expected to be a superset of any protection that may be achieved by > employing NEA"?=20 >=20 It seems to me that this better belongs in a security considerations section of the NEA spec, especially given where we are in the review cycle and the amount of time spent on this specific section already. > >=20 > > Bearing the original motivation in mind, would the following=20 > > work better? > > "An organization may make a range of policy decisions based=20 > > on the posture of an endpoint. NEA is not intended to be=20 > > prescriptive in this regard. For example, potential=20 > > deployment scenarios may include,but are not limited to,=20 > > providing normal access regardless of compliance with=20 > > recommendations for remediation ("advisory mode"), as well as=20 > > providing restricted access sufficient for remediation=20 > > purposes and any essential services until an endpoint is in=20 > > compliance ("mandatory mode").=20 > >=20 >=20 > I'm not sure that the charter actually needs to get into the modes at > all - I'm guessing what happens after NEA (i.e., what is done with the > results from NEA) has zero impact on any work being done in=20 > NEA itself. > So, why not simply state something like "Once NEA is conducted on an > endpoint, the results may be used by an organization in=20 > accordance with > any policies of the organization itself."?=20 >=20 Again, the text was added at the request of the security AD. I have no problem with Sam Hartman's modification to the text I proposed, your text above, or none at all. > That is not necessarily putting any requirements in the choice of the > mandatory to implement protocol itself, as I see it. I believe that > stating something like "The mandatory to implement PT protocol must be > generic enough to allow the execution of the NEA procedure without > forcing the need to re-execute network access procedures".=20 >=20 I think protocol requirements belong in the requirements I-D. > Not only do I not see anything in the charter or milestones that > indicates that the WG is going to spend time exploring this,=20 > I strongly > believe this WG should not be spending any time looking at this. The > trust models for the cases where the devices are not owned by the > organization performing NEA are hugely different and can take=20 > up its own > WG to actually find something that applies there, if at all. For one, > this could be considered a violation of privacy by the user of the > device. Secondly, the end user's perspective of attacks may=20 > be entirely > different from the organization's perspective in this case. Third, I > simply can't see what the organization's interests would be in > protecting a device that doesn't even belong to it. Last but not the > least, this requires the endpoint to be running an NEA client (that is > interoperable with the NEA server of the organization) -=20 > which in itself > is often an unrealistic requirement.=20 >=20 > Organizations that provide services in their networks to end users are > worried about protecting their resources (i.e., networks, servers, > etc.). As we have agreed, NEA does not protect such resources anyway. > Plus, there is absolutely no reason such organizations should believe > that devices they don't own are in fact, truthful endpoints.=20 >=20 > So, thinking that this WG must be looking into resolving this seems > flawed at several levels. In the interest of having a focused WG that > can get something useful accomplished, this does not make sense.=20 >=20 No argument with your gist here. The point I was trying to make is that I think applicability may not be quite as "black and white" as your original text suggests, and it would be better if the applicability and security considerations associated with NEA be addressed in the WG and specified in the appropriate NEA documents. The charter could express itself better in this regard. If the last sentence was replaced with something like: "NEA can be limited in its applicability when the endpoint and the organization providing network access are owned by different parties. NEA applicability and security considerations will be described in the appropriate NEA documents." Would this work?=20 Thanks Susan _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Oct 09 05:52:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWro0-00011G-9i; Mon, 09 Oct 2006 05:52:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWrny-00010n-9A for nea@ietf.org; Mon, 09 Oct 2006 05:52:14 -0400 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 1GWrkj-000077-Ql for nea@ietf.org; Mon, 09 Oct 2006 05:48:55 -0400 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 1GWrka-0001Ax-IJ for nea@ietf.org; Mon, 09 Oct 2006 19:48:44 +1000 Received: (qmail 32682 invoked by uid 453); 9 Oct 2006 09:07:48 -0000 Received: from speedy.dhs (HELO speedy) (192.168.0.8) by dhs (qpsmtpd/0.31-dev) with ESMTP; Mon, 09 Oct 2006 19:07:48 +1000 From: "Darryl \(Dassa\) Lynch" To: Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea) Date: Mon, 9 Oct 2006 19:48:40 +1000 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 Thread-Index: AcbrgmIOlvdB5dq6SReloepSZ/LCxwAAkpaw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <452A115A.6020308@zurich.ibm.com> X-Spam-Score: 0.0 (/) 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: Brian E Carpenter wrote: >>>>> This is what I meant when I said that the charter is unclear and >>>>> it must explicitly state that NEA is not meant as a protection >>>>> mechanism of any sort for the network. >>> >>> >>> I don't believe the Charter needs to delve into this at all. If >>> some people see it as part of their protection mechanisms, so be it. >>> >>> Darryl (Dassa) Lynch >> >> The IETF has an obligation to "truth in advertising" so IMHO >> we should not claim protection that doesn't exist, even implicitly. [...] Content analysis details: (0.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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: Brian E Carpenter wrote: >>>>> This is what I meant when I said that the charter is unclear and >>>>> it must explicitly state that NEA is not meant as a protection >>>>> mechanism of any sort for the network. >>> >>> >>> I don't believe the Charter needs to delve into this at all. If >>> some people see it as part of their protection mechanisms, so be it. >>> >>> Darryl (Dassa) Lynch >> >> The IETF has an obligation to "truth in advertising" so IMHO >> we should not claim protection that doesn't exist, even implicitly. I can't see anywhere in the charter where it is implied NEA is a protection mechanism. That doesn't mean the use of NEA can not be a part of an overall strategy to improve security on a network or on endpoints. NEA is not itself a protection mechanism but it may be used to assist in creating some protection mechanisms. Much like TCP/IP can be used to build a network but is itself not a network. For instance, if I have a network with the policy that only a small number of anti-virus products are trusted and the products must be version X with data files of at least version Y, an endpoint with a product C will not be allowed on the network. If NEA can be used to automatically check this policy is complied with at the endpoints before they are given full access then I consider NEA has been used as part of the security strategy. My understanding is this is already achieved with some vendor specific systems. Another side of the issue is NEA may be used to ensure a financial package is installed and has all the applicable patches installed before it is allowed to connect into the main database, which would be of assistance to maintain data integrity. To me NEA is just a means to have compatible standard communications. The full use of the communications data is really beyond the scope of the WG. Darryl (Dassa) Lynch _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Oct 09 10:10:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWvpc-0006rT-BG; Mon, 09 Oct 2006 10:10:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWeDT-0006Mz-GN; Sun, 08 Oct 2006 15:21:39 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWeDS-0005xO-19; Sun, 08 Oct 2006 15:21:39 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D3AC925817F; Sun, 8 Oct 2006 21:19:06 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31765-05; Sun, 8 Oct 2006 21:19:01 +0200 (CEST) Received: from [192.168.1.57] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 8437F2580E1; Sun, 8 Oct 2006 21:19:01 +0200 (CEST) Message-ID: <45294FBA.8040800@alvestrand.no> Date: Sun, 08 Oct 2006 21:21:30 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Lakshminath Dondeti Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) References: <4527685D.1090904@alvestrand.no> <7.0.1.0.2.20061007100953.059f1120@qualcomm.com> In-Reply-To: <7.0.1.0.2.20061007100953.059f1120@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 X-Mailman-Approved-At: Mon, 09 Oct 2006 10:10:11 -0400 Cc: nea@ietf.org, iesg@ietf.org, ietf@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 Lakshminath Dondeti wrote: > At 01:42 AM 10/7/2006, Harald Alvestrand wrote: >>> >> Many universities require their students to buy their own laptops, >> but prohibit certain types of activity from those laptops (like >> spamming, DDOS-attacks and the like). They would love to have the >> ability to run some kind of NEA procedure to ensure that laptops are >> reasonably virus-free and free from known vulnerabilities, and are >> important enough in their students' lives that they can probably >> enforce it without a complaint about "violation of privacy". >> >> Just pointing out that there's one use case with user-managed >> endpoints where NEA is not obviously a bad idea. > > My email ventures into a bit of non-IETF territory, but we are > discussing use cases, and so I guess it's on topic. Universities > should be the last places to try antics like NEA. Whereas an > operational network would be a priority to them, it is also important > that they allow students to experiment with new applications. If we > are believing that general purpose computing will be taken away from > college students, we are indeed talking about a different world. > > In any event, the bottomline is NEA as a solution to "network > protection" is a leaky bucket at best. > > NEA at best *may* raise the bar in attacking a "closed" network where > endpoints are owned and tightly controlled by the organization that > owns the network. Posture checking is certainly a leaky bucket. It doesn't protect all kinds of endpoint, it doesn't protect the endpoints against all kinds of threats, and it doesn't protect much of anything against a smart, resourceful attacker who is deeply familiar with the NEA system in use and is interested in investing considerable resources in attacking or circumventing it. But (to recycle a very old simile) the fact that I can open the locks of most doors with a crowbar doesn't mean that locks are not useful. Organizations that have deployed products that do something like what NEA is talking about have reported that their TCO is reduced. Harald _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Oct 09 10:10:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWvpc-0006rl-FV; Mon, 09 Oct 2006 10:10:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWotW-0007MO-Jr; Mon, 09 Oct 2006 02:45:46 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWotV-0007cE-8N; Mon, 09 Oct 2006 02:45:46 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k996jhUi002797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 8 Oct 2006 23:45:44 -0700 Received: from [10.100.102.97] (vpn-10-50-0-107.qualcomm.com [10.50.0.107]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k996jcZX023658; Sun, 8 Oct 2006 23:45:41 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <200610082120.k98LKfxn025225@relay01.ispone.net.au> References: <200610082120.k98LKfxn025225@relay01.ispone.net.au> Date: Sun, 8 Oct 2006 23:45:37 -0700 To: From: Ted Hardie Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-Mailman-Approved-At: Mon, 09 Oct 2006 10:10:11 -0400 Cc: nea@ietf.org Subject: [Nea] WG Review: Network Endpoint Assessment (nea) X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org I have a very basic fear that this working group is getting chartered with a bunch of aims added by people who will not take on the task of doing the work. After private discussion with folks involved, my sense is that the very core of this work is a perceived need to be able to pass opaque strings between a host and the network prior to the host attaching. Those opaque strings are, essentially, the vendor-specific strings currently associated with posture assessment. The standard protocol carrying these strings would connect on the network side to a system that has plug-ins which understand the vendor-specific strings. With a charter that clarified that this was intended to assist the end systems with vulnerabilities prior to attachment because the network they are attaching to might be filled with danger, I think this work would get done reasonably quickly. (As a control mechanism to protect the network, I agree with the point made clearly by others that this is not appropriate). I am less sure of the task of standardizing attributes. I am not sure that the number of attributes which can be standardized will ever be high enough to be truly useful, and I am pretty sure that all of these will be already covered by vendor-specific attributes. Since there must be an assessor in place on the client for those few standardized attributes to be assessed and that assessor will likely already have these covered by vendor-specific attributes, in other words, we seem to be standardizing redundancy. On the network attachment side, it is possible, of course, that an offer of remediation could be made based on just the standard attributes, but it seems far more likely that it would be a two step process (assess standard attributes, then pass vendor-specific attributes to vendor plug-in). Again, if the vendor's attributes cover the standard attributes, then this is largely redundant and may add measurable latency; it seems far more likely that step one would simply be skipped if there were a vendor-specific string and an available plug-in. Since there has to be an assessor, the first seems very likely to me. If you don't have a vendor's plug-in, then I suppose there is some chance that you will trust and act based on the standard attributes, but the chance of getting the right remediation seems pretty slight in those circumstances. Especially when many vulnerabilities are a combination of conditions, (Browser version Foo on OS patch level Bar) that you could remediate by upgrading either one, checking for and acting on the attributes which could be standardized seems of very, very limited utility. Ted Hardie _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Oct 09 10:10:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWvpc-0006sX-KA; Mon, 09 Oct 2006 10:10:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWrC3-0003qv-N3; Mon, 09 Oct 2006 05:13:03 -0400 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWr6r-0005uZ-3a; Mon, 09 Oct 2006 05:07:43 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.13.8/8.13.8) with ESMTP id k9997dHD148310; Mon, 9 Oct 2006 09:07:39 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k9999u4G851974; Mon, 9 Oct 2006 11:09:57 +0200 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k9997dIt021648; Mon, 9 Oct 2006 11:07:39 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k9997coj021625; Mon, 9 Oct 2006 11:07:38 +0200 Received: from zurich.ibm.com ([9.4.210.83]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA179260; Mon, 9 Oct 2006 11:07:36 +0200 Message-ID: <452A115A.6020308@zurich.ibm.com> Date: Mon, 09 Oct 2006 11:07:38 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: dassa@dhs.org Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) References: <200610082120.k98LKfxn025225@relay01.ispone.net.au> In-Reply-To: <200610082120.k98LKfxn025225@relay01.ispone.net.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-Mailman-Approved-At: Mon, 09 Oct 2006 10:10:11 -0400 Cc: nea@ietf.org, ietf@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 is what I meant when I said that the charter is unclear >>>and it must explicitly state that NEA is not meant as a >>>protection mechanism of any sort for the network. > > > I don't believe the Charter needs to delve into this at all. If some people > see it as part of their protection mechanisms, so be it. > > Darryl (Dassa) Lynch The IETF has an obligation to "truth in advertising" so IMHO we should not claim protection that doesn't exist, even implicitly. Brian _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Oct 09 10:10:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWvpc-0006tA-P8; Mon, 09 Oct 2006 10:10:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWuj5-0007TW-Ua; Mon, 09 Oct 2006 08:59:23 -0400 Received: from smtp.mail.umich.edu ([141.211.93.161] helo=tombraider.mr.itd.umich.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWuj3-000761-3V; Mon, 09 Oct 2006 08:59:23 -0400 Received: FROM punchout.gpcc.itd.umich.edu (punchout.gpcc.itd.umich.edu [141.211.2.208]) BY tombraider.mr.itd.umich.edu ID 452A47A1.7A095.25891 ; 9 Oct 2006 08:59:14 -0400 Date: Mon, 9 Oct 2006 08:59:13 -0400 (EDT) From: Susan Harris X-X-Sender: srh@punchout.gpcc.itd.umich.edu To: "Narayanan, Vidya" Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 93ea548d5fde6eb89af31f1faab96344 X-Mailman-Approved-At: Mon, 09 Oct 2006 10:10:11 -0400 Cc: nea@ietf.org, iesg@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 believe this mail should have gone to Sue Hares. On Fri, 6 Oct 2006, Narayanan, Vidya wrote: > Hi Susan, > Please see inline. > >> -----Original Message----- >> From: Susan Thomson (sethomso) [mailto:sethomso@cisco.com] >> Sent: Thursday, October 05, 2006 12:22 PM >> To: Narayanan, Vidya >> Cc: nea@ietf.org; iesg@ietf.org; ietf@ietf.org >> Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea) >> >> Hi Vidya >> >> Thanks for your comments. >> >> Inline ... >> >>> -----Original Message----- >>> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] >>> Sent: Wednesday, October 04, 2006 12:48 PM >>> To: iesg@ietf.org >>> Cc: nea@ietf.org >>> Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea) >>> >>> >>> All, >>> Comments on the charter inline below. >>> >>>> -----Original Message----- >>>> From: IESG Secretary [mailto:iesg-secretary@ietf.org] >>>> Sent: Monday, October 02, 2006 7:30 AM >>>> To: ietf-announce@ietf.org >>>> Cc: nea@ietf.org >>>> Subject: [Nea] WG Review: Network Endpoint Assessment (nea) >>>> >>>> A new IETF working group has been proposed in the Security Area. >>>> The IESG has not made any determination as yet. The >> following draft >>>> charter was submitted, and is provided for informational purposes >>>> only. >>>> Please send your comments to the IESG mailing list >>>> (iesg@ietf.org) by October 9. >>>> >>>> +++ >>>> >>>> Network Endpoint Assessment (nea) >>>> ====================================== >>>> >>>> Current Status: Proposed Working Group >>>> >>>> Chair(s): >>>> TBD >>>> >>>> Security Area Director(s): >>>> Russ Housley >>>> Sam Hartman >>>> >>>> Security Area Advisor: >>>> Russ Housley >>>> >>>> Mailing List: nea@ietf.org >>>> >>>> Description of Working Group: >>>> >>>> Network Endpoint Assessment (NEA) architectures have been >>>> implemented in the industry 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. An endpoint that does not comply with >> posture policy >>>> may be vulnerable to a number of known threats that may >> exist on the >>>> network. The intent of NEA is to facilitate corrective actions to >>>> address these known vulnerabilities before a host is exposed to >>>> potential attack. >>> >>> >>> Is it fair to then say that NEA is attempting to protect >> the endhost >>> and not necessarily the network? >> >> Yes, this is the focus. >> >>> That is not immediately clear in the >>> charter. Obviously, the network must deal with all kinds of >> known and >>> unknown threats and a process like NEA is inadequate to >> protect it at >>> any acceptable level. That is why we employ a number of other >>> mechanisms like firewalls, access control, packet filters, IDS/IPS, >>> etc. in any combination to appropriately protect the networks. >>> >>> So, stating that NEA is not attempting to protect the >> network at large >>> would bring a lot of clarity to the charter. >>> >> >> Since we have been around the block a few times on this >> section, could you suggest precise text that you would like >> to see to make this clearer? >> > > How about adding this text - "It should be noted that the networks at > large are exposed to attacks from lying endpoints and external entities > attaching to the networks as well as any problems arising from unknown > vulnerabilities on NEA compliant endpoints. Hence, NEA must not be > considered a protection mechanism for networks. Further, mechanisms > needed to protect the network from all kinds of vulnerabilities are > expected to be a superset of any protection that may be achieved by > employing NEA"? > > >>> >>>> Two deployment scenarios will be supported: advisory mode and >>>> mandatory mode. >>>> In advisory mode, an endpoint may be advised of the result of >>>> posture assessment and any recommended remediation >> actions, but is >>>> provided normal network access regardless of the result. In >>>> mandatory mode, a non-compliant endpoint is given >> restricted access >>>> to the network sufficient for remediation purposes and >> any essential >>>> services or denied access completely. >>>> >>> >>> It is unclear how the advisory vs mandatory model relates >> to the NEA >>> procedures itself. NEA is attempting to provide a vehicle >> to perform >>> some compliance tests on acceptable "postures". What the network >>> decides to do with that information seems entirely dependent on the >>> policy of the network and the extent of non-compliance, >> etc. What does >>> it mean to say that NEA *allows* an advisory and/or a >> mandatory model? >>> >>> >> Yes, it is a matter of policy. We have had other input as >> well that indicates this text is causing confusion. We added >> this text in consultation with our AD to re-inforce the >> notion that NEA did not necessarily imply enforcement, and >> that things like emergency services could be made available >> regardless of the outcome of posture assessment. >> >> The intention is not to be prescriptive about an >> organization's policy in any way. >> >> Bearing the original motivation in mind, would the following >> work better? >> "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. For example, potential >> deployment scenarios may include,but are not limited to, >> providing normal access regardless of compliance with >> 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"). >> > > I'm not sure that the charter actually needs to get into the modes at > all - I'm guessing what happens after NEA (i.e., what is done with the > results from NEA) has zero impact on any work being done in NEA itself. > So, why not simply state something like "Once NEA is conducted on an > endpoint, the results may be used by an organization in accordance with > any policies of the organization itself."? > >>>> Posture refers to the hardware or software configuration of an >>>> endpoint as it pertains to an organization's security 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. >>>> On network access and while connected, an endpoint supporting NEA >>>> protocols can be queried for such posture information in either >>>> advisory or mandatory modes. >>>> >>> >>> Again, what does it mean to be queried in a particular mode? >>> >> >> Based on consensus re the above, reference to the "modes" may >> be able to be dropped. >> >>>> Since NEA involves many different components from >> different vendors, >>>> interoperation >>> >>> s/interoperation/interoperability >>> >> >> OK. >> >>>> is highly desirable. The priority of the NEA working group is to >>>> standardize protocols at the higher layers in the architectures: >>>> the Posture Attribute protocol (PA) and the Posture >> Broker protocol >>>> (PB). >>>> PA and PB will be designed to support a variety of lower layer >>>> protocols. >>>> When used with standards for lower layers, these new >> protocols will >>>> allow interoperability between an NEA Client from one >> vendor and an >>>> NEA Server from another. >>>> >>> >>> This seems like an optimistic goal. Given that only a subset of >>> attributes are envisioned to be standardized and given that >> the kind >>> of attributes are likely to be ever increasing, considering that >>> posture refers to hardware/software configuration of an endpoint, I >>> fail to see how we would practically get NEA clients and >> NEA servers >>> from different vendors to perform any meaningful NEA procedures. In >>> theory, I can see how this can be slated to be a goal - >> but, I have to >>> believe that reality would be different. >>> >> >> This was discussed at last BOF, and resolution was to require >> that vendor-specific attributes be documented in a RFC. >> >> Its also possible that components of a client and components >> of a server are provided by same or different vendors, i.e. >> interoperability is not necessarily an all or nothing proposition. >> > > I realize that. I guess some people are convinced that the subset > standardized will be sufficient for some meaningful interoperability. I > will have to wait to see the interoperable deployments to be convinced > of that :) > >>> >>>> Since there are already several non-standard protocols at these >>>> higher layers, the NEA working group will consider these existing >>>> protocols as candidates for standardization. A >> requirements document >>>> will be written and used as a basis for evaluating the candidate >>>> protocols. >>>> The working group may decide to standardize one of the candidate >>>> protocols, use one of them as a basis for a new or >> revised protocol, >>>> or decide that a new protocol is needed. >>>> >>>> The NEA Requirements document will include a problem statement, >>>> definition of terms, requirements for 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 one mandatory to implement PT protocol to ensure >>>> interoperability. >>>> >>> >>> I assume that the mandatory to implement PT protocol must >> satisfy the >>> criteria that will allow the NEA process to be triggered at >> any time >>> (i.e., during or after network access). Clarifying this >> would be good. >>> >> >> There is text in a few paragraphs above that says "on network >> access and while connected, an endpoint supporting NEA >> protocols can be queried for such posture information". Is >> this not sufficient? >> > > That is not necessarily putting any requirements in the choice of the > mandatory to implement protocol itself, as I see it. I believe that > stating something like "The mandatory to implement PT protocol must be > generic enough to allow the execution of the NEA procedure without > forcing the need to re-execute network access procedures". > >>> >>>> PA, the Posture Attribute protocol, consists of posture >> attributes >>>> that are carried between a particular Posture Collector in a NEA >>>> client and a particular Posture Validator in a NEA Server. The PA >>>> protocol is carried inside the PB protocol. Certain posture >>>> attributes will be standardized to ensure interoperability but >>>> vendor-specific attributes will also be supported. >> Vendor-specific >>>> attributes must be documented in an RFC. >>>> >>> >>> This goes back to my comment on interoperability. Unless it is >>> expected that there will be ongoing efforts to continually >> standardize >>> attributes of significance to the community as the >> hardware/software >>> configurations of devices evolve, I am afraid that we won't have >>> interoperability of any significance. >>> >> >> Ongoing standardization of attributes can be done as necessary. >> > > This, to me, indicates that this is a WG that may never actually close > :) Again, I'll have to wait for deployments to convince myself! > >>> >>>> 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 (or stack of protocols) is >>>> suitable for carrying the PB protocol at the time of network >>>> connection, or shortly after. >>>> >>>> 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. >>>> >>> >>> >>> I'm not sure what the last sentence means here - everything in this >>> paragraph alludes to the fact that lying endpoints are out >> of scope. >>> If the last sentence is alluding to the TCG efforts, why is it >>> cryptic? As currently stated, it doesn't seem to add any >> value. If we >>> say that in order for NEA to have a meaningful use case, it >> must work >>> together with some of the TCG stuff, then, perhaps that is >> effort that >>> the WG must ensure gets done. >>> >> >> The last sentence was added as a result of the consensus >> reached at the last BOF. The intent is to make sure that NEA >> is compatible with emerging technologies to address "lying >> endpoints" so that they can be used together if a user >> chooses to do so. >> >> TCG is one example that could place requirements on NEA to >> ensure compatibility, but need not be the only one. My >> understanding (although I am no expert) is that requirements >> include providing a multi-round sequenced message exchange >> with authentication of the server, confidentiality, and >> integrity protection. Such requirements are not expected to >> be onerous. >> > > I guess the text leaves it so open-ended that it fails to add any value. > Unless we know what technologies NEA must be able to work with, how can > the protocols be designed to work with those technologies? I am > completely missing the point of this text. > >>> >>>> Note that NEA is not chartered to standardize protocols for >>>> remediation. >>>> NEA is intended to be used with new or existing tools that can be >>>> used in the absence of NEA. There is an open issue with >> respect to >>>> NEA applicability in deployment scenarios where the endpoint is >>>> owned by a party that is different from the organization >> providing >>>> network access. >>>> >>> >>> >>> Why is this an open issue? When the endpoint and the organization >>> providing network access are owned by different parties, it simply >>> does not seem to be viable to do any kind of configuration >> assessment >>> on the endpoint. I think this should be stated rather clearly along >>> these >>> lines: >>> >>> "NEA is limited in applicability to the case where the endpoint is >>> owned by the organization providing network access and >> performing the >>> assessment. In the cases where the two belong to a >> different party, it >>> is practically infeasible for an organization providing >> network access >>> to perform any kind of posture assessment or related >> compliance tests >>> on the endpoint." >>> >> >> The reason we left it open is to allow the working group to spend more >> time exploring the range of use cases in this area to better determine >> requirements and applicability. For example, it may be useful to >> classify endpoints as network-managed versus user-managed versus >> 3rd-party managed. A user-managed endpoint may want the >> choice to opt in >> or opt out, say. >> > > Not only do I not see anything in the charter or milestones that > indicates that the WG is going to spend time exploring this, I strongly > believe this WG should not be spending any time looking at this. The > trust models for the cases where the devices are not owned by the > organization performing NEA are hugely different and can take up its own > WG to actually find something that applies there, if at all. For one, > this could be considered a violation of privacy by the user of the > device. Secondly, the end user's perspective of attacks may be entirely > different from the organization's perspective in this case. Third, I > simply can't see what the organization's interests would be in > protecting a device that doesn't even belong to it. Last but not the > least, this requires the endpoint to be running an NEA client (that is > interoperable with the NEA server of the organization) - which in itself > is often an unrealistic requirement. > > Organizations that provide services in their networks to end users are > worried about protecting their resources (i.e., networks, servers, > etc.). As we have agreed, NEA does not protect such resources anyway. > Plus, there is absolutely no reason such organizations should believe > that devices they don't own are in fact, truthful endpoints. > > So, thinking that this WG must be looking into resolving this seems > flawed at several levels. In the interest of having a focused WG that > can get something useful accomplished, this does not make sense. > > Thanks, > Vidya > >> Thanks >> Susan >> >>> Thanks, >>> Vidya >>> >>> >>>> Further work in the NEA WG will be considered via the >>>> standard rechartering process after the completion of these >>>> milestones. >>>> >>>> Milestones: >>>> >>>> June 2006: >>>> * Submit first version of NEA Requirements I-D >>>> >>>> July 2006: >>>> * Agree on charter and milestones at IETF 66 >>>> >>>> October 2006: >>>> * Submit first draft of NEA Requirements I-D >>>> >>>> November 2006: >>>> * At IETF 67, discuss issues with NEA Requirements I-D >>>> * Agree on solutions to issues with NEA Requirements I-D >>>> >>>> December 2006: >>>> * Deadline for submission of candidate specs for PA and PB >>>> * Submit first version of NEA Evaluation I-D >>>> >>>> January 2007: >>>> * WG Last Call on NEA Evaluation I-D >>>> >>>> February 2007: >>>> * Submit NEA Requirements I-D and Evaluation I-D to IESG >> as Info RFC >>>> * Submit first draft of PA and PB specs for review >>>> >>>> March 2007: >>>> * Discuss unresolved issues with PA and PB specs at IETF 68 >>>> * Agree on solutions to unresolved issues with PA and PB specs >>>> >>>> April 2007: >>>> * Submit revised draft of PA and PB specs >>>> >>>> June 2007 >>>> * WG Last Call on PA and PB specs >>>> >>>> July 2007 >>>> * Resolve outstanding WGLC comments on PA and PB specs at IETF 69 >>>> >>>> August 2007: >>>> * Submit PA and PB specs to IESG for publication as Proposed >>>> >>>> September 2007: >>>> * Decide how to address MTI PT, recharter if needed >>>> >>>> _______________________________________________ >>>> 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 >>> >> > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > > > _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Oct 09 10:10:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWvpc-0006th-U0; Mon, 09 Oct 2006 10:10:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWv8a-00061r-O9; Mon, 09 Oct 2006 09:25:44 -0400 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWv0n-0004tB-Hy; Mon, 09 Oct 2006 09:17:44 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=js3OWpOLGkdhFAycA51wU6V7gNGwjQZunUAon8s80ACh9rGt1PTe3VBcqaoFBmxG; 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.138] (helo=gw) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GWv0h-0008P4-L0; Mon, 09 Oct 2006 09:17:36 -0400 Message-ID: <00b201c6eba5$4f3bad00$010aa8c0@home.glassey.com> From: "todd glassey" To: "Brian E Carpenter" , References: <200610082120.k98LKfxn025225@relay01.ispone.net.au> <452A115A.6020308@zurich.ibm.com> Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Date: Mon, 9 Oct 2006 06:17:33 -0700 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: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79c92556753f624366a7d35b81b5f120df350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.246.45.138 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-Mailman-Approved-At: Mon, 09 Oct 2006 10:10:11 -0400 Cc: nea@ietf.org, ietf@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 IETF has an obligation to WIPO and to the DMCA and well - so far its failed those pretty well I think. Todd Glassey ----- Original Message ----- From: "Brian E Carpenter" To: Cc: ; Sent: Monday, October 09, 2006 2:07 AM Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) > > >>>This is what I meant when I said that the charter is unclear > >>>and it must explicitly state that NEA is not meant as a > >>>protection mechanism of any sort for the network. > > > > > > I don't believe the Charter needs to delve into this at all. If some people > > see it as part of their protection mechanisms, so be it. > > > > Darryl (Dassa) Lynch > > The IETF has an obligation to "truth in advertising" so IMHO we should not > claim protection that doesn't exist, even implicitly. > > Brian > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Oct 09 10:10:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWvpd-0006uD-34; Mon, 09 Oct 2006 10:10:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWveA-0001Fe-Dq; Mon, 09 Oct 2006 09:58:22 -0400 Received: from bay0-omc3-s12.bay0.hotmail.com ([65.54.246.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWve8-0005fc-0c; Mon, 09 Oct 2006 09:58:22 -0400 Received: from hotmail.com ([65.54.250.89]) by bay0-omc3-s12.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Oct 2006 06:58:19 -0700 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 9 Oct 2006 06:58:18 -0700 Message-ID: Received: from 15.238.95.37 by BAY115-DAV17.phx.gbl with DAV; Mon, 09 Oct 2006 13:58:18 +0000 X-Originating-IP: [15.238.95.37] X-Originating-Email: [fritz_saad@hotmail.com] X-Sender: fritz_saad@hotmail.com From: "Fritz F. Saad" To: "todd glassey" , "Brian E Carpenter" , References: <200610082120.k98LKfxn025225@relay01.ispone.net.au><452A115A.6020308@zurich.ibm.com> <00b201c6eba5$4f3bad00$010aa8c0@home.glassey.com> Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Date: Mon, 9 Oct 2006 07:58:20 -0600 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.2900.2869 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-OriginalArrivalTime: 09 Oct 2006 13:58:18.0930 (UTC) FILETIME=[F97CA120:01C6EBAA] X-Spam-Score: 3.0 (+++) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a X-Mailman-Approved-At: Mon, 09 Oct 2006 10:10:11 -0400 Cc: nea@ietf.org, ietf@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 Tood, Agreed, we should work to fix that. Fritz. ----- Original Message ----- From: "todd glassey" To: "Brian E Carpenter" ; Cc: ; Sent: Monday, October 09, 2006 7:17 AM Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) The IETF has an obligation to WIPO and to the DMCA and well - so far its failed those pretty well I think. Todd Glassey ----- Original Message ----- From: "Brian E Carpenter" To: Cc: ; Sent: Monday, October 09, 2006 2:07 AM Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) > > >>>This is what I meant when I said that the charter is unclear > >>>and it must explicitly state that NEA is not meant as a > >>>protection mechanism of any sort for the network. > > > > > > I don't believe the Charter needs to delve into this at all. If some people > > see it as part of their protection mechanisms, so be it. > > > > Darryl (Dassa) Lynch > > The IETF has an obligation to "truth in advertising" so IMHO we should not > claim protection that doesn't exist, even implicitly. > > Brian > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Oct 09 10:38:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWwGj-0002Aq-IG; Mon, 09 Oct 2006 10:38:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWwAL-0006fv-Nc; Mon, 09 Oct 2006 10:31:37 -0400 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWwAK-0002Rd-9A; Mon, 09 Oct 2006 10:31:37 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.8/8.13.8) with ESMTP id k99EVZEe018648; Mon, 9 Oct 2006 14:31:35 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k99EXq6E2678886; Mon, 9 Oct 2006 16:33:52 +0200 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k99EVY1D019808; Mon, 9 Oct 2006 16:31:34 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k99EVYkC019755; Mon, 9 Oct 2006 16:31:34 +0200 Received: from zurich.ibm.com ([9.4.210.83]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA134426; Mon, 9 Oct 2006 16:31:33 +0200 Message-ID: <452A5D46.1070701@zurich.ibm.com> Date: Mon, 09 Oct 2006 16:31:34 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: ietf@ietf.org Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) References: <200610082120.k98LKfxn025225@relay01.ispone.net.au><452A115A.6020308@zurich.ibm.com> <00b201c6eba5$4f3bad00$010aa8c0@home.glassey.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 X-Mailman-Approved-At: Mon, 09 Oct 2006 10:38:12 -0400 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 should work to fix that. ... > The IETF has an obligation to WIPO and to the DMCA ... I can only assume this was intended as some form of joke. Brian _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Oct 09 11:35:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWx9q-0002Sg-QQ; Mon, 09 Oct 2006 11:35:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWwfQ-0005cz-Fi; Mon, 09 Oct 2006 11:03:44 -0400 Received: from bes.cs.utk.edu ([160.36.56.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWwfP-00005w-95; Mon, 09 Oct 2006 11:03:44 -0400 Received: from localhost (localhost [127.0.0.1]) by bes.cs.utk.edu (Postfix) with ESMTP id 2ED56FCFA; Mon, 9 Oct 2006 11:03:23 -0400 (EDT) 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 gFf+c1VCtGZ0; Mon, 9 Oct 2006 11:03:16 -0400 (EDT) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by bes.cs.utk.edu (Postfix) with ESMTP id 3070CFCEE; Mon, 9 Oct 2006 11:03:16 -0400 (EDT) Message-ID: <452A64C5.4040305@cs.utk.edu> Date: Mon, 09 Oct 2006 11:03:33 -0400 From: Keith Moore User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) References: <200610082120.k98LKfxn025225@relay01.ispone.net.au><452A115A.6020308@zurich.ibm.com> <00b201c6eba5$4f3bad00$010aa8c0@home.glassey.com> <452A5D46.1070701@zurich.ibm.com> In-Reply-To: <452A5D46.1070701@zurich.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-Mailman-Approved-At: Mon, 09 Oct 2006 11:35:09 -0400 Cc: nea@ietf.org, ietf@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 IETF has an obligation to WIPO and to the DMCA > ... > > I can only assume this was intended as some form of joke. regardless of intent, it should be treated as such. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Oct 09 12:15:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWxn8-0008MO-UT; Mon, 09 Oct 2006 12:15:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWxk1-00061R-RB; Mon, 09 Oct 2006 12:12:33 -0400 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWxia-0000Pn-BL; Mon, 09 Oct 2006 12:11:06 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=XDoCPMpRK0TT78V7BFel+HUUFqkvgPnvbr0g3gt0R6e0+yiMgt03Ed0R2xlnAQ/I; 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.229] (helo=gw) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GWxiH-00045o-5z; Mon, 09 Oct 2006 12:10:48 -0400 Message-ID: <010401c6ebbd$800d9d40$010aa8c0@home.glassey.com> From: "todd glassey" To: "Fritz F. Saad" , "Brian E Carpenter" , References: <200610082120.k98LKfxn025225@relay01.ispone.net.au><452A115A.6020308@zurich.ibm.com> <00b201c6eba5$4f3bad00$010aa8c0@home.glassey.com> Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Date: Mon, 9 Oct 2006 09:05:50 -0700 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: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec793113b0ff53d1dc4a3d1f8431c2b15d78350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.246.45.229 X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 X-Mailman-Approved-At: Mon, 09 Oct 2006 12:15:46 -0400 Cc: nea@ietf.org, ietf@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 Fritz this is a much bigger issue than ANYONE thinks at this time and its based on the idea that the WIPO standard says that the IETF MUST be doing Industrial Design IP Models, and it only does Copyright which is a violation of the WIPO IP protection framework and the treaties ALL of the Member States have signed. Interesting eh? Todd Glassey ----- Original Message ----- From: "Fritz F. Saad" To: "todd glassey" ; "Brian E Carpenter" ; Cc: ; Sent: Monday, October 09, 2006 6:58 AM Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) > Tood, > > > > Agreed, we should work to fix that. > > > > Fritz. > > > > ----- Original Message ----- > From: "todd glassey" > To: "Brian E Carpenter" ; > Cc: ; > Sent: Monday, October 09, 2006 7:17 AM > Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) > > > The IETF has an obligation to WIPO and to the DMCA and well - so far its > failed those pretty well I think. > > Todd Glassey > > ----- Original Message ----- > From: "Brian E Carpenter" > To: > Cc: ; > Sent: Monday, October 09, 2006 2:07 AM > Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) > > > > > > >>>This is what I meant when I said that the charter is unclear > > >>>and it must explicitly state that NEA is not meant as a > > >>>protection mechanism of any sort for the network. > > > > > > > > > I don't believe the Charter needs to delve into this at all. If some > people > > > see it as part of their protection mechanisms, so be it. > > > > > > Darryl (Dassa) Lynch > > > > The IETF has an obligation to "truth in advertising" so IMHO we should not > > claim protection that doesn't exist, even implicitly. > > > > Brian > > > > _______________________________________________ > > Ietf mailing list > > Ietf@ietf.org > > https://www1.ietf.org/mailman/listinfo/ietf > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Oct 09 12:16:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWxnS-0000Qp-9B; Mon, 09 Oct 2006 12:16:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWxk1-00061a-RG; Mon, 09 Oct 2006 12:12:33 -0400 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWxia-0000Ng-BL; Mon, 09 Oct 2006 12:11:06 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=FIez7esw/LWCTA4lSegd5jGdJudspmqZHfl8llZ3DLUScUHvJW+9+i7Yi3mFNgnr; 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.229] (helo=gw) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GWxiT-00045o-LZ; Mon, 09 Oct 2006 12:10:59 -0400 Message-ID: <010601c6ebbd$877eac90$010aa8c0@home.glassey.com> From: "todd glassey" To: "Brian E Carpenter" , References: <200610082120.k98LKfxn025225@relay01.ispone.net.au><452A115A.6020308@zurich.ibm.com><00b201c6eba5$4f3bad00$010aa8c0@home.glassey.com> <452A5D46.1070701@zurich.ibm.com> Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Date: Mon, 9 Oct 2006 09:08:42 -0700 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: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec7931d524f892185d9bbd0053cfc3434cf2350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.246.45.229 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a X-Mailman-Approved-At: Mon, 09 Oct 2006 12:16:05 -0400 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 No it wasn't Brian - the WIPO IP Framework calls for a set of protections for Industrial Designs which ALL of the work that happens here is controlled by right? Otherwise, do you formally want to make a declaration as the IETF's Chair that the IETF and the ISOC are immune from Global IP Law and can pretty much do anything they want. Todd Glassey ----- Original Message ----- From: "Brian E Carpenter" To: Cc: Sent: Monday, October 09, 2006 7:31 AM Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) > > Agreed, we should work to fix that. > ... > > The IETF has an obligation to WIPO and to the DMCA > ... > > I can only assume this was intended as some form of joke. > > Brian > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Oct 09 12:29:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWy0k-00045t-4W; Mon, 09 Oct 2006 12:29:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWy0i-00045b-2w; Mon, 09 Oct 2006 12:29:48 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWy0g-0004Pl-Lj; Mon, 09 Oct 2006 12:29:48 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k99GTc25012261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Oct 2006 09:29:40 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k99GTK1X023433; Mon, 9 Oct 2006 09:29:37 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Oct 2006 09:29:35 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea) Date: Mon, 9 Oct 2006 09:29:37 -0700 Message-ID: In-Reply-To: <200610082120.k98LKfsi025224@relay01.ispone.net.au> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] WG Review: Network Endpoint Assessment (nea) thread-index: AcbqbkOTiRjr9dBtSFCoMFOj9yQzUQAjAdggAAjmGFAAJ6TMAA== From: "Narayanan, Vidya" To: , X-OriginalArrivalTime: 09 Oct 2006 16:29:35.0516 (UTC) FILETIME=[1B8DBDC0:01C6EBC0] X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: nea@ietf.org, iesg@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 Darrly,=20 > >>=20 > >> It appears that the NEA charter is completely misleading to some=20 > >> people from what is stated in this email. As the NEA=20 > charter alludes=20 > >> to, NEA does nothing to protect against compromised=20 > devices. Also, as=20 > >> has been agreed, NEA is not a protection mechanism for the=20 > network -=20 > >> it is meant to be a protection mechanism for compliant,=20 > truthful and=20 > >> as yet uncompromised end hosts against known vulnerabilities. >=20 > True the NEA doesn't "do" anything to protect against=20 > compromised devices but it does assist in limiting the known=20 > compromises on endpoint devices by being a mechanism for the=20 > checking and reporting on compliance to what ever network=20 > policy is in place including virus and patch levels. =20 I'm not sure what you mean by "known compromises" - did you mean known vulnerabilities? If so, yes - I was not questioning the role of NEA in dealing with known vulnerabilities on truthful endpoints.=20 The discussion was about using NEA as a protection mechanism for the network and that doesn't make sense to me and as I understand from Susan, that is not the intention of the charter either.=20 > As a=20 > network administrator I already deploy mechanisms for doing=20 > just this, but at a higher level than the NEA charter=20 > indicates. To me the difference is between being reactive or=20 > proactive. Compliance testing I already run occurs after an=20 > end node has joined the network, with NEA the possibility is=20 > for compliance checking before being allowed onto the network=20 > so isolation and immediate remediation is possible. >=20 > >> Any network, in its own best interests, must assume that=20 > it has lying=20 > >> and compromised endpoints connecting to it and that there=20 > are unknown=20 > >> vulnerabilities on any NEA-compliant devices connecting to it. Any=20 > >> kind of protection that addresses these general threats that the=20 > >> network may be exposed to at any time will simply obviate the need=20 > >> for NEA from the network perspective. >=20 > Reliance on one protection or reporting mechanism is not=20 > enough. We need a lot of varied tools to cover all the bases=20 > and minimise risk. >=20 This is repitition at this point - but, when a network has mechanisms to protect itself against lying endpoints and unknown vulnerabilites, that should cover protection against truthful ones with known vulnerabilities. Otherwise, the network is obviously not adequately protected against the broader set of threats. So, one would employ NEA in their networks to protect the end hosts attaching to the network, not the network itself.=20 > >> A network operator that thinks the network is getting any=20 > protection=20 > >> by employing NEA is clearly ignoring the obvious real threats that=20 > >> the network is exposed to at any time. >=20 > No, NEA would just be one more tool used to improve overall=20 > security and minimise risk. It would be at a different level=20 > to the tools some of already deploy. >=20 > >> This is what I meant when I said that the charter is=20 > unclear and it=20 > >> must explicitly state that NEA is not meant as a=20 > protection mechanism=20 > >> of any sort for the network. >=20 > I don't believe the Charter needs to delve into this at all. =20 > If some people see it as part of their protection mechanisms,=20 > so be it. >=20 That is a terrible approach to take, given how misleading the charter obviously has been to many. The charter must be clear about what the WG is doing and what is out of scope.=20 Vidya _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Oct 09 13:42:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWz8g-0000Rq-Eo; Mon, 09 Oct 2006 13:42:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWz8e-0000Rc-9q; Mon, 09 Oct 2006 13:42:04 -0400 Received: from e33.co.us.ibm.com ([32.97.110.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWz8c-0000bV-Kr; Mon, 09 Oct 2006 13:42:04 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.13.8/8.12.11) with ESMTP id k99Hfvll007457; Mon, 9 Oct 2006 13:41:57 -0400 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 k99HfuEk351956; Mon, 9 Oct 2006 11:41:57 -0600 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 k99HfuxG015190; Mon, 9 Oct 2006 11:41:56 -0600 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 k99HfulG015178; Mon, 9 Oct 2006 11:41:56 -0600 In-Reply-To: Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) To: Ted Hardie X-Mailer: Lotus Notes Release 7.0 HF242 April 21, 2006 Message-ID: From: Frank Yeh Jr Date: Mon, 9 Oct 2006 10:41:51 -0700 X-MIMETrack: Serialize by Router on D03NM129/03/M/IBM(Release 7.0.1HF346 | August 4, 2006) at 10/09/2006 11:41:56 MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 17bdfcaea25d1444baef0e24abc38874 Cc: nea@ietf.org, ietf@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="===============0788922744==" Errors-To: nea-bounces@ietf.org --===============0788922744== Content-type: multipart/alternative; Boundary="0__=07BBF891DFCD597C8f9e8a93df938690918c07BBF891DFCD597C" Content-Disposition: inline --0__=07BBF891DFCD597C8f9e8a93df938690918c07BBF891DFCD597C Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Ted Hardie wrote on 10/08/2006 11:45:37 PM: > [snip] > my sense is that the very core of this work is a perceived > need to be able to pass opaque strings between a host and the network= > prior to the host attaching. Yes, that is the essence of this work which is what we need to remember and focus on. It will probably be applied for various purposes= . > Those opaque strings are, essentially, > the vendor-specific strings currently associated with posture assessm= ent. > The standard protocol carrying these strings would connect on the net= work > side to a system that has plug-ins which understand the vendor-specif= ic > strings. > > With a charter that clarified that this was intended to assist the en= d > systems with vulnerabilities prior to attachment because the > network they are attaching to might be filled with danger, I > think this work would get done reasonably quickly. (As a control > mechanism to protect the network, I agree with the point made > clearly by others that this is not appropriate). > There seems to be confusion as two why people would want to do th= is. In one sense we can protect things by not giving compromised endpoints access to network-attached resources, including parts of the network itself. This application has caused significant discussion as to the security of the protocol and solutions using it, which promises to be a= subject of debate for the near future. Another way of looking at this is that it allows customers to use= the network to enforce endpoint compliance to policy and provide a convenie= nt "place" to challenge endpoints, collect data from them, thus providing = an audit trail. > I am less sure of the task of standardizing attributes. > > I am not sure that the number of attributes which can be standardized= > will ever be high enough to be truly useful, and I am pretty sure > that all of these will be already covered by vendor-specific attribut= es. > Since there must be an assessor in place on the client for those few > standardized attributes to be assessed and that assessor will likely already > have these covered by vendor-specific attributes, in other words, > we seem to be standardizing redundancy. On the network attachment > side, it is possible, of course, that an offer of remediation could b= e made > based on just the standard attributes, but it seems far more likely t= hat > it would be a two step process (assess standard attributes, then pass= > vendor-specific attributes to vendor plug-in). Again, if the vendor'= s > attributes cover the standard attributes, then this is largely redund= ant > and may add measurable latency; it seems far more likely that > step one would simply be skipped if there were a vendor-specific stri= ng > and an available plug-in. Since there has to be an assessor, the firs= t > seems very likely to me. If you don't have a vendor's plug-in, then > I suppose there is some chance that you will trust and act based on > the standard > attributes, but the chance of getting the right remediation seems > pretty slight in those circumstances. Especially when many vulnerabilities > are a combination of conditions, (Browser version Foo on OS patch lev= el Bar) > that you could remediate by upgrading either one, checking for and > acting on the attributes which could be standardized seems of very, v= ery > limited utility. > Standardized VS vendor-specific attributes is not something that needs to be solved today. Solutions can start with vendor-specific and migrate toward a standard, if one develops, without changing the protoc= ol. The specification should not preclude the addition of standardized attributes. IE the specification is like an alphabet, attributes are li= ke vocabulary. You can add new words without changing the letters. > Ted Hardie > > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea Frank Yeh= --0__=07BBF891DFCD597C8f9e8a93df938690918c07BBF891DFCD597C Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Ted Hardie <hardie@qualcomm.com> wrote on 10/08/2006 11:45= :37 PM:

> [snip]
> my sense is that the very core of this work is a perceived > need to be able to pass opaque strings between a host and the netw= ork
> prior to the host attaching.  

Yes, that is the essence of this work which is what we need to rem= ember and focus on. It will probably be applied for various purposes.

> Those opaque strings are, essentially,
> the vendor-specific strings currently associated with posture asse= ssment.
> The standard protocol carrying these strings would connect on the = network
> side to a system that has plug-ins which understand the vendor-spe= cific
> strings.  
>
> With a charter that clarified that this was intended to assist the= end
> systems with vulnerabilities prior to attachment because the
> network they are attaching to might be filled with danger, I
> think this work would get done reasonably quickly. (As a control > mechanism to protect the network, I agree with the point made
> clearly by others that this is not appropriate).
>

There seems to be confusion as two why people would want to do thi= s. In one sense we can protect things by not giving compromised endpoin= ts access to network-attached resources, including parts of the network= itself. This application has caused significant discussion as to the s= ecurity of the protocol and solutions using it, which promises to be a = subject of debate for the near future.

Another way of looking at this is that it allows customers to use = the network to enforce endpoint compliance to policy and provide a conv= enient "place" to challenge endpoints, collect data from them= , thus providing an audit trail.

> I am less sure of the task of standardizing attributes.
>
> I am not sure that the number of attributes which can be standardi= zed
> will ever be high enough to be truly useful, and I am pretty sure<= br> > that all of these will be already covered by vendor-specific attri= butes.
> Since there must be an assessor in place on the client for those f= ew
> standardized attributes to be assessed and that assessor will like= ly already
> have these covered by vendor-specific attributes, in other words,<= br> > we seem to be standardizing redundancy.  On the network attac= hment
> side, it is possible, of course, that an offer of remediation coul= d be made
> based on just the standard attributes, but it seems far more likel= y that
> it would be a two step process (assess standard attributes, then p= ass
> vendor-specific attributes to vendor plug-in).  Again, if the= vendor's
> attributes cover the standard attributes, then this is largely red= undant
> and may add measurable latency; it seems far more likely that
= > step one would simply be skipped if there were a vendor-specific s= tring
> and an available plug-in. Since there has to be an assessor, the f= irst
> seems very likely to me.  If you don't have a vendor's plug-i= n, then
> I suppose there is some chance that you will trust and act based o= n
> the standard
> attributes, but the chance of getting the right remediation seems<= br> > pretty slight in those circumstances.  Especially when many v= ulnerabilities
> are a combination of conditions, (Browser version Foo on OS patch = level Bar)
> that you could remediate by upgrading either one, checking for and=
> acting on the attributes which could be standardized seems of very= , very
> limited utility.
>

Standardized VS vendor-specific attributes is not something that n= eeds to be solved today. Solutions can start with vendor-specific and m= igrate toward a standard, if one develops, without changing the protoco= l. The specification should not preclude the addition of standardized a= ttributes. IE the specification is like an alphabet, attributes are lik= e vocabulary. You can add new words without changing the letters.<= br>
 
>             Ted Hardie
>
> _______________________________________________
> Nea mailing list
> Nea@ietf.org
> https://www= 1.ietf.org/mailman/listinfo/nea

Frank Yeh
= --0__=07BBF891DFCD597C8f9e8a93df938690918c07BBF891DFCD597C-- --===============0788922744== 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 --===============0788922744==-- From nea-bounces@ietf.org Mon Oct 09 13:48:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWzFK-0004UZ-1B; Mon, 09 Oct 2006 13:48:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWz35-00041B-VP; Mon, 09 Oct 2006 13:36:19 -0400 Received: from [2001:4f8:3:bb:20c:76ff:fe16:4040] (helo=goliath.isc.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWz33-0008Bx-K6; Mon, 09 Oct 2006 13:36:19 -0400 Received: by goliath.isc.org (Postfix, from userid 10200) id 13D6F5A5D1; Mon, 9 Oct 2006 10:36:11 -0700 (PDT) Date: Mon, 9 Oct 2006 10:36:10 -0700 From: "David W. Hankins" To: ietf@ietf.org Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Message-ID: <20061009173610.GC9743@isc.org> References: <452A5D46.1070701@zurich.ibm.com> <010601c6ebbd$877eac90$010aa8c0@home.glassey.com> Mime-Version: 1.0 In-Reply-To: <010601c6ebbd$877eac90$010aa8c0@home.glassey.com> User-Agent: Mutt/1.5.9i X-Spam-Score: -2.8 (--) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-Mailman-Approved-At: Mon, 09 Oct 2006 13:48:57 -0400 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="===============1874015321==" Errors-To: nea-bounces@ietf.org --===============1874015321== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="k+w/mQv8wyuph6w0" Content-Disposition: inline --k+w/mQv8wyuph6w0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Oct 09, 2006 at 09:08:42AM -0700, todd glassey wrote: > No it wasn't Brian - the WIPO IP Framework calls for a set of protections > for Industrial Designs which ALL of the work that happens here is controlled > by right? I suppose you might consider ALL IETF work as protected or threatened by WIPO Inustrial Designs [1] treaties if you first accept that "ALL" IETF work is ornamental. But of course, the joke isn't funny if you have to explain it. [1] http://www.wipo.int/designs/en/designs.html -- ISC Training! October 16-20, 2006, in the San Francisco Bay Area, covering topics from DNS to DDNS & DHCP. Email training@isc.org. -- David W. Hankins "If you don't do it right the first time, Software Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --k+w/mQv8wyuph6w0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFFKoiKcXeLeWu2vmoRAslbAJ0Tht/WhKU0jw2CgITSm6Xdm2eMHACeOC3p 0mT1IOn4LHTGfLXDHOkG1Ww= =K2v3 -----END PGP SIGNATURE----- --k+w/mQv8wyuph6w0-- --===============1874015321== 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 --===============1874015321==-- From nea-bounces@ietf.org Mon Oct 09 14:24:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWzo1-0003Ke-6F; Mon, 09 Oct 2006 14:24:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GWznz-0003KT-4X; Mon, 09 Oct 2006 14:24:47 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GWznx-00010q-Dt; Mon, 09 Oct 2006 14:24:46 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k99IOffk002725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Oct 2006 11:24:41 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k99ILPuG018896; Mon, 9 Oct 2006 11:24:40 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Oct 2006 11:24:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea) Date: Mon, 9 Oct 2006 11:24:28 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] WG Review: Network Endpoint Assessment (nea) thread-index: AcbrKNWUzo//GYi9Rkekvc6zVIfDgAAl2ePA From: "Narayanan, Vidya" To: "Susan Thomson \(sethomso\)" X-OriginalArrivalTime: 09 Oct 2006 18:24:32.0613 (UTC) FILETIME=[2A8B3950:01C6EBD0] X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: nea@ietf.org, iesg@ietf.org, ietf@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 Susan,=20 > -----Original Message----- > From: Susan Thomson (sethomso) [mailto:sethomso@cisco.com]=20 > Sent: Sunday, October 08, 2006 3:27 PM > To: Narayanan, Vidya > Cc: nea@ietf.org; iesg@ietf.org; ietf@ietf.org > Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea)=20 >=20 >=20 > Hi Vidya >=20 > Inline ... >=20 > > >=20 > > How about adding this text - "It should be noted that the=20 > networks at=20 > > large are exposed to attacks from lying endpoints and external=20 > > entities attaching to the networks as well as any problems arising=20 > > from unknown vulnerabilities on NEA compliant endpoints. Hence, NEA=20 > > must not be considered a protection mechanism for networks.=20 > Further,=20 > > mechanisms needed to protect the network from all kinds of=20 > > vulnerabilities are expected to be a superset of any=20 > protection that=20 > > may be achieved by employing NEA"? > >=20 >=20 > It seems to me that this better belongs in a security=20 > considerations section of the NEA spec, especially given=20 > where we are in the review cycle and the amount of time spent=20 > on this specific section already. >=20 No, this text definitely needs to be on the charter. From the number of discussions even at this stage, it is clear that the charter lacks the clarity in this space. This is not text about a particular draft in NEA - it is about the scope of the WG.=20 > > That is not necessarily putting any requirements in the=20 > choice of the=20 > > mandatory to implement protocol itself, as I see it. I believe that=20 > > stating something like "The mandatory to implement PT=20 > protocol must be=20 > > generic enough to allow the execution of the NEA procedure without=20 > > forcing the need to re-execute network access procedures". > >=20 >=20 > I think protocol requirements belong in the requirements I-D. >=20 The charter text elsewhere does get into performing NEA procedures at network access. Perhaps that could be removed from the charter too? If the charter only specified that the PT protocol was out of scope and left out any text about the timing of execution of the PT protcol w.r.t. network access, that would be fine.=20 > > > Not only do I not see anything in the charter or milestones that=20 > > indicates that the WG is going to spend time exploring this, I=20 > > strongly believe this WG should not be spending any time looking at=20 > > this. The trust models for the cases where the devices are=20 > not owned=20 > > by the organization performing NEA are hugely different and=20 > can take=20 > > up its own WG to actually find something that applies there, if at=20 > > all. For one, this could be considered a violation of=20 > privacy by the=20 > > user of the device. Secondly, the end user's perspective of attacks=20 > > may be entirely different from the organization's=20 > perspective in this=20 > > case. Third, I simply can't see what the organization's interests=20 > > would be in protecting a device that doesn't even belong to=20 > it. Last=20 > > but not the least, this requires the endpoint to be running an NEA=20 > > client (that is interoperable with the NEA server of the=20 > organization)=20 > > - which in itself is often an unrealistic requirement. > >=20 > > Organizations that provide services in their networks to=20 > end users are=20 > > worried about protecting their resources (i.e., networks, servers,=20 > > etc.). As we have agreed, NEA does not protect such=20 > resources anyway. > > Plus, there is absolutely no reason such organizations=20 > should believe=20 > > that devices they don't own are in fact, truthful endpoints. > >=20 > > So, thinking that this WG must be looking into resolving this seems=20 > > flawed at several levels. In the interest of having a=20 > focused WG that=20 > > can get something useful accomplished, this does not make sense. > >=20 > No argument with your gist here. The point I was trying to=20 > make is that I think applicability may not be quite as "black=20 > and white" as your original text suggests, and it would be=20 > better if the applicability and security considerations=20 > associated with NEA be addressed in the WG and specified in=20 > the appropriate NEA documents. >=20 This again is not necessarily a document-specific issue. It applies in general to anything that will be produced by this WG.=20 > The charter could express itself better in this regard. If=20 > the last sentence was replaced with something like: "NEA can=20 > be limited in its applicability when the endpoint and the=20 > organization providing network access are owned by different=20 > parties. NEA applicability and security considerations will=20 > be described in the appropriate NEA documents." > Would this work?=20 >=20 Why would the charter not be limited to producing solutions that may be relevant to the case where the organization owns the end devices? As long as we agree that NEA is not intending to protect the network and is only meant to protect endpoints, keeping the scope to this would allow for more focussed and useful work. To that effect, here is some modified text:=20 "NEA can be limited in its applicability when the endpoint and the organization providing network access are owned by different parties. The resources and threat models in these cases can be vastly different and such cases are outside the scope of this WG. NEA applicability and security considerations will also be described in the appropriate NEA documents." Vidya _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Oct 09 15:35:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX0uq-0002ZL-E9; Mon, 09 Oct 2006 15:35:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX0YY-0001AX-0h; Mon, 09 Oct 2006 15:12:54 -0400 Received: from thunk.org ([69.25.196.29] helo=thunker.thunk.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX0YW-0004BR-QU; Mon, 09 Oct 2006 15:12:53 -0400 Received: from root (helo=candygram.thunk.org) by thunker.thunk.org with local-esmtps (tls_cipher TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.50 #1 (Debian)) id 1GX0Y0-0007Z3-LL; Mon, 09 Oct 2006 15:12:20 -0400 Received: from tytso by candygram.thunk.org with local (Exim 4.60) (envelope-from ) id 1GX0VH-000163-53; Mon, 09 Oct 2006 15:09:31 -0400 Date: Mon, 9 Oct 2006 15:09:31 -0400 From: Theodore Tso To: todd glassey Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Message-ID: <20061009190931.GC7990@thunk.org> References: <452A5D46.1070701@zurich.ibm.com> <010601c6ebbd$877eac90$010aa8c0@home.glassey.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <010601c6ebbd$877eac90$010aa8c0@home.glassey.com> User-Agent: Mutt/1.5.11 X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-Mailman-Approved-At: Mon, 09 Oct 2006 15:35:55 -0400 Cc: Brian E Carpenter , nea@ietf.org, ietf@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 Mon, Oct 09, 2006 at 09:08:42AM -0700, todd glassey wrote: > No it wasn't Brian - the WIPO IP Framework calls for a set of protections > for Industrial Designs which ALL of the work that happens here is controlled > by right? Otherwise, do you formally want to make a declaration as the > IETF's Chair that the IETF and the ISOC are immune from Global IP Law and > can pretty much do anything they want. Todd, According to the WIPO web site: "The World Intellectual Property Organization (WIPO) is a specialized agency of the United Nations. It is dedicated to developing a balanced and accessible international intellectual property (IP) system, which rewards creativity, stimulates innovation and contributes to economic development while safeguarding the public interest." What the WIPO might or might not call for might perhaps be of interest to various national legislative bodies, but it is completely out of scope for the IETF list. Regards, - Ted IETF Sergeant-at-Arms _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Oct 09 16:52:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX26Y-0005xQ-DG; Mon, 09 Oct 2006 16:52:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX23S-0005P2-Hd; Mon, 09 Oct 2006 16:48:54 -0400 Received: from chokecherry.srv.cs.cmu.edu ([128.2.185.41]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX23R-000334-8c; Mon, 09 Oct 2006 16:48:54 -0400 Received: from SIRIUS.FAC.CS.CMU.EDU (SIRIUS.FAC.CS.CMU.EDU [128.2.209.170]) (authenticated bits=0) by chokecherry.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id k99Kmk5f000526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Oct 2006 16:48:46 -0400 (EDT) Date: Mon, 09 Oct 2006 16:48:46 -0400 From: Jeffrey Hutzelman To: todd glassey , "Narayanan, Vidya" , iesg@ietf.org, ietf@ietf.org Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Message-ID: <80A16800AAE34B3E7EA23F62@sirius.fac.cs.cmu.edu> In-Reply-To: <00c601c6e806$a60d11c0$aa30f604@home.glassey.com> References: <00c601c6e806$a60d11c0$aa30f604@home.glassey.com> Originator-Info: login-token=Mulberry:01BeVTGG9NyIxRMMuZOGODh5xXikOMGcxyWoF9O2U=; token_authority=postmaster@andrew.cmu.edu X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-Mailman-Approved-At: Mon, 09 Oct 2006 16:52:04 -0400 Cc: nea@ietf.org, Jeffrey Hutzelman 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 Wednesday, October 04, 2006 02:31:36 PM -0700 todd glassey wrote: > Vidya good commentary, maybe I can add some more. The NEA, per the > charter-need's justification statement says: > >> >> Network Endpoint Assessment (NEA) architectures have been implemented >> in the industry to assess the "posture" of endpoint devices > > Ah two new terms of Art - "Posture" and "Devices". I only see one. I believe "device" is a fairly well-understood term, though perhaps "node" would have been more appropriate in this context. However, I completely agree that this proposed charter uses the term "posture" far too often not to define it. I fail to see how whether my computer is sitting upright or lying on its side is relevant to whether it should be allowed access to the network. -- Jeff _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Oct 09 17:00:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX2Et-0005rP-NT; Mon, 09 Oct 2006 17:00:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX2Du-00049G-EO; Mon, 09 Oct 2006 16:59:42 -0400 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX2Dt-0005f0-4w; Mon, 09 Oct 2006 16:59:42 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=uCy/mh5SPLKKpFApLTt13Oa7eIujTXnrX2/2oXfQmK2kDvzQKsBVnChOPQyGLLOR; 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.229] (helo=gw) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GX2D2-0004us-Pt; Mon, 09 Oct 2006 16:59:38 -0400 Message-ID: <015901c6ebe5$c3d1e9f0$010aa8c0@home.glassey.com> From: "todd glassey" To: "Theodore Tso" References: <452A5D46.1070701@zurich.ibm.com> <010601c6ebbd$877eac90$010aa8c0@home.glassey.com> <20061009190931.GC7990@thunk.org> Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Date: Mon, 9 Oct 2006 13:54:51 -0700 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: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec792947a9897ed0139773f45f46cbd40645350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.246.45.229 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 X-Mailman-Approved-At: Mon, 09 Oct 2006 17:00:43 -0400 Cc: Brian E Carpenter , nea@ietf.org, ietf@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 No you are wrong Ted, and its pretty funny too. As it happens you are incorrect for saying that this is inappropriate for the IETF's lists. You need to dig farther into the WIPO Site and find all the State Signatures to the Treaties - its them that the IETF is bound by whether it likes it or not. Since the countries through with the IETF's actions operate including the meetings, are all signatories to the WIPO Treaties you are exactly stuck with them. Todd Glassey ----- Original Message ----- From: "Theodore Tso" To: "todd glassey" Cc: "Brian E Carpenter" ; ; Sent: Monday, October 09, 2006 12:09 PM Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) > On Mon, Oct 09, 2006 at 09:08:42AM -0700, todd glassey wrote: > > No it wasn't Brian - the WIPO IP Framework calls for a set of protections > > for Industrial Designs which ALL of the work that happens here is controlled > > by right? Otherwise, do you formally want to make a declaration as the > > IETF's Chair that the IETF and the ISOC are immune from Global IP Law and > > can pretty much do anything they want. > > Todd, > > According to the WIPO web site: > > "The World Intellectual Property Organization (WIPO) is a > specialized agency of the United Nations. It is dedicated to > developing a balanced and accessible international intellectual > property (IP) system, which rewards creativity, stimulates innovation > and contributes to economic development while safeguarding the public > interest." > > What the WIPO might or might not call for might perhaps be of interest > to various national legislative bodies, but it is completely out of > scope for the IETF list. > > Regards, > > - Ted > IETF Sergeant-at-Arms > _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Oct 09 17:08:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX2MD-00011O-Rb; Mon, 09 Oct 2006 17:08:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX2MB-000117-BP for nea@ietf.org; Mon, 09 Oct 2006 17:08:15 -0400 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 1GX2M9-0007Oq-IF for nea@ietf.org; Mon, 09 Oct 2006 17:08:15 -0400 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 1GX2M8-0007jn-6u for nea@ietf.org; Tue, 10 Oct 2006 07:08:12 +1000 Received: (qmail 9018 invoked by uid 453); 9 Oct 2006 20:25:55 -0000 Received: from speedy.dhs (HELO speedy) (192.168.0.8) by dhs (qpsmtpd/0.31-dev) with ESMTP; Tue, 10 Oct 2006 06:25:55 +1000 From: "Darryl \(Dassa\) Lynch" To: Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea) Date: Tue, 10 Oct 2006 07:08:08 +1000 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 Thread-Index: AcbrrKTkUTzsP64MSDKrVuRXzHXuhQAOZRbQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-Reply-To: <45294FBA.8040800@alvestrand.no> X-Spam-Score: 0.0 (/) 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: Harald Alvestrand wrote: >> Posture checking is certainly a leaky bucket. It doesn't >> protect all kinds of endpoint, it doesn't protect the >> endpoints against all kinds of threats, and it doesn't >> protect much of anything against a smart, resourceful >> attacker who is deeply familiar with the NEA system in use >> and is interested in investing considerable resources in >> attacking or circumventing it. [...] Content analysis details: (0.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: nea@ietf.org 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: Harald Alvestrand wrote: >> Posture checking is certainly a leaky bucket. It doesn't >> protect all kinds of endpoint, it doesn't protect the >> endpoints against all kinds of threats, and it doesn't >> protect much of anything against a smart, resourceful >> attacker who is deeply familiar with the NEA system in use >> and is interested in investing considerable resources in >> attacking or circumventing it. NEA itself may not offer any protection, it is more an informational tool from my perspective. How that information may be used could lead to some protection but that would vary with each deployment. >> But (to recycle a very old simile) the fact that I can open >> the locks of most doors with a crowbar doesn't mean that locks are >> not useful. Organizations that have deployed products that do >> something like what NEA is talking about have reported that their >> TCO is reduced. In these days of information overload I still maintain, the more information available the better it is. Darryl (Dassa) Lynch _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Oct 09 17:27:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX2fB-0002qp-Lc; Mon, 09 Oct 2006 17:27:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX2dS-0002NX-Hn; Mon, 09 Oct 2006 17:26:06 -0400 Received: from thunk.org ([69.25.196.29] helo=thunker.thunk.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX2dR-0002TH-BU; Mon, 09 Oct 2006 17:26:06 -0400 Received: from root (helo=candygram.thunk.org) by thunker.thunk.org with local-esmtps (tls_cipher TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.50 #1 (Debian)) id 1GX2g1-0008JO-Gh; Mon, 09 Oct 2006 17:28:45 -0400 Received: from tytso by candygram.thunk.org with local (Exim 4.60) (envelope-from ) id 1GX2dH-0006jZ-Qh; Mon, 09 Oct 2006 17:25:55 -0400 Date: Mon, 9 Oct 2006 17:25:55 -0400 From: Theodore Tso To: todd glassey Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Message-ID: <20061009212555.GD7990@thunk.org> References: <452A5D46.1070701@zurich.ibm.com> <010601c6ebbd$877eac90$010aa8c0@home.glassey.com> <20061009190931.GC7990@thunk.org> <015901c6ebe5$c3d1e9f0$010aa8c0@home.glassey.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <015901c6ebe5$c3d1e9f0$010aa8c0@home.glassey.com> User-Agent: Mutt/1.5.11 X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-Mailman-Approved-At: Mon, 09 Oct 2006 17:27:52 -0400 Cc: Brian E Carpenter , nea@ietf.org, ietf@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 Mon, Oct 09, 2006 at 01:54:51PM -0700, todd glassey wrote: > No you are wrong Ted, and its pretty funny too. As it happens you are > incorrect for saying that this is inappropriate for the IETF's lists. > > You need to dig farther into the WIPO Site and find all the State Signatures > to the Treaties - its them that the IETF is bound by whether it likes it or > not. Since the countries through with the IETF's actions operate including > the meetings, are all signatories to the WIPO Treaties you are exactly stuck > with them. I said it was inappropraite for the IETF list. If you have specific ideas as they relate to the ipr working group, feel free to be specific about specific WIPO treaties that have resulted in national legislation, and specific changes to be made to IETF's IPR policies, feel free to make them on that list, but not on the main IETF list, please. Thanks, - Ted _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Oct 09 18:02:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX3CJ-0002TK-BS; Mon, 09 Oct 2006 18:02:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX2ra-0002HJ-OV; Mon, 09 Oct 2006 17:40:42 -0400 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX2rZ-0004t7-2C; Mon, 09 Oct 2006 17:40:42 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=W7QuCAFx3xf1GdYpY4bXUZpcU97PP3kooPWWX1Oz+5bXEWVkTKadG6o9EK+yLg2D; 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.229] (helo=gw) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GX2rX-0005jC-Jq; Mon, 09 Oct 2006 17:40:40 -0400 Message-ID: <017a01c6ebeb$96cfcac0$010aa8c0@home.glassey.com> From: "todd glassey" To: "Theodore Tso" References: <452A5D46.1070701@zurich.ibm.com> <010601c6ebbd$877eac90$010aa8c0@home.glassey.com> <20061009190931.GC7990@thunk.org> <015901c6ebe5$c3d1e9f0$010aa8c0@home.glassey.com> <20061009212555.GD7990@thunk.org> Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Date: Mon, 9 Oct 2006 14:39:46 -0700 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: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79259a20f24805bc03b43c0950a37da4f6350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.246.45.229 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-Mailman-Approved-At: Mon, 09 Oct 2006 18:02:06 -0400 Cc: Brian E Carpenter , nea@ietf.org, ietf@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 So then Ted are you formally saying that it is inappropriate to discuss IETF operations or its processes on the IETF@IETF.ORG mailing list? The problem with the IPR working group is simply that Harald kicks people off for disagreeing with him or his very limited charter. He doesn't want to hear about expanding the charter or how these other issues fit into the IPR Working Group and in doing so he is violating my and others participatory rights as well as our First Amendment rights I believe too. Todd Glassey. ----- Original Message ----- From: "Theodore Tso" To: "todd glassey" Cc: "Brian E Carpenter" ; ; Sent: Monday, October 09, 2006 2:25 PM Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) > On Mon, Oct 09, 2006 at 01:54:51PM -0700, todd glassey wrote: > > No you are wrong Ted, and its pretty funny too. As it happens you are > > incorrect for saying that this is inappropriate for the IETF's lists. > > > > You need to dig farther into the WIPO Site and find all the State Signatures > > to the Treaties - its them that the IETF is bound by whether it likes it or > > not. Since the countries through with the IETF's actions operate including > > the meetings, are all signatories to the WIPO Treaties you are exactly stuck > > with them. > > I said it was inappropraite for the IETF list. If you have specific > ideas as they reFrom nea-bounces@ietf.org Mon Oct 09 18:02:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX3CJ-0002TK-BS; Mon, 09 Oct 2006 18:02:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX2ra-0002HJ-OV; Mon, 09 Oct 2006 17:40:42 -0400 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX2rZ-0004t7-2C; Mon, 09 Oct 2006 17:40:42 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=W7QuCAFx3xf1GdYpY4bXUZpcU97PP3kooPWWX1Oz+5bXEWVkTKadG6o9EK+yLg2D; 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.229] (helo=gw) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GX2rX-0005jC-Jq; Mon, 09 Oct 2006 17:40:40 -0400 Message-ID: <017a01c6ebeb$96cfcac0$010aa8c0@home.glassey.com> From: "todd glassey" To: "Theodore Tso" References: <452A5D46.1070701@zurich.ibm.com> <010601c6ebbd$877eac90$010aa8c0@home.glassey.com> <20061009190931.GC7990@thunk.org> <015901c6ebe5$c3d1e9f0$010aa8c0@home.glassey.com> <20061009212555.GD7990@thunk.org> Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Date: Mon, 9 Oct 2006 14:39:46 -0700 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: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79259a20f24805bc03b43c0950a37da4f6350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.246.45.229 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-Mailman-Approved-At: Mon, 09 Oct 2006 18:02:06 -0400 Cc: Brian E Carpenter , nea@ietf.org, ietf@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 So then Ted are you formally saying that it is inappropriate to discuss IETF operations or its processes on the IETF@IETF.ORG mailing list? The problem with the IPR working group is simply that Harald kicks people off for disagreeing with him or his very limited charter. He doesn't want to hear about expanding the charter or how these other issues fit into the IPR Working Group and in doing so he is violating my and others participatory rights as well as our First Amendment rights I believe too. Todd Glassey. ----- Original Message ----- From: "Theodore Tso" To: "todd glassey" Cc: "Brian E Carpenter" ; ; Sent: Monday, October 09, 2006 2:25 PM Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) > On Mon, Oct 09, 2006 at 01:54:51PM -0700, todd glassey wrote: > > No you are wrong Ted, and its pretty funny too. As it happens you are > > incorrect for saying that this is inappropriate for the IETF's lists. > > > > You need to dig farther into the WIPO Site and find all the State Signatures > > to the Treaties - its them that the IETF is bound by whether it likes it or > > not. Since the countries through with the IETF's actions operate including > > the meetings, are all signatories to the WIPO Treaties you are exactly stuck > > with them. > > I said it was inappropraite for the IETF list. If you have specific > ideas as they relate to the ipr working group, feel free to be > specific about specific WIPO treaties that have resulted in national > legislation, and specific changes to be made to IETF's IPR policies, > feel free to make them on that list, but not on the main IETF list, > please. > > Thanks, > > - Ted _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Oct 09 18:02:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX3CJ-0002TF-82; Mon, 09 Oct 2006 18:02:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX2rY-0002G5-6A; Mon, 09 Oct 2006 17:40:40 -0400 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX2rW-0004sh-T5; Mon, 09 Oct 2006 17:40:40 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Q8w0UuWc8mmGiYp6xFWJxRiXzlX/7Fb5RiUNFMf1aaKSJQry/d+Rmcd9+M1HzD7I; 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.229] (helo=gw) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GX2rS-0005jC-AI; Mon, 09 Oct 2006 17:40:35 -0400 Message-ID: <017901c6ebeb$93a9d2a0$010aa8c0@home.glassey.com> From: "todd glassey" To: "Jeffrey Hutzelman" , "Narayanan, Vidya" , , References: <00c601c6e806$a60d11c0$aa30f604@home.glassey.com> <80A16800AAE34B3E7EA23F62@sirius.fac.cs.cmu.edu> Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Date: Mon, 9 Oct 2006 14:36:30 -0700 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: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79059cdb24c3f55c975c27fea7cac7c13f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.246.45.229 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-Mailman-Approved-At: Mon, 09 Oct 2006 18:02:06 -0400 Cc: nea@ietf.org, Jeffrey Hutzelman 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 Jeff - ----- Original Message ----- From: "Jeffrey Hutzelman" To: "todd glassey" ; "Narayanan, Vidya" ; ; Cc: ; "Jeffrey Hutzelman" Sent: Monday, October 09, 2006 1:48 PM Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) > > > > Ah two new terms of Art - "Posture" and "Devices". > > I only see one. I believe "device" is a fairly well-understood term, > though perhaps "node" would have been more appropriate in this context. > > However, I completely agree that this proposed charter uses the term > "posture" far too often not to define it. I fail to see how whether my > computer is sitting upright or lying on its side is relevant to whether it > should be allowed access to the network. > > -- Jeff OK Devices is really well defined in both a technical and legal sense per the Device based Frauds Act - the little brother of the CFAA. But in this instance I wanted to bringlate to the ipr working group, feel free to be > specific about specific WIPO treaties that have resulted in national > legislation, and specific changes to be made to IETF's IPR policies, > feel free to make them on that list, but not on the main IETF list, > please. > > Thanks, > > - Ted _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Oct 09 18:02:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX3CJ-0002TF-82; Mon, 09 Oct 2006 18:02:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX2rY-0002G5-6A; Mon, 09 Oct 2006 17:40:40 -0400 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX2rW-0004sh-T5; Mon, 09 Oct 2006 17:40:40 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Q8w0UuWc8mmGiYp6xFWJxRiXzlX/7Fb5RiUNFMf1aaKSJQry/d+Rmcd9+M1HzD7I; 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.229] (helo=gw) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GX2rS-0005jC-AI; Mon, 09 Oct 2006 17:40:35 -0400 Message-ID: <017901c6ebeb$93a9d2a0$010aa8c0@home.glassey.com> From: "todd glassey" To: "Jeffrey Hutzelman" , "Narayanan, Vidya" , , References: <00c601c6e806$a60d11c0$aa30f604@home.glassey.com> <80A16800AAE34B3E7EA23F62@sirius.fac.cs.cmu.edu> Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Date: Mon, 9 Oct 2006 14:36:30 -0700 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: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79059cdb24c3f55c975c27fea7cac7c13f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.246.45.229 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 X-Mailman-Approved-At: Mon, 09 Oct 2006 18:02:06 -0400 Cc: nea@ietf.org, Jeffrey Hutzelman 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 Jeff - ----- Original Message ----- From: "Jeffrey Hutzelman" To: "todd glassey" ; "Narayanan, Vidya" ; ; Cc: ; "Jeffrey Hutzelman" Sent: Monday, October 09, 2006 1:48 PM Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) > > > > Ah two new terms of Art - "Posture" and "Devices". > > I only see one. I believe "device" is a fairly well-understood term, > though perhaps "node" would have been more appropriate in this context. > > However, I completely agree that this proposed charter uses the term > "posture" far too often not to define it. I fail to see how whether my > computer is sitting upright or lying on its side is relevant to whether it > should be allowed access to the network. > > -- Jeff OK Devices is really well defined in both a technical and legal sense per the Device based Frauds Act - the little brother of the CFAA. But in this instance I wanted to bring out the use of the misnomer "Posture" relative to a Device. The Device is what it is. The Posture is clearly a term for Operating Policy which includes change management, security/integrity proofing, and the general state-response policies that make up the controls and processes for the Entity in question. The problem we both saw was the indiscriminant use of the term Posture to define a group of policies which were specific to a number of things that the Charter was trying to lay claim to. I don't necessarily think the NEA is a bad idea - but its about auditing and so it needs to be crafted as an audit tool and use audit speak in the process IMHO. Todd Glassey _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea out the use of the misnomer "Posture" relative to a Device. The Device is what it is. The Posture is clearly a term for Operating Policy which includes change management, security/integrity proofing, and the general state-response policies that make up the controls and processes for the Entity in question. The problem we both saw was the indiscriminant use of the term Posture to define a group of policies which were specific to a number of things that the Charter was trying to lay claim to. I don't necessarily think the NEA is a bad idea - but its about auditing and so it needs to be crafted as an audit tool and use audit speak in the process IMHO. Todd Glassey _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Oct 09 20:04:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX56t-0000fr-02; Mon, 09 Oct 2006 20:04:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX56r-0000eH-KJ; Mon, 09 Oct 2006 20:04:37 -0400 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX56q-0005Qh-AZ; Mon, 09 Oct 2006 20:04:37 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=EIqj6Q82YU5oWNzrxGNuEfLzWn/Vvnm6Wqq27pEonLi/9lVD7b4CFte8DofsqIVe; 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.229] (helo=gw) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GX56p-0008B3-9z; Mon, 09 Oct 2006 20:04:36 -0400 Message-ID: <021401c6ebff$b225d710$010aa8c0@home.glassey.com> From: "todd glassey" To: "Theodore Tso" References: <452A5D46.1070701@zurich.ibm.com> <010601c6ebbd$877eac90$010aa8c0@home.glassey.com> <20061009190931.GC7990@thunk.org> <015901c6ebe5$c3d1e9f0$010aa8c0@home.glassey.com> <20061009212555.GD7990@thunk.org> <017a01c6ebeb$96cfcac0$010aa8c0@home.glassey.com> <20061009221649.GA9460@thunk.org> Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Date: Mon, 9 Oct 2006 17:04:14 -0700 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: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79918694897452ec7e04592e81eda47322350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.246.45.229 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: nea@ietf.org, ietf@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 You know Ted you crack me up. Todd Glassey ----- Original Message ----- From: "Theodore Tso" To: "todd glassey" Cc: ; Sent: Monday, October 09, 2006 3:16 PM Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) > On Mon, Oct 09, 2006 at 02:39:46PM -0700, todd glassey wrote: > > So then Ted are you formally saying that it is inappropriate to discuss IETF > > operations or its processes on the IETF@IETF.ORG mailing list? > > If you have a specific and actionable suggestion regarding IETF > direction, policy, meetings, and procedures, where there is not a more > appropriate e-mail venue (such as the IPR wg list), then it is > certainly, appropriate for the IETF list. > > Your recent postings, alas, have not met this test. > > > The problem with the IPR working group is simply that Harald kicks people > > off for disagreeing with him or his very limited charter. He doesn't want to > > hear about expanding the charter or how these other issues fit into the IPR > > Working Group and in doing so he is violating my and others participatory > > rights as well as our First Amendment rights I believe too. > > First Amendment rights only apply when the US Government restricts > speech. It does not apply anywhere else. In general, you have been > making various legal claims without being a lawyer, and fairly wild > ones which make it very clear that you don't know what you are talking > about. For what it's worth, be advised that I know of know legally > enforceable "right" that you might have towards participating in any > IETF forum, and certainly if you persist in sounding like someone who > does not know what they are talking about, no one is required to > listen to you, either --- and more and more people may in fact decide > that it is wise for them to exercise their right to ignore you. > > Regards, > > - Ted _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Oct 09 22:50:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX7hY-0002g9-5g; Mon, 09 Oct 2006 22:50:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX7hX-0002ff-EP; Mon, 09 Oct 2006 22:50:39 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX7hW-0004CI-5B; Mon, 09 Oct 2006 22:50:39 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J6W00375FR4CA@usaga01-in.huawei.com>; Mon, 09 Oct 2006 19:47:29 -0700 (PDT) Received: from huawei.com ([172.17.1.218]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J6W00FPTFR2C2@usaga01-in.huawei.com>; Mon, 09 Oct 2006 19:47:28 -0700 (PDT) Received: from [172.24.1.18] (Forwarded-For: [10.110.108.66]) by szxmc02-in.huawei.com (mshttpd); Tue, 10 Oct 2006 10:50:34 +0800 Date: Tue, 10 Oct 2006 10:50:34 +0800 From: yinhan 34728 Subject: =?gb2312?B?u9i4tA==?=:Re: [Nea] WG Review: Network Endpoint Assessment (nea) To: Jeffrey Hutzelman Message-id: <297200e29758a1.29758a1297200e@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: zh-CN Priority: normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: nea@ietf.org, iesg@ietf.org, ietf@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 Wednesday, October 04, 2006 02:31:36 PM -0700 todd glassey > wrote: > > > Vidya good commentary, maybe I can add some more. The NEA, per the > > charter-need's justification statement says: > > > >> > >> Network Endpoint Assessment (NEA) architectures have been > implemented>> in the industry to assess the "posture" of endpoint > devices> > > Ah two new terms of Art - "Posture" and "Devices". > > I only see one. I believe "device" is a fairly well-understood > term, > though perhaps "node" would have been more appropriate in this > context. > However, I completely agree that this proposed charter uses the > term > "posture" far too often not to define it. I fail to see how > whether my > computer is sitting upright or lying on its side is relevant to > whether it > should be allowed access to the network. > How about "snapshot" ? > -- Jeff > > _______________________________________________ > 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 Oct 09 23:27:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX8Gv-0001XR-WD; Mon, 09 Oct 2006 23:27:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX8Gu-0001XJ-RY; Mon, 09 Oct 2006 23:27:12 -0400 Received: from usaga01-in.huawei.com ([12.129.211.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX8Gt-0001wv-Hr; Mon, 09 Oct 2006 23:27:12 -0400 Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J6W003PGHFZCA@usaga01-in.huawei.com>; Mon, 09 Oct 2006 20:24:00 -0700 (PDT) Received: from huawei.com ([172.17.1.218]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J6W00FQ3HFYC2@usaga01-in.huawei.com>; Mon, 09 Oct 2006 20:23:59 -0700 (PDT) Received: from [172.24.1.18] (Forwarded-For: [10.110.108.66]) by szxmc02-in.huawei.com (mshttpd); Tue, 10 Oct 2006 11:27:07 +0800 Date: Tue, 10 Oct 2006 11:27:07 +0800 From: yinhan 34728 Subject: Re:[Nea] WG Review: Network Endpoint Assessment (nea) To: Ted Hardie Message-id: <297c86c297dc26.297dc26297c86c@huawei.com> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.25 (built Mar 3 2004) Content-type: text/plain; charset=us-ascii Content-language: zh-CN Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: zh-CN Priority: normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: nea@ietf.org, ietf@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 have a very basic fear that this working group is getting chartered > with a bunch of aims added by people who will not take on the > task of doing the work. After private discussion with folks > involved, my sense is that the very core of this work is a > perceived > need to be able to pass opaque strings between a host and the > network > prior to the host attaching. Those opaque strings are, essentially, > the vendor-specific strings currently associated with posture > assessment.The standard protocol carrying these strings would > connect on the network > side to a system that has plug-ins which understand the vendor- > specificstrings. > > With a charter that clarified that this was intended to assist the end > systems with vulnerabilities prior to attachment because the > network they are attaching to might be filled with danger, I > think this work would get done reasonably quickly. (As a control > mechanism to protect the network, I agree with the point made > clearly by others that this is not appropriate). > > I am less sure of the task of standardizing attributes. > > I am not sure that the number of attributes which can be standardized > will ever be high enough to be truly useful, and I am pretty sure > that all of these will be already covered by vendor-specific > attributes.Since there must be an assessor in place on the client > for those few > standardized attributes to be assessed and that assessor will > likely already > have these covered by vendor-specific attributes, in other words, > we seem to be standardizing redundancy. On the network attachment > side, it is possible, of course, that an offer of remediation > could be made > based on just the standard attributes, but it seems far more > likely that > it would be a two step process (assess standard attributes, then pass > vendor-specific attributes to vendor plug-in). Again, if the vendor's > attributes cover the standard attributes, then this is largely > redundantand may add measurable latency; it seems far more likely > that > step one would simply be skipped if there were a vendor-specific > stringand an available plug-in. Since there has to be an assessor, > the first > seems very likely to me. If you don't have a vendor's plug-in, then > I suppose there is some chance that you will trust and act based > on the standard > attributes, but the chance of getting the right remediation seems > pretty slight in those circumstances. Especially when many > vulnerabilitiesare a combination of conditions, (Browser version > Foo on OS patch level Bar) > that you could remediate by upgrading either one, checking for and > acting on the attributes which could be standardized seems of > very, very > limited utility. I think that most function should be completed through vendor-specific attributes and standard attributes are only basic information. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 10 08:00:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXGHY-0001JE-T8; Tue, 10 Oct 2006 08:00:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GX3ax-0007qM-Fx; Mon, 09 Oct 2006 18:27:35 -0400 Received: from thunk.org ([69.25.196.29] helo=thunker.thunk.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GX3Qa-00038l-Je; Mon, 09 Oct 2006 18:16:53 -0400 Received: from root (helo=candygram.thunk.org) by thunker.thunk.org with local-esmtps (tls_cipher TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.50 #1 (Debian)) id 1GX3TH-0000JS-MC; Mon, 09 Oct 2006 18:19:39 -0400 Received: from tytso by candygram.thunk.org with local (Exim 4.60) (envelope-from ) id 1GX3QX-0003Ty-W6; Mon, 09 Oct 2006 18:16:50 -0400 Date: Mon, 9 Oct 2006 18:16:49 -0400 From: Theodore Tso To: todd glassey Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Message-ID: <20061009221649.GA9460@thunk.org> References: <452A5D46.1070701@zurich.ibm.com> <010601c6ebbd$877eac90$010aa8c0@home.glassey.com> <20061009190931.GC7990@thunk.org> <015901c6ebe5$c3d1e9f0$010aa8c0@home.glassey.com> <20061009212555.GD7990@thunk.org> <017a01c6ebeb$96cfcac0$010aa8c0@home.glassey.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <017a01c6ebeb$96cfcac0$010aa8c0@home.glassey.com> User-Agent: Mutt/1.5.11 X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-Mailman-Approved-At: Tue, 10 Oct 2006 08:00:23 -0400 Cc: nea@ietf.org, ietf@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 Mon, Oct 09, 2006 at 02:39:46PM -0700, todd glassey wrote: > So then Ted are you formally saying that it is inappropriate to discuss IETF > operations or its processes on the IETF@IETF.ORG mailing list? If you have a specific and actionable suggestion regarding IETF direction, policy, meetings, and procedures, where there is not a more appropriate e-mail venue (such as the IPR wg list), then it is certainly, appropriate for the IETF list. Your recent postings, alas, have not met this test. > The problem with the IPR working group is simply that Harald kicks people > off for disagreeing with him or his very limited charter. He doesn't want to > hear about expanding the charter or how these other issues fit into the IPR > Working Group and in doing so he is violating my and others participatory > rights as well as our First Amendment rights I believe too. First Amendment rights only apply when the US Government restricts speech. It does not apply anywhere else. In general, you have been making various legal claims without being a lawyer, and fairly wild ones which make it very clear that you don't know what you are talking about. For what it's worth, be advised that I know of know legally enforceable "right" that you might have towards participating in any IETF forum, and certainly if you persist in sounding like someone who does not know what they are talking about, no one is required to listen to you, either --- and more and more people may in fact decide that it is wise for them to exercise their right to ignore you. Regards, - Ted _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 10 14:58:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXMno-00055l-VJ; Tue, 10 Oct 2006 14:58:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXMno-00055d-BS; Tue, 10 Oct 2006 14:58:08 -0400 Received: from elasmtp-galgo.atl.sa.earthlink.net ([209.86.89.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXMnm-0008JL-09; Tue, 10 Oct 2006 14:58:08 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=NRHEsiq9ZxH4bf0AuK6D/2LhOJYpRZquVjXxplxSRVbqtcNRjcjO5oea+CRmzatf; 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.153] (helo=gw) by elasmtp-galgo.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GXMnk-0007gY-RK; Tue, 10 Oct 2006 14:58:05 -0400 Message-ID: <035201c6ec9e$0bf23b50$010aa8c0@home.glassey.com> From: "todd glassey" To: "Theodore Tso" References: <452A5D46.1070701@zurich.ibm.com> <010601c6ebbd$877eac90$010aa8c0@home.glassey.com> <20061009190931.GC7990@thunk.org> <015901c6ebe5$c3d1e9f0$010aa8c0@home.glassey.com> <20061009212555.GD7990@thunk.org> <017a01c6ebeb$96cfcac0$010aa8c0@home.glassey.com> <20061009221649.GA9460@thunk.org> Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Date: Tue, 10 Oct 2006 11:37:49 -0700 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: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec7999ae0d0071ef474853163b615b843626350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.246.45.153 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: nea@ietf.org, ietf@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 Hey Ted - the more I thought about this post of yours the more it annoyed me. You see - when a WG chair doesn't want someone saying something in their WG and they control the number of players in that WG, they will always control the consensus such as it is. The point is that there is no where to permanently register a dissenting opinion in an effort or IETF program now that you claim that the charter for the IETF@IETF.ORG mailing list is restricted. The IETF needs IMHO one general list for everything that doesn't fall under the rubric/charter/umbrella of some WG and their list, and personally after NETWORK was shutdown I thought that this was it. Todd Glassey ----- Original Message ----- From: "Theodore Tso" To: "todd glassey" Cc: ; Sent: Monday, October 09, 2006 3:16 PM Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) > On Mon, Oct 09, 2006 at 02:39:46PM -0700, todd glassey wrote: > > So then Ted are you formally saying that it is inappropriate to discuss IETF > > operations or its processes on the IETF@IETF.ORG mailing list? > > If you have a specific and actionable suggestion regarding IETF > direction, policy, meetings, and procedures, where there is not a more > appropriate e-mail venue (such as the IPR wg list), then it is > certainly, appropriate for the IETF list. > > Your recent postings, alas, have not met this test. > > > The problem with the IPR working group is simply that Harald kicks people > > off for disagreeing with him or his very limited charter. He doesn't want to > > hear about expanding the charter or how these other issues fit into the IPR > > Working Group and in doing so he is violating my and others participatory > > rights as well as our First Amendment rights I believe too. > > First Amendment rights only apply when the US Government restricts > speech. It does not apply anywhere else. In general, you have been > making various legal claims without being a lawyer, and fairly wild > ones which make it very clear that you don't know what you are talking > about. For what it's worth, be advised that I know of know legally > enforceable "right" that you might have towards participating in any > IETF forum, and certainly if you persist in sounding like someone who > does not know what they are talking about, no one is required to > listen to you, either --- and more and more people may in fact decide > that it is wise for them to exercise their right to ignore you. > > Regards, > > - Ted _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 10 15:35:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXNNh-0004Eg-FE; Tue, 10 Oct 2006 15:35:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXNNf-0004EP-Af; Tue, 10 Oct 2006 15:35:11 -0400 Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXNNW-0005ki-NX; Tue, 10 Oct 2006 15:35:11 -0400 Received: from [192.35.165.61] by consulintel.es (MDaemon.PRO.v8.1.4.R) with ESMTP id md50002119875.msg; Tue, 10 Oct 2006 21:32:22 +0200 User-Agent: Microsoft-Entourage/11.2.5.060620 Date: Tue, 10 Oct 2006 14:34:51 -0500 Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) From: JORDI PALET MARTINEZ To: todd glassey , Message-ID: Thread-Topic: [Nea] WG Review: Network Endpoint Assessment (nea) Thread-Index: AcbsoydPZhGUvliWEduo9gANky3PwA== In-Reply-To: <035201c6ec9e$0bf23b50$010aa8c0@home.glassey.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Authenticated-Sender: jordi.palet@consulintel.es X-HashCash: 1:20:061010:ietf@ietf.org::BvI7lR/8fLYKDN4S:0000Grlv X-MDRemoteIP: 192.35.165.61 X-Return-Path: jordi.palet@consulintel.es X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.consulintel.es X-Spam-Status: No, score=-4.7 required=4.7 tests=BAYES_00 autolearn=ham version=3.0.4 X-Spam-Level: X-Spam-Processed: consulintel.es, Tue, 10 Oct 2006 21:32:24 +0200 X-MDAV-Processed: consulintel.es, Tue, 10 Oct 2006 21:32:26 +0200 X-Spam-Score: 0.1 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: "nea@ietf.org" X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Todd, I've received several complains from people that think that you are crossing the limit again and being off-topic with this thread and I seriously agree with them. Consequently I warn you. If you keep going on this, I will apply a new ban (two weeks, as it will be your second one in a very short period of time). Regards, Jordi, acting as IETF Sergeant-at-arms > De: todd glassey > Responder a: > Fecha: Tue, 10 Oct 2006 11:37:49 -0700 > Para: Theodore Tso > CC: "nea@ietf.org" , > Asunto: Re: [Nea] WG Review: Network Endpoint Assessment (nea) > > Hey Ted - the more I thought about this post of yours the more it annoyed > me. You see - when a WG chair doesn't want someone saying something in their > WG and they control the number of players in that WG, they will always > control the consensus such as it is. > > The point is that there is no where to permanently register a dissenting > opinion in an effort or IETF program now that you claim that the charter for > the IETF@IETF.ORG mailing list is restricted. > > The IETF needs IMHO one general list for everything that doesn't fall under > the rubric/charter/umbrella of some WG and their list, and personally after > NETWORK was shutdown I thought that this was it. > > Todd Glassey > > > > ----- Original Message ----- > From: "Theodore Tso" > To: "todd glassey" > Cc: ; > Sent: Monday, October 09, 2006 3:16 PM > Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) > > >> On Mon, Oct 09, 2006 at 02:39:46PM -0700, todd glassey wrote: >>> So then Ted are you formally saying that it is inappropriate to discuss > IETF >>> operations or its processes on the IETF@IETF.ORG mailing list? >> >> If you have a specific and actionable suggestion regarding IETF >> direction, policy, meetings, and procedures, where there is not a more >> appropriate e-mail venue (such as the IPR wg list), then it is >> certainly, appropriate for the IETF list. >> >> Your recent postings, alas, have not met this test. >> >>> The problem with the IPR working group is simply that Harald kicks > people >>> off for disagreeing with him or his very limited charter. He doesn't > want to >>> hear about expanding the charter or how these other issues fit into the > IPR >>> Working Group and in doing so he is violating my and others > participatory >>> rights as well as our First Amendment rights I believe too. >> >> First Amendment rights only apply when the US Government restricts >> speech. It does not apply anywhere else. In general, you have been >> making various legal claims without being a lawyer, and fairly wild >> ones which make it very clear that you don't know what you are talking >> about. For what it's worth, be advised that I know of know legally >> enforceable "right" that you might have towards participating in any >> IETF forum, and certainly if you persist in sounding like someone who >> does not know what they are talking about, no one is required to >> listen to you, either --- and more and more people may in fact decide >> that it is wise for them to exercise their right to ignore you. >> >> Regards, >> >> - Ted > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf ********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 10 16:30:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXOEi-0006vt-J6; Tue, 10 Oct 2006 16:30:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXOEf-0006bE-70; Tue, 10 Oct 2006 16:29:57 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXOEd-000383-TZ; Tue, 10 Oct 2006 16:29:57 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 10 Oct 2006 13:27:30 -0700 X-IronPort-AV: i="4.09,291,1157353200"; d="scan'208"; a="599633159:sNHT34654508" X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Oct 2006 16:29:53 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: WG Review: Network Endpoint Assessment (nea) Thread-index: AcbqbkOTiRjr9dBtSFCoMFOj9yQzUQAjAdggAAjmGFAAJ6TMAAADA84QAAPRyrAAIwMskAAEaIlgAAq7B2A= From: "Stephen Hanna" To: , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: Subject: [Nea] Re: WG Review: Network Endpoint Assessment (nea) X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org I have seen a lot of discussion about whether NEA provides "network protection". In fact, it has been suggested that the charter be revised to say "NEA must not be considered a protection mechanism for networks." I don't agree. Let's start by examining this concept of "network protection". It's an awfully broad concept. No single security technology can provide total protection for a network against all attacks. Instead, a careful threat analysis must be done and layered countermeasures put in place: firewalls, malware scanning, intrusion detection and prevention, strong authentication and authorization, strong encryption for data at rest and in transit, user education, etc. In the context of an overall security program and when combined with other security technologies, NEA can help protect networks. Let me list the ways. First, NEA can help improve the security of cooperating, truthful endpoints. When a cooperating, truthful endpoint connects to the network, its health can be checked and any problems fixed before it can come under attack. This helps protect networks by keeping endpoints healthy so that fewer endpoints become infected and potentially impact the network through port scanning and other misbehavior. The protection provided by NEA alone is not absolute. Healthy endpoints can be vulnerable to a zero day attack. And NEA on its own provides no protection against lying endpoints and no protection against hosts that don't participate in NEA protocols. But it's a lot better than today's situation where some endpoints are completely unprotected with patches or anti-virus software. Second, NEA can be used with technology for detecting lying endpoints. This prevents compromised systems from lying to gain access to the network, thus providing a huge improvement in network security. I recognize that technology for detecting lying endpoints is out of scope for the NEA effort but we shouldn't pretend that it doesn't exist. Without NEA or similar protocols, it will be hard to integrate lying endpoint detection systems into network access control. That's why the NEA BOF in Montreal agreed to include language in the charter saying that "the protocols developed by the NEA WG must be designed to accommodate emerging technologies for identifying and dealing with lying endpoints." Third, endpoints that don't initially participate in NEA protocols can be quarantined for further examination with an external vulnerability scanner or a dynamically downloaded NEA client. Again, this is not part of the proposed NEA WG charter but it is another example of ways that NEA can be used with other security technologies to improve network security. To summarize, the NEA protocols will increase network security on their own. When combined with other technologies, the increase in network security is much greater. But either way it is not accurate to say that NEA is not a protection mechanism for networks. Thanks, Steve _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 10 23:01:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXULh-0000Jk-N8; Tue, 10 Oct 2006 23:01:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXULg-0000By-01; Tue, 10 Oct 2006 23:01:36 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXULd-0004c8-Fr; Tue, 10 Oct 2006 23:01:35 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k9B31Vku007741 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 10 Oct 2006 20:01:32 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k9B31Umi025459; Tue, 10 Oct 2006 20:01:31 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Oct 2006 20:01:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea) Date: Tue, 10 Oct 2006 20:01:29 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Re: WG Review: Network Endpoint Assessment (nea) thread-index: AcbqbkOTiRjr9dBtSFCoMFOj9yQzUQAjAdggAAjmGFAAJ6TMAAADA84QAAPRyrAAIwMskAAEaIlgAAq7B2AABqYvoA== From: "Narayanan, Vidya" To: "Stephen Hanna" , , , X-OriginalArrivalTime: 11 Oct 2006 03:01:30.0431 (UTC) FILETIME=[8D0464F0:01C6ECE1] X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Hi Steve, Let me start with a couple of fundamental points that have already been stated before.=20 A. Any network is exposed to threats from lying endpoints, compromised endpoints and unknown vulnerabilities even on NEA-compliant endpoints.=20 B. A network needs to be protected against such generic threats (as listed in A).=20 I am rather confused by this attempt to make NEA fit into some kind of a network protection mechanism. I keep hearing that NEA is *one* of a suite of protocols that may be used for protecting networks. Let's dig a bit deeper into what a network may employ as protection mechanisms in order to protect against all kinds of general threats.=20 i) Access control mechanisms such as authentication and authorization (to ensure only valid endpoints are allowed on the network) ii) Ingress address filtering to prevent packets with topologically incorrect IP addresses from being injected into the network iii) VPNs to provide remote access to clients iv) Firewalls to provide advanced filtering mechanisms v) IDS/IPS to detect and prevent intrusions=20 vi) Application level filtering where applicable (e.g., detecting and discarding email spam) A combination of the above (or the like) needs to be used to address the general threats mentioned above (in B, for e.g.). Given that, what does NEA bring to the network that isn't already provided by such mechanisms that need to be employed anyway? It is not like we can stop using some of these mechanisms if NEA is present, since the threats that NEA may protect against (from the network perspective) are a small subset of the general threats that a network operator must consider. And, when the general threats are addressed, any subset of those threats are also addressed.=20 The effectiveness of NEA is tied to the type of endpoint (i.e., truthful, compliant endpoints with known vulnerabilities). A network, OTOH, needs mechanisms that protect against all kinds of endpoints. I fail to understand why a particular category of endpoints that NEA addresses is not viewed as a subset of the general category of "all endpoints".=20 Some further comments inline.=20 =20 > -----Original Message----- > From: Stephen Hanna [mailto:shanna@juniper.net]=20 > Sent: Tuesday, October 10, 2006 1:30 PM > To: ietf@ietf.org; nea@ietf.org; iesg@ietf.org > Subject: [Nea] Re: WG Review: Network Endpoint Assessment (nea) >=20 > I have seen a lot of discussion about whether NEA provides=20 > "network protection". In fact, it has been suggested that the=20 > charter be revised to say "NEA must not be considered a=20 > protection mechanism for networks." I don't agree. >=20 > Let's start by examining this concept of "network protection". > It's an awfully broad concept. No single security technology=20 > can provide total protection for a network against all attacks. > Instead, a careful threat analysis must be done and layered=20 > countermeasures put in place: firewalls, malware scanning,=20 > intrusion detection and prevention, strong authentication and=20 > authorization, strong encryption for data at rest and in=20 > transit, user education, etc. >=20 > In the context of an overall security program and when=20 > combined with other security technologies, NEA can help=20 > protect networks. > Let me list the ways. >=20 > First, NEA can help improve the security of cooperating,=20 > truthful endpoints.=20 How is this network protection? As you state above, it is about improving the security of co-operating, truthful *endpoints*.=20 > When a cooperating, truthful endpoint=20 > connects to the network, its health can be checked and any=20 > problems fixed before it can come under attack. This helps=20 > protect networks by keeping endpoints healthy so that fewer=20 > endpoints become infected and potentially impact the network=20 > through port scanning and other misbehavior. >=20 > The protection provided by NEA alone is not absolute. Healthy=20 > endpoints can be vulnerable to a zero day attack. And NEA on=20 > its own provides no protection against lying endpoints and no=20 > protection against hosts that don't participate in NEA=20 > protocols. But it's a lot better than today's situation where=20 > some endpoints are completely unprotected with patches or=20 > anti-virus software. >=20 > Second, NEA can be used with technology for detecting lying=20 > endpoints. This prevents compromised systems from lying to=20 > gain access to the network, thus providing a huge improvement=20 > in network security. >=20 Once again, given that a network operator must really protect against many generic threats, what kind of improvement is NEA bringing to the security of the network?=20 > I recognize that technology for detecting lying endpoints is=20 > out of scope for the NEA effort but we shouldn't pretend that=20 > it doesn't exist. Without NEA or similar protocols, it will=20 > be hard to integrate lying endpoint detection systems into=20 > network access control. That's why the NEA BOF in Montreal=20 > agreed to include language in the charter saying that "the=20 > protocols developed by the NEA WG must be designed to=20 > accommodate emerging technologies for identifying and dealing=20 > with lying endpoints." >=20 > Third, endpoints that don't initially participate in NEA=20 > protocols can be quarantined for further examination with an=20 > external vulnerability scanner or a dynamically downloaded=20 > NEA client. Again, this is not part of the proposed NEA WG=20 > charter but it is another example of ways that NEA can be=20 > used with other security technologies to improve network security. >=20 I'm confused by the above - what is the role of NEA here?=20 > To summarize, the NEA protocols will increase network=20 > security on their own. When combined with other technologies,=20 > the increase in network security is much greater. But either=20 > way it is not accurate to say that NEA is not a protection=20 > mechanism for networks. >=20 I continue to remain puzzled on the above points!=20 Vidya _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Oct 11 05:55:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXaoX-00005h-0R; Wed, 11 Oct 2006 05:55:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXaoW-00005X-6m for nea@ietf.org; Wed, 11 Oct 2006 05:55:48 -0400 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 1GXaoU-0005j6-Ch for nea@ietf.org; Wed, 11 Oct 2006 05:55:48 -0400 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 1GXaoM-0001ms-GI for nea@ietf.org; Wed, 11 Oct 2006 19:55:39 +1000 Received: (qmail 12438 invoked by uid 453); 11 Oct 2006 09:10:41 -0000 Received: from speedy.dhs (HELO speedy) (192.168.0.8) by dhs (qpsmtpd/0.31-dev) with ESMTP; Wed, 11 Oct 2006 19:10:41 +1000 From: "Darryl \(Dassa\) Lynch" To: "'Narayanan, Vidya'" , , Subject: RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea) Date: Wed, 11 Oct 2006 19:55:34 +1000 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: AcbqbkOTiRjr9dBtSFCoMFOj9yQzUQAjAdggAAjmGFAAJ6TMAAADA84QAAPRyrAAIwMskAAEaIlgAAq7B2AABqYvoAAXgiCw In-Reply-To: X-Spam-Score: 0.0 (/) 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: Narayanan, Vidya wrote: >> I continue to remain puzzled on the above points! Hello Vidya Perhaps if I put forward an example of how NEA may benefit me it would go some way to clear the puzzle. [...] Content analysis details: (0.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: 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: Narayanan, Vidya wrote: >> I continue to remain puzzled on the above points! Hello Vidya Perhaps if I put forward an example of how NEA may benefit me it would go some way to clear the puzzle. I run a very closed network, ports are closed and not opened unless there is a validated request, external drives are disabled etc etc. A contractor comes in with a notebook and needs to work on some files located on our internal secure network. A trusted staff member rings in with the request to open a specified port. The port is opened and the contractor hooks up the laptop to it. NEA does it's thing and if the laptop doesn't match the requirements of the internal network policy it is directed to a sandbox network for remediation. If the laptop does meet the policy then it allowed onto the internal network. I have not had to physically interface with the laptop or needed to allow it onto the internal network before some basic checks have been carried out. If the laptop met the policy requirements it was quickly allowed into the internal network and the contractor hasn't had to prove to me their device could be trusted except through automated means using NEA. If I wish, I can run some more checks as the laptop joins the internal network including additional authentication and other hoops to ensure the system hasn't lied through NEA. Really I see NEA as providing additional information to a network administrator so they automate more decisions on the network. In the above situation, if I felt NEA provided all the information I needed I'd leave ports open and be reasonably confident there was little risk in doing so as unknown systems would be directed to the sandbox network if necessary and if a lying system was able to make it to the internal network my normal protection/security measures would catch it out or warn me of the possibility within a reasonable time. Just another tool to give network administrators information and systems they can use to ensure the majority of users get their requirements met in a reasonable and timely manner. Darryl (Dassa) Lynch _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Oct 11 10:19:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXevF-0003cg-1A; Wed, 11 Oct 2006 10:19:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXevD-0003Zi-E5 for nea@ietf.org; Wed, 11 Oct 2006 10:18:59 -0400 Received: from woodstock.binhost.com ([66.150.120.2]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GXevC-00071w-49 for nea@ietf.org; Wed, 11 Oct 2006 10:18:59 -0400 Received: (qmail 29930 invoked by uid 0); 11 Oct 2006 14:18:54 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.126.161.75) by woodstock.binhost.com with SMTP; 11 Oct 2006 14:18:54 -0000 Message-Id: <7.0.0.16.2.20061011101538.06dd9910@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Wed, 11 Oct 2006 10:18:53 -0400 To: "Narayanan, Vidya" From: Russ Housley Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea) 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: d6b246023072368de71562c0ab503126 Cc: nea@ietf.org, iesg@ietf.org, ietf@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Vidya: >I'm not sure that the charter actually needs to get into the modes at >all - I'm guessing what happens after NEA (i.e., what is done with the >results from NEA) has zero impact on any work being done in NEA itself. >So, why not simply state something like "Once NEA is conducted on an >endpoint, the results may be used by an organization in accordance with >any policies of the organization itself."? Discussions with the IAB and IESG prior to external review lead to the addition of the modes discussion. The point is that some networks will demand compliance to grant full access, and other networks will simply notify that host that they are not in compliance. A host my not want to change the configuration to gain compliance. That is acceptable in the second case, but not the first. Russ _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Oct 11 13:27:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXhrA-0008NG-8j; Wed, 11 Oct 2006 13:27:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXgGu-0002zz-0p; Wed, 11 Oct 2006 11:45:28 -0400 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXgGs-0000ra-J1; Wed, 11 Oct 2006 11:45:27 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.8/8.13.8) with ESMTP id k9BFjOZF105074; Wed, 11 Oct 2006 15:45:24 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k9BFlj422851032; Wed, 11 Oct 2006 17:47:45 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k9BFjOU7005138; Wed, 11 Oct 2006 17:45:24 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k9BFjNwM005127; Wed, 11 Oct 2006 17:45:23 +0200 Received: from zurich.ibm.com ([9.4.210.83]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA75114; Wed, 11 Oct 2006 17:45:12 +0200 Message-ID: <452D0946.7080704@zurich.ibm.com> Date: Wed, 11 Oct 2006 17:09:58 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: dassa@dhs.org Subject: Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 X-Mailman-Approved-At: Wed, 11 Oct 2006 13:26:59 -0400 Cc: nea@ietf.org, ietf@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 run a very closed network, ports are closed and not opened unless there is > a validated request, external drives are disabled etc etc. A contractor > comes in with a notebook and needs to work on some files located on our > internal secure network. A trusted staff member rings in with the request > to open a specified port. The port is opened and the contractor hooks up > the laptop to it. NEA does it's thing and if the laptop doesn't match the > requirements of the internal network policy it is directed to a sandbox > network for remediation. If the laptop does meet the policy then it allowed > onto the internal network. What if your contractor has carefully configured the laptop to give all the right answers? What if it has already been infected with a virus that causes it to give all the right answers? The first case is certainly current practice, and the second one could arrive any day. Brian _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Oct 11 13:27:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXhrA-0008No-GU; Wed, 11 Oct 2006 13:27:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXhXA-0005GR-OM; Wed, 11 Oct 2006 13:06:20 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXhX8-000414-C1; Wed, 11 Oct 2006 13:06:20 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k9BH6CQc006685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 11 Oct 2006 10:06:14 -0700 Received: from [10.0.1.4] (vpn-10-50-0-114.qualcomm.com [10.50.0.114]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k9BH67Db020824; Wed, 11 Oct 2006 10:06:10 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 11 Oct 2006 10:06:05 -0700 To: dassa@dhs.org, "'Narayanan, Vidya'" , , From: Ted Hardie Subject: RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea) Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab X-Mailman-Approved-At: Wed, 11 Oct 2006 13:26:59 -0400 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 At 7:55 PM +1000 10/11/06, Darryl \(Dassa\) Lynch wrote: >I run a very closed network, ports are closed and not opened unless there is >a validated request, external drives are disabled etc etc. A contractor >comes in with a notebook and needs to work on some files located on our >internal secure network. A trusted staff member rings in with the request >to open a specified port. The port is opened and the contractor hooks up >the laptop to it. NEA does it's thing and if the laptop doesn't match the >requirements of the internal network policy it is directed to a sandbox >network for remediation. One of the points that has been made here several times is that the rosy promise of a sandbox for remediation has a number of thorns, even in the case where a posture assessment method has identified a potential issue. As it stands, there are commonly multiple ways to work around a vulnerability, including base-levels upgrades (from OS Foo v3 to v4) specific patches (either to the OS or to the application), and, in some cases, configurations (turning off functionality BAR). Assessing those is difficult; offering remediation is trickier yet, especially when one or more of the systems which may need remediation may not even been active at the time of attachment. As I have expressed before, I have serious doubts that the standardized parameters will be sufficient to do any reasonable assessment, and the same carries through in spades for remediation, since that involves a check that none of the remediations has already been applied. Maintaining a valid, *current* set of patches, OS upgrades, and the like for remediation is going to be a very big task; managing the licensing on it a nasty problem; and handling the potential liability of applying the *wrong* remediation a nightmare. Handling unknown states (even for those running recognized assessors) is an even more problematic issue, but you may not care that some folks run development drops of OSes and applications, since you can always remediate them by offering a downgrade. In your example, the contractor presumably also agrees to your mucking with their laptop configuration as part of the contract, but the number of cases in which this is going to be wise is clearly a subset of all cases and it may be a tiny subset. If I came into your network and offered to work with you, my corporate IT folks would be upset if I allowed you to do any of the updates discussed above, so the sandbox is effectively a denial of network access. That's a policy decision you are welcome to make (it's your network), but it's a complex and risky way to make it. I continue to think that the core of this work (passing an opaque string prior to attachment) has some benefits > >Just another tool to give network administrators information and systems >they can use to ensure the majority of users get their requirements met in a >reasonable and timely manner. And I believe others agree with your "tool in the toolkit" view. But if you advertise a saw as a hammer, someone is going to get cut. regards, Ted _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Oct 11 13:31:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXhv6-0001qe-N1; Wed, 11 Oct 2006 13:31:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXhv4-0001nj-4y; Wed, 11 Oct 2006 13:31:02 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXhv1-0007Rx-NJ; Wed, 11 Oct 2006 13:31:02 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k9BHUmQ5001619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 11 Oct 2006 10:30:49 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k9BHUHVl000276; Wed, 11 Oct 2006 10:30:47 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Oct 2006 10:30:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea) Date: Wed, 11 Oct 2006 10:30:24 -0700 Message-ID: In-Reply-To: <200610110953.k9B9rmYt025642@moria.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Re: WG Review: Network Endpoint Assessment (nea) thread-index: AcbqbkOTiRjr9dBtSFCoMFOj9yQzUQAjAdggAAjmGFAAJ6TMAAADA84QAAPRyrAAIwMskAAEaIlgAAq7B2AABqYvoAAXgiCwAA3bEhA= From: "Narayanan, Vidya" To: , , X-OriginalArrivalTime: 11 Oct 2006 17:30:21.0202 (UTC) FILETIME=[ED60C720:01C6ED5A] X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Hi Darryl, Your email indicates that you would:=20 a) somehow require that a visitor's laptop run an NEA client,=20 b) expect the device to support PAs that the server requires to be checked, and=20 c) trust data coming out of it, rather than treat that endpoint as an unknown endpoint and do IDS/IPS in the network.=20 Other than finding this a rather bizzarre trust model, I have to say that there will be a very small set of such endpoints where the owner of that endpoint is going to be thrilled to allow you to place such clients on his/her device and perform updates on it.=20 In short, this is exactly the type of endpoint I wouldn't imagine NEA being useful for!=20 Vidya=20 > -----Original Message----- > From: Darryl (Dassa) Lynch [mailto:dassa@dhs.org]=20 > Sent: Wednesday, October 11, 2006 2:56 AM > To: Narayanan, Vidya; ietf@ietf.org; nea@ietf.org > Subject: RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea) >=20 > Narayanan, Vidya wrote: > > >> I continue to remain puzzled on the above points! >=20 > Hello Vidya >=20 > Perhaps if I put forward an example of how NEA may benefit me=20 > it would go some way to clear the puzzle. >=20 > I run a very closed network, ports are closed and not opened=20 > unless there is a validated request, external drives are=20 > disabled etc etc. A contractor comes in with a notebook and=20 > needs to work on some files located on our internal secure=20 > network. A trusted staff member rings in with the request to=20 > open a specified port. The port is opened and the contractor=20 > hooks up the laptop to it. NEA does it's thing and if the=20 > laptop doesn't match the requirements of the internal network=20 > policy it is directed to a sandbox network for remediation. =20 > If the laptop does meet the policy then it allowed onto the=20 > internal network. I have not had to physically interface=20 > with the laptop or needed to allow it onto the internal=20 > network before some basic checks have been carried out. If=20 > the laptop met the policy requirements it was quickly allowed=20 > into the internal network and the contractor hasn't had to=20 > prove to me their device could be trusted except through=20 > automated means using NEA. If I wish, I can run some more=20 > checks as the laptop joins the internal network including=20 > additional authentication and other hoops to ensure the=20 > system hasn't lied through NEA. >=20 > Really I see NEA as providing additional information to a=20 > network administrator so they automate more decisions on the=20 > network. In the above situation, if I felt NEA provided all=20 > the information I needed I'd leave ports open and be=20 > reasonably confident there was little risk in doing so as=20 > unknown systems would be directed to the sandbox network if=20 > necessary and if a lying system was able to make it to the=20 > internal network my normal protection/security measures would=20 > catch it out or warn me of the possibility within a reasonable time. >=20 > Just another tool to give network administrators information=20 > and systems they can use to ensure the majority of users get=20 > their requirements met in a reasonable and timely manner. >=20 > Darryl (Dassa) Lynch=20 >=20 >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Oct 11 14:00:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXiNs-0000v9-3b; Wed, 11 Oct 2006 14:00:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXiNq-0000uu-My; Wed, 11 Oct 2006 14:00:46 -0400 Received: from elasmtp-banded.atl.sa.earthlink.net ([209.86.89.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXiNo-0006CP-BR; Wed, 11 Oct 2006 14:00:46 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=BZwpV77a2XaAMEc/3k2iqhUrX30W1VWNsfXU/ugxwfUKeXKpdZjwDXobv712GOgP; 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.48.119] (helo=gw) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GXiNB-0001Fr-Ce; Wed, 11 Oct 2006 14:00:06 -0400 Message-ID: <007401c6ed5f$14356f00$7730f604@home.glassey.com> From: "todd glassey" To: "Narayanan, Vidya" , "Russ Housley" References: <7.0.0.16.2.20061011101538.06dd9910@vigilsec.com> Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Date: Wed, 11 Oct 2006 09:51:41 -0700 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: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec7956c5dbc445075a725571a83a1187b364350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.246.48.119 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: nea@ietf.org, iesg@ietf.org, ietf@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 Russ - I agree that something like a global NEA is necessary - just not that a new protocol is necessary to implement it. So let me ask... So then why not pass a new configuration mode model with SNMP - the point is that while the idea of some agent that could actually collect these separate logs and service records from the various 'aspects of compliance' built into the operating models of the system in question, is no new one. Tripwire's does this already. COPS and FREMONT can be made to with CRON and their configuration files. SNORT, AIDE, Heck they can even use SysLogNG as the transport for their log data which might also make sense as an addition... Or SCP/SFTP if they wanted to. The point is that while NEA is a good collective idea at the altitude the idea was hatched at, there are already things that do the NEA component functions today, and that can be aggregated together into a homogeneous utility environment without redesigning the wheel again. I don't dispute that the end goal of what the Creator's of the NEA idea wanted to accomplish is not good. It is clearly. But the issue is whether its necessary to have in the form they have proposed so far when other very similar and more widely deployed transports exist for the Inter-Nodal Communications Model that NEA purports to want to create. Again - SNMP and Syslog/SysLogNG can do allot of this already. Why not just add an Node-Integrity Reporting Process to either of them. From an Audit Perspective this would be a powerful addition to the SysLog protocols since it would better anchor them Just my 35c. Todd Glassey ----- Original Message ----- From: "Russ Housley" To: "Narayanan, Vidya" Cc: ; ; Sent: Wednesday, October 11, 2006 7:18 AM Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea) > Vidya: > > >I'm not sure that the charter actually needs to get into the modes at > >all - I'm guessing what happens after NEA (i.e., what is done with the > >results from NEA) has zero impact on any work being done in NEA itself. > >So, why not simply state something like "Once NEA is conducted on an > >endpoint, the results may be used by an organization in accordance with > >any policies of the organization itself."? > > Discussions with the IAB and IESG prior to external review lead to > the addition of the modes discussion. The point is that some > networks will demand compliance to grant full access, and other > networks will simply notify that host that they are not in > compliance. A host my not want to change the configuration to gain > compliance. That is acceptable in the second case, but not the first. > > Russ > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Oct 11 14:53:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXjD8-0004Cf-8L; Wed, 11 Oct 2006 14:53:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXjD6-0004CT-Cn; Wed, 11 Oct 2006 14:53:44 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXjD5-0002mO-1r; Wed, 11 Oct 2006 14:53:44 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k9BIrfHo022864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 11 Oct 2006 11:53:42 -0700 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k9BIr4UB004811; Wed, 11 Oct 2006 11:53:40 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Oct 2006 11:53:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea) Date: Wed, 11 Oct 2006 11:53:31 -0700 Message-ID: In-Reply-To: <7.0.0.16.2.20061011101538.06dd9910@vigilsec.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] WG Review: Network Endpoint Assessment (nea) thread-index: AcbtQDZIK+VQ+iTITcqACE9O7786NQAGv3MA From: "Narayanan, Vidya" To: "Russ Housley" X-OriginalArrivalTime: 11 Oct 2006 18:53:30.0159 (UTC) FILETIME=[8B0733F0:01C6ED66] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: nea@ietf.org, iesg@ietf.org, ietf@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 Russ,=20 > -----Original Message----- > From: Russ Housley [mailto:housley@vigilsec.com]=20 > Sent: Wednesday, October 11, 2006 7:19 AM > To: Narayanan, Vidya > Cc: nea@ietf.org; iesg@ietf.org; ietf@ietf.org > Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea)=20 >=20 > Vidya: >=20 > >I'm not sure that the charter actually needs to get into the=20 > modes at=20 > >all - I'm guessing what happens after NEA (i.e., what is=20 > done with the=20 > >results from NEA) has zero impact on any work being done in=20 > NEA itself. > >So, why not simply state something like "Once NEA is conducted on an=20 > >endpoint, the results may be used by an organization in=20 > accordance with=20 > >any policies of the organization itself."? >=20 > Discussions with the IAB and IESG prior to external review=20 > lead to the addition of the modes discussion. The point is=20 > that some networks will demand compliance to grant full=20 > access, and other networks will simply notify that host that=20 > they are not in compliance. A host my not want to change the=20 > configuration to gain compliance. That is acceptable in the=20 > second case, but not the first. >=20 I don't disagree with the above. But, I was mainly wondering what impact any of these decisions may have on NEA itself? Aren't these just post-NEA actions?=20 In general though, I have far less problems with this text than I do with the idea of NEA somehow protecting networks or NEA being performed on endpoints that is not owned by the organization performing NEA.=20 Regards, Vidya > Russ >=20 >=20 >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Oct 11 16:16:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXkUk-0006nA-T2; Wed, 11 Oct 2006 16:16:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXkUi-0006kB-U8; Wed, 11 Oct 2006 16:16:00 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXkUg-0002Sx-O1; Wed, 11 Oct 2006 16:16:00 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 11 Oct 2006 13:13:31 -0700 X-IronPort-AV: i="4.09,295,1157353200"; d="scan'208"; a="592836780:sNHT45772752" X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea) Date: Wed, 11 Oct 2006 16:15:56 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Re: WG Review: Network Endpoint Assessment (nea) Thread-index: AcbqbkOTiRjr9dBtSFCoMFOj9yQzUQAjAdggAAjmGFAAJ6TMAAADA84QAAPRyrAAIwMskAAEaIlgAAq7B2AABqYvoAAryiiw From: "Stephen Hanna" To: "Narayanan, Vidya" , , , X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Vidya, Thanks for your response. I think we may be getting closer to understanding each other's perspectives. That's a good thing. Let me respond to your comments inline below. I hope you won't mind if I clip a bit since this thread is starting to get long. Vidya Narayanan wrote: > A. Any network is exposed to threats from lying endpoints, compromised > endpoints and unknown vulnerabilities even on NEA-compliant endpoints. > > B. A network needs to be protected against such generic threats (as > listed in A). Agreed. There are plenty of other threats but that's enough for now. > I am rather confused by this attempt to make NEA fit into some kind of a > network protection mechanism. I keep hearing that NEA is *one* of a > suite of protocols that may be used for protecting networks. Let's dig a > bit deeper into what a network may employ as protection mechanisms in > order to protect against all kinds of general threats.=20 > > i) Access control mechanisms such as authentication and authorization > (to ensure only valid endpoints are allowed on the network) > ii) Ingress address filtering to prevent packets with topologically > incorrect IP addresses from being injected into the network > iii) VPNs to provide remote access to clients > iv) Firewalls to provide advanced filtering mechanisms > v) IDS/IPS to detect and prevent intrusions=20 > vi) Application level filtering where applicable (e.g., detecting and > discarding email spam) > > A combination of the above (or the like) needs to be used to address the > general threats mentioned above (in B, for e.g.). Given that, what does > NEA bring to the network that isn't already provided by such mechanisms > that need to be employed anyway? It is not like we can stop using some > of these mechanisms if NEA is present, since the threats that NEA may > protect against (from the network perspective) are a small subset of the > general threats that a network operator must consider. And, when the > general threats are addressed, any subset of those threats are also > addressed.=20 NEA is another network security tool. Like the others, it has some special advantages but does not remove the need for the others. What does NEA provide that isn't provided by the others? NEA can 1) identify unhealthy endpoints (vulnerable or infected) 2) quarantine unhealthy endpoints before they can infect others or become infected (optionally) 3) repair unhealthy endpoints (optionally) Yes, NEA cannot provide all these functions itself. NEA provides a framework for passing messages about endpoint health. Other security products use that framework to collect, send, and validate specific posture attributes and then to send remediation instructions and/or quarantine unhealthy endpoints. > The effectiveness of NEA is tied to the type of endpoint (i.e., > truthful, compliant endpoints with known vulnerabilities). A network, > OTOH, needs mechanisms that protect against all kinds of endpoints. I > fail to understand why a particular category of endpoints that NEA > addresses is not viewed as a subset of the general category of "all > endpoints".=20 With the aid of technology for detecting lying endpoints, NEA can also handle that class of endpoints. But I agree that NEA will probably never apply to every endpoint on the network. For endpoints that support NEA, the network operator can provide better security. For endpoints that don't support NEA, it will be status quo. > Steve Hanna wrote: > > In the context of an overall security program and when=20 > > combined with other security technologies, NEA can help=20 > > protect networks. > > Let me list the ways. > >=20 > > First, NEA can help improve the security of cooperating,=20 > > truthful endpoints.=20 > > How is this network protection? As you state above, it is about > improving the security of co-operating, truthful *endpoints*.=20 Network security is improved because fewer cooperating, truthful endpoints turn into uncooperative, infected endpoints that then flood the network with attacks. > > Second, NEA can be used with technology for detecting lying=20 > > endpoints. This prevents compromised systems from lying to=20 > > gain access to the network, thus providing a huge improvement=20 > > in network security. > > Once again, given that a network operator must really protect against > many generic threats, what kind of improvement is NEA bringing to the > security of the network?=20 See my comments above. > > Third, endpoints that don't initially participate in NEA=20 > > protocols can be quarantined for further examination with an=20 > > external vulnerability scanner or a dynamically downloaded=20 > > NEA client. Again, this is not part of the proposed NEA WG=20 > > charter but it is another example of ways that NEA can be=20 > > used with other security technologies to improve network security. > > I'm confused by the above - what is the role of NEA here?=20 I'm pointing out that endpoints that don't initially participate in NEA protocols can be quarantined and directed to a web page where they can run a dynamically downloaded NEA client. So this expands the set of endpoints that can be handled by NEA. > I continue to remain puzzled on the above points! I was previously confused by your perspective but I think I now see where you're coming from. I think you want to provide a network that's as secure as possible without having any involvement in how endpoints are configured. That's one valid perspective but it's not the only valid one. Many enterprises want to know about the configuration of endpoints connected to their networks. They may or may not restrict network access for endpoints that don't comply with their policies. Some ISPs want to provide endpoint security services for their customers and therefore want to know about endpoint configuration. Do you now see the value of NEA for these network operators? And maybe you see how NEA can help them make their networks more secure? Thanks, Steve _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Oct 11 16:43:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXkux-0006Ii-23; Wed, 11 Oct 2006 16:43:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXkqW-0002ui-U2; Wed, 11 Oct 2006 16:38:32 -0400 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 1GXkhQ-0003XX-09; Wed, 11 Oct 2006 16:29:09 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 11 Oct 2006 13:29:06 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AY8CANDvLEWMJwEJDio X-IronPort-AV: i="4.09,295,1157353200"; d="scan'208"; a="445530187:sNHT28472080" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9BKT6Ul030261; Wed, 11 Oct 2006 13:29:06 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k9BKT6W4000581; Wed, 11 Oct 2006 13:29:06 -0700 (PDT) Received: from [212.254.247.5] (ams3-vpn-dhcp89.cisco.com [10.61.64.89]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9BKHT0q025099; Wed, 11 Oct 2006 13:17:29 -0700 Message-ID: <452D540F.8050805@cisco.com> Date: Wed, 11 Oct 2006 22:29:03 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Stephen Hanna Subject: Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea) References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-1.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=493; t=1160598546; x=1161462546; c=relaxed/simple; s=sjdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Re=3A=20[Nea]=20Re=3A=20WG=20Review=3A=20Network=20Endpoint=20Assessment =20(nea); X=v=3Dcisco.com=3B=20h=3D21VFERE51ZoLNGJvKF5Kth2rBIo=3D; b=kQCsfKVdHjoykuFGi4IbQDNIxFfRueT4hwB3tVzL+MD+7q8fLERMkXMfiZVIGCAZ9BFGbAP8 7LbTFTXtXT14ixIC4p9Bq8Gha4tSUR1hgrRZ4SC0MsnW75yp2o56J9ye; X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-Mailman-Approved-At: Wed, 11 Oct 2006 16:43:05 -0400 Cc: nea@ietf.org, ietf@ietf.org, iesg@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 In the end, I believe all NEA can do is help good hosts stay good. Bad hosts will stay bad, and may or may not be identifyable as such. Still, the former ain't nothing. But I agree with Ted at least in part that a standardization effort for the content within NEA is challenging. I do not think the licensing issues are quite so severe, however. If people understand the limits of NEA, then the liability should be a solvable problem, but then I'm really so not a lawyer. Eliot _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Oct 11 16:47:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXkzV-0002Sl-60; Wed, 11 Oct 2006 16:47:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXkzT-0002SS-VD for nea@ietf.org; Wed, 11 Oct 2006 16:47:47 -0400 Received: from mailservice.tudelft.nl ([130.161.131.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXkzR-0006nG-Ha for nea@ietf.org; Wed, 11 Oct 2006 16:47:47 -0400 Received: from localhost (localhost [127.0.0.1]) by rav.antivirus (Postfix) with ESMTP id B9972232EA1; Wed, 11 Oct 2006 22:47:42 +0200 (CEST) X-Virus-Scanned: amavisd-new at tudelft.nl X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-99 required=5 tests=[ALL_TRUSTED=-1.8, BAYES_20=-0.74, PROLO_LEO3=0.1] Received: from mailservice.tudelft.nl ([127.0.0.1]) by localhost (mx0.tudelft.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id hjRfu53PUOK5; Wed, 11 Oct 2006 22:47:41 +0200 (CEST) Received: from smtp-a.tudelft.nl (smtp-a.tudelft.nl [130.161.129.18]) by mx2.tudelft.nl (Postfix) with ESMTP id 785CA232E63; Wed, 11 Oct 2006 22:47:41 +0200 (CEST) Received: from [145.94.90.156] (jochemd.tnw-s.tudelft.nl [145.94.90.156]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-a.tudelft.nl (Postfix) with ESMTP id A50C6F1B39; Wed, 11 Oct 2006 22:47:40 +0200 (CEST) Message-ID: <452D586C.8000602@oli.tudelft.nl> Date: Wed, 11 Oct 2006 22:47:40 +0200 From: Jochem van Dieten User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Narayanan, Vidya" Subject: Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea) 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: e1e48a527f609d1be2bc8d8a70eb76cb Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Narayanan, Vidya wrote: > > Your email indicates that you would: > > a) somehow require that a visitor's laptop run an NEA client, > b) expect the device to support PAs that the server requires to be > checked, and > c) trust data coming out of it, > > rather than treat that endpoint as an unknown endpoint and do IDS/IPS in > the network. That is the common practice that hundreds of thousands college and university students are confronted with when they try to connect to the network in to their dorms. > Other than finding this a rather bizzarre trust model, I have to say > that there will be a very small set of such endpoints where the owner of > that endpoint is going to be thrilled to allow you to place such clients > on his/her device and perform updates on it. I fully agree with that. But that the students are not happy about it is not going to stop it. > In short, this is exactly the type of endpoint I wouldn't imagine NEA > being useful for! It is the scenario where I think NEA will be most useful. The desire of network operators to obtain posture information from endpoints is not going to go away just because you and me agree that doing IDS/IPS in the network is a better option. I see a trend in .edu that more and more networks are requiring endpoints to provide posture information. Some roaming users in .edu are already confronted with the situation where the NEA client of their own institution blocks the NEA client of the institution they are visiting. If there is no interoperability of proprietary NEA solutions, that problem is going to grow and get out of control. That is why a standard NEA is useful. Jochem _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Oct 11 16:54:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXl5e-0005Em-Nd; Wed, 11 Oct 2006 16:54:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXl5d-0005Cz-53 for nea@ietf.org; Wed, 11 Oct 2006 16:54:09 -0400 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 1GXl5a-0007Oe-CG for nea@ietf.org; Wed, 11 Oct 2006 16:54:09 -0400 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 1GXl5V-0006Sw-3C for nea@ietf.org; Thu, 12 Oct 2006 06:54:02 +1000 Received: (qmail 18323 invoked by uid 453); 11 Oct 2006 20:08:21 -0000 Received: from speedy.dhs (HELO speedy) (192.168.0.8) by dhs (qpsmtpd/0.31-dev) with ESMTP; Thu, 12 Oct 2006 06:08:20 +1000 From: "Darryl \(Dassa\) Lynch" To: "'Brian E Carpenter'" Subject: RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea) Date: Thu, 12 Oct 2006 06:53:52 +1000 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: AcbtTEeHPJfWr5SoR7iPDZYkHodLugAKdInQ In-Reply-To: <452D0946.7080704@zurich.ibm.com> X-Spam-Score: 0.0 (/) 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: Brian E Carpenter wrote: >>> I run a very closed network, ports are closed and not opened unless >>> there is a validated request, external drives are disabled etc etc. >>> A contractor comes in with a notebook and needs to work on some >>> files located on our internal secure network. A trusted staff >>> member rings in with the request to open a specified port. The >>> port is opened and the contractor hooks up the laptop to it. NEA >>> does it's thing and if the laptop doesn't match the requirements of >>> the internal network policy it is directed to a sandbox network for >>> remediation. If the laptop does meet the policy then it allowed >>> onto the internal network. >> >> What if your contractor has carefully configured the laptop >> to give all the right answers? What if it has already been >> infected with a virus that causes it to give all the right answers? >> >> The first case is certainly current practice, and the second >> one could arrive any day. [...] Content analysis details: (0.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: nea@ietf.org, ietf@ietf.org 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: Brian E Carpenter wrote: >>> I run a very closed network, ports are closed and not opened unless >>> there is a validated request, external drives are disabled etc etc. >>> A contractor comes in with a notebook and needs to work on some >>> files located on our internal secure network. A trusted staff >>> member rings in with the request to open a specified port. The >>> port is opened and the contractor hooks up the laptop to it. NEA >>> does it's thing and if the laptop doesn't match the requirements of >>> the internal network policy it is directed to a sandbox network for >>> remediation. If the laptop does meet the policy then it allowed >>> onto the internal network. >> >> What if your contractor has carefully configured the laptop >> to give all the right answers? What if it has already been >> infected with a virus that causes it to give all the right answers? >> >> The first case is certainly current practice, and the second >> one could arrive any day. Hello Brian I would be monitoring for unusual behaviour on the network and would be warned if the laptop started to behave in ways not expected. NEA would only save time in getting the system onto the network as instead of physically inspecting it I'd be relying on automated means to judge compliance. It would be an acceptable risk. The risk of someone wishing to hack in or being infected with a virus as you describe is low. I'd mainly be using NEA to assist in those situations where the trust isn't total but there isn't harmful intent. If you know of a system that provides total protection, is easy for users to perform their duties and doesn't have me or IT staff doing physical checks I'd be more than willing to look at it. Let's face it, there will always be a risk of someone getting around any informational or protection mechanism put into play, we all have to judge that risk and set up networks accordingly. If we really want to be secure we wouldn't allow any ad hoc connections at all. Darryl (Dassa) Lynch _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Oct 11 17:01:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXlD7-0004J0-9M; Wed, 11 Oct 2006 17:01:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXlD6-0004IS-5L for nea@ietf.org; Wed, 11 Oct 2006 17:01:52 -0400 Received: from woodstock.binhost.com ([66.150.120.2]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GXlD4-0008Gi-UN for nea@ietf.org; Wed, 11 Oct 2006 17:01:52 -0400 Received: (qmail 26360 invoked by uid 0); 11 Oct 2006 21:01:43 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.126.161.75) by woodstock.binhost.com with SMTP; 11 Oct 2006 21:01:43 -0000 Message-Id: <7.0.0.16.2.20061011170048.0709d920@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Wed, 11 Oct 2006 17:01:46 -0400 To: "Narayanan, Vidya" From: Russ Housley Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea) In-Reply-To: References: <7.0.0.16.2.20061011101538.06dd9910@vigilsec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: nea@ietf.org, iesg@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 need to be accommodated. I do not know if there will be an impact on the protocol to ensure that both are accommodated. Russ At 02:53 PM 10/11/2006, Narayanan, Vidya wrote: >Hi Russ, > > > -----Original Message----- > > From: Russ Housley [mailto:housley@vigilsec.com] > > Sent: Wednesday, October 11, 2006 7:19 AM > > To: Narayanan, Vidya > > Cc: nea@ietf.org; iesg@ietf.org; ietf@ietf.org > > Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea) > > > > Vidya: > > > > >I'm not sure that the charter actually needs to get into the > > modes at > > >all - I'm guessing what happens after NEA (i.e., what is > > done with the > > >results from NEA) has zero impact on any work being done in > > NEA itself. > > >So, why not simply state something like "Once NEA is conducted on an > > >endpoint, the results may be used by an organization in > > accordance with > > >any policies of the organization itself."? > > > > Discussions with the IAB and IESG prior to external review > > lead to the addition of the modes discussion. The point is > > that some networks will demand compliance to grant full > > access, and other networks will simply notify that host that > > they are not in compliance. A host my not want to change the > > configuration to gain compliance. That is acceptable in the > > second case, but not the first. > > > >I don't disagree with the above. But, I was mainly wondering what impact >any of these decisions may have on NEA itself? Aren't these just >post-NEA actions? > >In general though, I have far less problems with this text than I do >with the idea of NEA somehow protecting networks or NEA being performed >on endpoints that is not owned by the organization performing NEA. > >Regards, >Vidya > > > Russ > > > > > > _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Oct 11 17:05:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXlGJ-0004o0-Tl; Wed, 11 Oct 2006 17:05:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXlGI-0004np-UI for nea@ietf.org; Wed, 11 Oct 2006 17:05:10 -0400 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 1GXlGF-0000A4-FI for nea@ietf.org; Wed, 11 Oct 2006 17:05:10 -0400 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 1GXlGD-0006ZP-QM for nea@ietf.org; Thu, 12 Oct 2006 07:05:06 +1000 Received: (qmail 18930 invoked by uid 453); 11 Oct 2006 20:19:27 -0000 Received: from speedy.dhs (HELO speedy) (192.168.0.8) by dhs (qpsmtpd/0.31-dev) with ESMTP; Thu, 12 Oct 2006 06:19:27 +1000 From: "Darryl \(Dassa\) Lynch" To: "'Ted Hardie'" , , Subject: RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea) Date: Thu, 12 Oct 2006 07:04:59 +1000 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: AcbtV5EpoWzFVLYpSH6pBijrQy1E6AAICj+A In-Reply-To: X-Spam-Score: 0.0 (/) 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: Hello Ted Comments inline as appropriate. Ted Hardie wrote: >> At 7:55 PM +1000 10/11/06, Darryl \(Dassa\) Lynch wrote: >>> I run a very closed network, ports are closed and not opened unless >>> there is a validated request, external drives are disabled etc etc. >>> A contractor comes in with a notebook and needs to work on some >>> files located on our internal secure network. A trusted staff >>> member rings in with the request to open a specified port. The >>> port is opened and the contractor hooks up the laptop to it. NEA >>> does it's thing and if the laptop doesn't match the requirements of >>> the internal network policy it is directed to a sandbox network for >>> remediation. >> >> One of the points that has been made here several times is >> that the rosy promise of a sandbox for remediation has a >> number of thorns, even in the case where a posture >> assessment method has identified a potential issue. As it >> stands, there are commonly multiple ways to work around a >> vulnerability, including base-levels upgrades (from OS Foo >> v3 to v4) specific patches (either to the OS or to the >> application), and, in some cases, configurations (turning off >> functionality BAR). Assessing those is difficult; offering >> remediation is trickier yet, especially when one or more of the >> systems which may need remediation may not even been active at the >> time of attachment. As I have expressed before, I have serious >> doubts that the standardized parameters will be sufficient to do any >> reasonable assessment, and the same carries through in >> spades for remediation, since that involves a check that >> none of the remediations has already been applied. [...] Content analysis details: (0.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- X-Spam-Score: 0.1 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: 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: Hello Ted Comments inline as appropriate. Ted Hardie wrote: >> At 7:55 PM +1000 10/11/06, Darryl \(Dassa\) Lynch wrote: >>> I run a very closed network, ports are closed and not opened unless >>> there is a validated request, external drives are disabled etc etc. >>> A contractor comes in with a notebook and needs to work on some >>> files located on our internal secure network. A trusted staff >>> member rings in with the request to open a specified port. The >>> port is opened and the contractor hooks up the laptop to it. NEA >>> does it's thing and if the laptop doesn't match the requirements of >>> the internal network policy it is directed to a sandbox network for >>> remediation. >> >> One of the points that has been made here several times is >> that the rosy promise of a sandbox for remediation has a >> number of thorns, even in the case where a posture >> assessment method has identified a potential issue. As it >> stands, there are commonly multiple ways to work around a >> vulnerability, including base-levels upgrades (from OS Foo >> v3 to v4) specific patches (either to the OS or to the >> application), and, in some cases, configurations (turning off >> functionality BAR). Assessing those is difficult; offering >> remediation is trickier yet, especially when one or more of the >> systems which may need remediation may not even been active at the >> time of attachment. As I have expressed before, I have serious >> doubts that the standardized parameters will be sufficient to do any >> reasonable assessment, and the same carries through in >> spades for remediation, since that involves a check that >> none of the remediations has already been applied. Very true, any remediation is difficult. It may be there will be options provided so once a system fails to meet NEA compliance they are offered a number of options instead of remediation, perhaps limited access, no access or intervention by IT staff, all this is beyond the scope of NEA at this stage IMHO. >> Maintaining a valid, *current* set of patches, OS upgrades, >> and the like for remediation is going to be a very big task; >> managing the licensing on it a nasty problem; and handling >> the potential liability of applying the *wrong* remediation >> a nightmare. Handling unknown states (even for those >> running recognized assessors) is an even more problematic >> issue, but you may not care that some folks run development >> drops of OSes and applications, since you can always >> remediate them by offering a downgrade. What is the difference to maintaining the network nodes already on the system. They all have to be maintained and kept in compliance already. NEA just provides some information on what may be needed. >> In your example, the contractor presumably also agrees to >> your mucking with their laptop configuration as part of the >> contract, but the number of cases in which this is going to >> be wise is clearly a subset of all cases and it may be a >> tiny subset. If I came into your network and offered to >> work with you, my corporate IT folks would be upset if I >> allowed you to do any of the updates discussed above, so the >> sandbox is effectively a denial of network access. >> That's a policy decision you are welcome to make (it's your >> network), but it's a complex and risky way to make it. If they don't agree to the network policy then alternatives would need to be available such as providing a trusted system for them to use. Hackers and theives wouldn't agree to abide by any policy in place but that doesn't mean I have to provide methods to make their life easier :). >> I continue to think that the core of this work (passing an >> opaque string prior to attachment) has some benefits I don't disagree. >> >>> >>> Just another tool to give network administrators information and >>> systems they can use to ensure the majority of users get their >>> requirements met in a reasonable and timely manner. >> >> And I believe others agree with your "tool in the toolkit" >> view. But if you advertise a saw as a hammer, someone is going to >> get cut. Most accidents occur in the home. People do have to take some responsibility for themselves. Darryl (Dassa) Lynch _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Oct 11 17:13:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXlOG-00034r-3j; Wed, 11 Oct 2006 17:13:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXlOD-000342-IH for nea@ietf.org; Wed, 11 Oct 2006 17:13:21 -0400 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 1GXlOB-0000nI-Mk for nea@ietf.org; Wed, 11 Oct 2006 17:13:21 -0400 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 1GXlOA-0006dA-5m for nea@ietf.org; Thu, 12 Oct 2006 07:13:18 +1000 Received: (qmail 19460 invoked by uid 453); 11 Oct 2006 20:27:40 -0000 Received: from speedy.dhs (HELO speedy) (192.168.0.8) by dhs (qpsmtpd/0.31-dev) with ESMTP; Thu, 12 Oct 2006 06:27:39 +1000 From: "Darryl \(Dassa\) Lynch" To: "'Narayanan, Vidya'" , , Subject: RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea) Date: Thu, 12 Oct 2006 07:13:13 +1000 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: AcbqbkOTiRjr9dBtSFCoMFOj9yQzUQAjAdggAAjmGFAAJ6TMAAADA84QAAPRyrAAIwMskAAEaIlgAAq7B2AABqYvoAAXgiCwAA3bEhAACiQBUA== In-Reply-To: X-Spam-Score: 0.0 (/) 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: Hi Vidya Comments inline as appropriate. Narayanan, Vidya wrote: [...] Content analysis details: (0.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: 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: Hi Vidya Comments inline as appropriate. Narayanan, Vidya wrote: >> Your email indicates that you would: >> >> a) somehow require that a visitor's laptop run an NEA client, >> b) expect the device to support PAs that the server requires to be >> checked, and c) trust data coming out of it, >> >> rather than treat that endpoint as an unknown endpoint and do >> IDS/IPS in the network. You are limiting my options to a small subset of what I would have available. I may sandbox systems that don't have an NEA client and are unwilling to install one, they would be treated as an unknown node and given very limited access, they wouldn't be allowed onto the trusted network for instance. I would expect some information to be available which I would then be able to check against my policy. I would assume a limited amount of trust but would continue to have other mechanisms in place to be informed where that limited trust has been abused. >> Other than finding this a rather bizzarre trust model, I >> have to say that there will be a very small set of such >> endpoints where the owner of that endpoint is going to be >> thrilled to allow you to place such clients on his/her >> device and perform updates on it. If they wish to join my network they have to abide by the policies I have in place, they don't like it, they don't get to play. >> In short, this is exactly the type of endpoint I wouldn't imagine >> NEA being useful for! NEA is a means to automate the information gathering about this endpoint, if they don't agree to the policies, they will have options to. If a person or device doesn't agree with the policies in place, it doesn't mean I should still provide full access for them. Risk management will dictate what will or will not be allowed. Darryl (Dassa) Lynch _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Oct 11 17:33:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXli6-0004gS-G2; Wed, 11 Oct 2006 17:33:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXli5-0004eA-Mg for nea@ietf.org; Wed, 11 Oct 2006 17:33:53 -0400 Received: from a.mail.sonic.net ([64.142.16.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GXli2-0003KH-9E for nea@ietf.org; Wed, 11 Oct 2006 17:33:53 -0400 Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG [168.61.10.151]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id k9BLXlNG031270 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 11 Oct 2006 14:33:47 -0700 In-Reply-To: <7.0.0.16.2.20061011170048.0709d920@vigilsec.com> References: <7.0.0.16.2.20061011101538.06dd9910@vigilsec.com> <7.0.0.16.2.20061011170048.0709d920@vigilsec.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3261C2B5-50A5-4CA4-968C-4AA6BB9BACE4@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Date: Wed, 11 Oct 2006 14:33:56 -0700 To: Russ Housley 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 Oct 11, 2006, at 2:01 PM, Russ Housley wrote: > Both need to be accommodated. I do not know if there will be an > impact on the protocol to ensure that both are accommodated. > > Russ > > At 02:53 PM 10/11/2006, Narayanan, Vidya wrote: >> Hi Russ, >> >>> Vidya: >>>> >>>> I'm not sure that the charter actually needs to get into the >>>> modes at all - I'm guessing what happens after NEA (i.e., what >>>> is done with the results from NEA) has zero impact on any work >>>> being done in NEA itself. So, why not simply state something >>>> like "Once NEA is conducted on an endpoint, the results may be >>>> used by an organization in accordance with any policies of the >>>> organization itself."? >>> >>> Discussions with the IAB and IESG prior to external review lead >>> to the addition of the modes discussion. The point is that some >>> networks will demand compliance to grant full access, and other >>> networks will simply notify [the] host that they are not in >>> compliance. A host my not want to change the configuration to >>> gain compliance. That is acceptable in the second case, but not >>> the first. >> >> I don't disagree with the above. But, I was mainly wondering what >> impact any of these decisions may have on NEA itself? Aren't these >> just post-NEA actions? >> >> In general though, I have far less problems with this text than I >> do with the idea of NEA somehow protecting networks or NEA being >> performed on endpoints that is not owned by the organization >> performing NEA. The latter mode seems the most interesting. Rather than seeing this as an endpoint auditing or information gathering mechanism, this can also serve as a means to notify endpoints of an "apparent" lack of compliance, where an endpoint must then use a service that provides a "certificate" of compliance. This process may need to be repeated as needed, where remediation may be part of the process. This mechanism could supplement browser redirection as a notification mechanism, especially when the endpoint is not running a browser. -Doug _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Oct 12 00:06:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXrpb-0007iy-II; Thu, 12 Oct 2006 00:06:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GXrpa-0007in-Kg; Thu, 12 Oct 2006 00:06:02 -0400 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 1GXrpY-0005OO-DU; Thu, 12 Oct 2006 00:06:02 -0400 Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id EA8BA16E31; Wed, 11 Oct 2006 23:59:41 -0400 (EDT) From: "Alan DeKok" To: Brian E Carpenter Subject: Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea) In-Reply-To: Your message of "Wed, 11 Oct 2006 17:09:58 +0200." <452D0946.7080704@zurich.ibm.com> Date: Wed, 11 Oct 2006 23:59:41 -0400 Message-Id: <20061012035941.EA8BA16E31@mail.nitros9.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: nea@ietf.org, ietf@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 Brian E Carpenter wrote: > What if your contractor has carefully configured the laptop to > give all the right answers? What if it has already been infected with > a virus that causes it to give all the right answers? Yes, that's a problem with NEA. No, it's not a problem for many (if not most) people using NEA. The people I talk with plan on using NEA to catch the 99% case of a misconfigured/unknown system that is used by a well-meaning but perhaps less clueful employee or contractor. The purpose of NEA is to enhance network security by allowing fewer insecure end hosts in the network. No one can prevent a determined attacker from getting in. But by providing fewer hosts for him to attack, the attacks become less feasibly, and more visible. Alan DeKok. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Oct 12 11:59:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY2xj-0005BR-Pg; Thu, 12 Oct 2006 11:59:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY2xi-0005Az-5h; Thu, 12 Oct 2006 11:59:10 -0400 Received: from a.mail.sonic.net ([64.142.16.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY2xg-0003l3-Pa; Thu, 12 Oct 2006 11:59:10 -0400 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 k9CFx7PN011024 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 12 Oct 2006 08:59:07 -0700 Subject: RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea) From: Douglas Otis To: "Narayanan, Vidya" In-Reply-To: References: Content-Type: text/plain Date: Thu, 12 Oct 2006 08:59:07 -0700 Message-Id: <1160668747.11888.45.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: 2.3 (++) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: nea@ietf.org, ietf@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-10-10 at 20:01 -0700, Narayanan, Vidya wrote: > I am rather confused by this attempt to make NEA fit into some kind of > a network protection mechanism. I keep hearing that NEA is *one* of a > suite of protocols that may be used for protecting networks. Let's dig > a bit deeper into what a network may employ as protection mechanisms > in order to protect against all kinds of general threats. > > i) Access control mechanisms such as authentication and > authorization (to ensure only valid endpoints are allowed on the > network) > > ii) Ingress address filtering to prevent packets with topologically > incorrect IP addresses from being injected into the network > > iii) VPNs to provide remote access to clients > > iv) Firewalls to provide advanced filtering mechanisms > > v) IDS/IPS to detect and prevent intrusions > > vi) Application level filtering where applicable (e.g., detecting and > discarding email spam) If an application happens to be malware, it seems it would be unlikely stop these applications. How about: vi) Provide application level advisory information pertaining to available services. Points that seem to be missing are: vii) Notification of non-compliance. (Perhaps this could become a restatement of i.) viii) Time or sequence sensitive compliance certificates provided following a remediation process or service. Often bad behavior is detected, such as scanning or sending spam which may violate AUPs. These violations may trigger a requirement for the endpoint to use a service that offers remedies the endpoint might use. There could then be a time-sensitive certificate of compliance offered following completion of a check-list and an agreement to comply with the recommendations. Those that remain infected after remediation, or that ignore the AUPs and are again detected, may find this process a reason to correct the situation or their behavior, or the provider may wish to permanently disable the account. -Doug _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Oct 12 17:28:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY865-0000en-Te; Thu, 12 Oct 2006 17:28:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY864-0000eS-S7 for nea@ietf.org; Thu, 12 Oct 2006 17:28:08 -0400 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 1GY863-0004pv-2X for nea@ietf.org; Thu, 12 Oct 2006 17:28:08 -0400 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 1GY85w-0001kJ-MJ for nea@ietf.org; Fri, 13 Oct 2006 07:28:01 +1000 Received: (qmail 11901 invoked by uid 453); 12 Oct 2006 20:40:26 -0000 Received: from speedy.dhs (HELO speedy) (192.168.0.8) by dhs (qpsmtpd/0.31-dev) with ESMTP; Fri, 13 Oct 2006 06:40:25 +1000 From: "Darryl \(Dassa\) Lynch" To: Subject: RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea) Date: Fri, 13 Oct 2006 07:27:53 +1000 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: <1160668747.11888.45.camel@bash.adsl-64-142-13-68> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AcbuGLzAxRci54CpRCW8RBj0aPj6BAAK2JYQ X-Spam-Score: 0.0 (/) 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: Douglas Otis wrote: >> >> If an application happens to be malware, it seems it would >> be unlikely stop these applications. How about: >> >> vi) Provide application level advisory information pertaining to >> available services. >> >> Points that seem to be missing are: >> >> vii) Notification of non-compliance. (Perhaps this could become a >> restatement of i.) >> >> viii) Time or sequence sensitive compliance certificates provided >> following a remediation process or service. >> >> >> Often bad behavior is detected, such as scanning or sending >> spam which may violate AUPs. These violations may trigger a >> requirement for the endpoint to use a service that offers >> remedies the endpoint might use. >> There could then be a time-sensitive certificate of >> compliance offered following completion of a check-list and >> an agreement to comply with the recommendations. >> >> Those that remain infected after remediation, or that ignore >> the AUPs and are again detected, may find this process a >> reason to correct the situation or their behavior, or the >> provider may wish to permanently disable the account. [...] Content analysis details: (0.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ietf@ietf.org 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: Douglas Otis wrote: >> >> If an application happens to be malware, it seems it would >> be unlikely stop these applications. How about: >> >> vi) Provide application level advisory information pertaining to >> available services. >> >> Points that seem to be missing are: >> >> vii) Notification of non-compliance. (Perhaps this could become a >> restatement of i.) >> >> viii) Time or sequence sensitive compliance certificates provided >> following a remediation process or service. >> >> >> Often bad behavior is detected, such as scanning or sending >> spam which may violate AUPs. These violations may trigger a >> requirement for the endpoint to use a service that offers >> remedies the endpoint might use. >> There could then be a time-sensitive certificate of >> compliance offered following completion of a check-list and >> an agreement to comply with the recommendations. >> >> Those that remain infected after remediation, or that ignore >> the AUPs and are again detected, may find this process a >> reason to correct the situation or their behavior, or the >> provider may wish to permanently disable the account. Am I mistaken or is NEA intended to be a compliance check before a node is allowed onto the network? As such, observed behaviour and application abuse would seem to be issues that would be dealt with by other tools. NEA may be used to ensure certain applications are installed and some other characteristics of the node but actual behaviour may not be evident until such time as the node has joined the network and would be beyond the scope of detection by NEA IMHO. NEA may be used to assist in limiting the risk of such behaviour but that is about the extent of it that I see. My reading of the charter gives me the impression NEA is only intended for a specific task and some of what we have been discussing seems to extend well beyond the limited scope proposed. Darryl (Dassa) Lynch _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Oct 12 18:32:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY96o-0006Sm-Vq; Thu, 12 Oct 2006 18:32:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GY96k-0006SB-Og; Thu, 12 Oct 2006 18:32:54 -0400 Received: from e35.co.us.ibm.com ([32.97.110.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GY96i-0001B5-1P; Thu, 12 Oct 2006 18:32:54 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.13.8/8.12.11) with ESMTP id k9CMWppu008764; Thu, 12 Oct 2006 18:32:51 -0400 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 k9CMWpXX536780; Thu, 12 Oct 2006 16:32:51 -0600 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 k9CMWpKr020862; Thu, 12 Oct 2006 16:32:51 -0600 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 k9CMWpoJ020846; Thu, 12 Oct 2006 16:32:51 -0600 In-Reply-To: Subject: RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea) To: dassa@dhs.org X-Mailer: Lotus Notes Release 7.0 HF242 April 21, 2006 Message-ID: From: Frank Yeh Jr Date: Thu, 12 Oct 2006 15:32:47 -0700 X-MIMETrack: Serialize by Router on D03NM129/03/M/IBM(Release 7.0.1HF346 | August 4, 2006) at 10/12/2006 16:32:51 MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d9ae72af46718088458d214998cc683 Cc: nea@ietf.org, ietf@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="===============1930014561==" Errors-To: nea-bounces@ietf.org --===============1930014561== Content-type: multipart/related; Boundary="0__=07BBF896DFE8F6A98f9e8a93df938690918c07BBF896DFE8F6A9" --0__=07BBF896DFE8F6A98f9e8a93df938690918c07BBF896DFE8F6A9 Content-type: multipart/alternative; Boundary="1__=07BBF896DFE8F6A98f9e8a93df938690918c07BBF896DFE8F6A9" --1__=07BBF896DFE8F6A98f9e8a93df938690918c07BBF896DFE8F6A9 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Greetings, Both of the existing flavors of NEA-type protocols (Cisco NAC and= TNC) provide some mechanisms for integrity checking after the admission= process has completed and removing an endpoint's privileged access if i= t falls out of compliance. So IMHO, support for post-admission integrity checking willbe expected in NEA. Collector/Verifier pairs can use NEA for pre-admission integrity checking and some other protocol for post-admission checking but if a post-admission violation is found, there should be a mechanism to termi= nate the user's current admission session and restart the admission process.= Regards, Frank Yeh Corporate Security Strategy Team IBM Tivoli Software = "Darryl \(Dassa\) = Lynch" = = To = 10/12/2006 02:27 = cc PM ietf@ietf.org = Subj= ect RE: [Nea] Re: WG Review: Network= Please respond to Endpoint Assessment (nea) = dassa@dhs.org = = = = = = Douglas Otis wrote: >> >> If an application happens to be malware, it seems it would >> be unlikely stop these applications. How about: >> >> vi) Provide application level advisory information pertaining to >> available services. >> >> Points that seem to be missing are: >> >> vii) Notification of non-compliance. (Perhaps this could become a >> restatement of i.) >> >> viii) Time or sequence sensitive compliance certificates provided >> following a remediation process or service. >> >> >> Often bad behavior is detected, such as scanning or sending >> spam which may violate AUPs. These violations may trigger a >> requirement for the endpoint to use a service that offers >> remedies the endpoint might use. >> There could then be a time-sensitive certificate of >> compliance offered following completion of a check-list and >> an agreement to comply with the recommendations. >> >> Those that remain infected after remediation, or that ignore >> the AUPs and are again detected, may find this process a >> reason to correct the situation or their behavior, or the >> provider may wish to permanently disable the account. Am I mistaken or is NEA intended to be a compliance check before a node= is allowed onto the network? As such, observed behaviour and application abuse would seem to be issues that would be dealt with by other tools. NEA m= ay be used to ensure certain applications are installed and some other characteristics of the node but actual behaviour may not be evident unt= il such time as the node has joined the network and would be beyond the sc= ope of detection by NEA IMHO. NEA may be used to assist in limiting the ri= sk of such behaviour but that is about the extent of it that I see. My reading of the charter gives me the impression NEA is only intended = for a specific task and some of what we have been discussing seems to extend = well beyond the limited scope proposed. Darryl (Dassa) Lynch _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea = --1__=07BBF896DFE8F6A98f9e8a93df938690918c07BBF896DFE8F6A9 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Greetings,

Both of the existing flavors of NEA-type protocols (Cisco NAC and TNC)= provide some mechanisms for integrity checking after the admission pro= cess has completed and removing an endpoint's privileged access if it f= alls out of compliance. So IMHO, support for post-admission integrity c= hecking willbe expected in NEA.

Collector/Verifier pairs can use NEA for pre-admission integrity check= ing and some other protocol for post-admission checking but if a post-a= dmission violation is found, there should be a mechanism to terminate t= he user's current admission session and restart the admission process.<= br>
Regards,
Frank Yeh
Corporate Security Strategy Team
IBM
Tivoli Software

3D"Inactive"Darryl \(Das= sa\) Lynch" <dassa@dhs.org>


=
          "Darryl \(Dassa\) Lynch" <dassa@dh= s.org>

          10/12/2006 02:27 PM
          Please respond to
          dassa@dhs.org

 =
3D=
To
3D""
<nea@ietf.org>
3D=
cc
3D""
ietf@ietf.org
3D=
Subject
3D""
RE: [Nea] Re: WG Review: Network Endpoint Assessment (= nea)
3D=3D""

Douglas Otis wrote:
>>
>> If an application happens to be malware, it seems it would
= >> be unlikely stop these applications.  How about:
>>
>> vi)   Provide application level advisory information pert= aining to  
>> available services.
>>
>> Points that seem to be missing are:
>>
>> vii)  Notification of non-compliance. (Perhaps this could= become a  
>> restatement of i.)
>>
>> viii) Time or sequence sensitive compliance certificates provi= ded
>>       following a remediation process or servic= e.
>>
>>
>> Often bad behavior is detected, such as scanning or sending >> spam which may violate AUPs.  These violations may trigge= r a
>> requirement for the endpoint to use a service that offers
>> remedies the endpoint might use.
>> There could then be a time-sensitive certificate of
>> compliance offered following completion of a check-list and >> an agreement to comply with the recommendations.
>>
>> Those that remain infected after remediation, or that ignore >> the AUPs and are again detected, may find this process a
>> reason to correct the situation or their behavior, or the
>> provider may wish to permanently disable the account.

Am I mistaken or is NEA intended to be a compliance check before a node= is
allowed onto the network?  As such, observed behaviour and applica= tion abuse
would seem to be issues that would be dealt with by other tools.  = NEA may be
used to ensure certain applications are installed and some other
characteristics of the node but actual behaviour may not be evident unt= il
such time as the node has joined the network and would be beyond the sc= ope
of detection by NEA IMHO.  NEA may be used to assist in limiting t= he risk of
such behaviour but that is about the extent of it that I see.

My reading of the charter gives me the impression NEA is only intended = for a
specific task and some of what we have been discussing seems to extend = well
beyond the limited scope proposed.

Darryl (Dassa) Lynch


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

= --1__=07BBF896DFE8F6A98f9e8a93df938690918c07BBF896DFE8F6A9-- --0__=07BBF896DFE8F6A98f9e8a93df938690918c07BBF896DFE8F6A9 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=07BBF896DFE8F6A98f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=07BBF896DFE8F6A98f9e8a93df938690918c07BBF896DFE8F6A9 Content-type: image/gif; name="pic15846.gif" Content-Disposition: inline; filename="pic15846.gif" Content-ID: <2__=07BBF896DFE8F6A98f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33 YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0 2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w 2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw 9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA Ow== --0__=07BBF896DFE8F6A98f9e8a93df938690918c07BBF896DFE8F6A9 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <3__=07BBF896DFE8F6A98f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=07BBF896DFE8F6A98f9e8a93df938690918c07BBF896DFE8F6A9-- --===============1930014561== 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 --===============1930014561==-- From nea-bounces@ietf.org Fri Oct 13 08:55:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYMZ5-0007lS-HC; Fri, 13 Oct 2006 08:55:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYMWI-0004fv-C9; Fri, 13 Oct 2006 08:52:10 -0400 Received: from kalyani.oryx.com ([195.30.37.30]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYMK3-0001oq-E3; Fri, 13 Oct 2006 08:39:35 -0400 Received: from libertango.oryx.com (libertango.oryx.com [195.30.37.9]) by kalyani.oryx.com (Postfix) with ESMTP id CE81C4AD08; Fri, 13 Oct 2006 14:39:11 +0200 (CEST) Message-Id: Date: Fri, 13 Oct 2006 14:40:02 +0200 From: Arnt Gulbrandsen To: ietf@ietf.org Subject: Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea) References: <20061012035941.EA8BA16E31@mail.nitros9.org> In-Reply-To: <20061012035941.EA8BA16E31@mail.nitros9.org> Content-Type: text/plain; format=flowed MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 X-Mailman-Approved-At: Fri, 13 Oct 2006 08:55:02 -0400 Cc: Brian E Carpenter , 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 Alan DeKok writes: > The people I talk with plan on using NEA to catch the 99% case of a > misconfigured/unknown system that is used by a well-meaning but > perhaps less clueful employee or contractor. The purpose of NEA is to > enhance network security by allowing fewer insecure end hosts in the > network. I think the requirements document and/or charter would do well to stress this. Perhaps even exclude the 1% case explicitly. Arnt _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Oct 13 08:57:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYMbt-0000oF-4Y; Fri, 13 Oct 2006 08:57:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYMbr-0000o6-Di; Fri, 13 Oct 2006 08:57:55 -0400 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYMbn-0005ZE-OU; Fri, 13 Oct 2006 08:57:55 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=lIdCygiBnp6yokJxwOjT1SQ/NBuz5kX9CPFMSPSND5EPkevbjN+Mxe39gUmD2OFR; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [4.246.45.140] (helo=gw) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GYMbg-0003gl-TW; Fri, 13 Oct 2006 08:57:47 -0400 Message-ID: <00af01c6eec7$2f325c50$010aa8c0@home.glassey.com> From: "todd glassey" To: , "Frank Yeh Jr" References: Subject: Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea) Date: Fri, 13 Oct 2006 05:56:42 -0700 MIME-Version: 1.0 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: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec790eb9261b0d92e41d09d8e02f24635bd0350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.246.45.140 X-Spam-Score: 0.6 (/) X-Scan-Signature: f4e722e9456ead69ba4cdd21dd3d3600 Cc: nea@ietf.org, ietf@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="===============0517215544==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============0517215544== Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_00A7_01C6EE8C.5BC69190" This is a multi-part message in MIME format. ------=_NextPart_000_00A7_01C6EE8C.5BC69190 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00A8_01C6EE8C.5BC69190" ------=_NextPart_001_00A8_01C6EE8C.5BC69190 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable So then this is an attempt by Cisco and IBM and several others to = qualify a "SOX reporting and compliance tool" - get real. Todd Glassey ----- Original Message -----=20 From: Frank Yeh Jr=20 To: dassa@dhs.org=20 Cc: nea@ietf.org ; ietf@ietf.org=20 Sent: Thursday, October 12, 2006 3:32 PM Subject: RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea) Greetings, Both of the existing flavors of NEA-type protocols (Cisco NAC and TNC) = provide some mechanisms for integrity checking after the admission = process has completed and removing an endpoint's privileged access if it = falls out of compliance. So IMHO, support for post-admission integrity = checking willbe expected in NEA. Collector/Verifier pairs can use NEA for pre-admission integrity = checking and some other protocol for post-admission checking but if a = post-admission violation is found, there should be a mechanism to = terminate the user's current admission session and restart the admission = process. Regards, Frank Yeh Corporate Security Strategy Team IBM Tivoli Software "Darryl \(Dassa\) Lynch" "Darryl \(Dassa\) Lynch" =20 10/12/2006 02:27 PM Please respond to dassa@dhs.org=20 =20 To=20 =20 cc=20 ietf@ietf.org=20 Subject=20 RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea) = =20 =20 Douglas Otis wrote: >>=20 >> If an application happens to be malware, it seems it would >> be unlikely stop these applications. How about: >>=20 >> vi) Provide application level advisory information pertaining to = >> available services.=20 >>=20 >> Points that seem to be missing are: >>=20 >> vii) Notification of non-compliance. (Perhaps this could become a = >> restatement of i.)=20 >>=20 >> viii) Time or sequence sensitive compliance certificates provided >> following a remediation process or service. >>=20 >>=20 >> Often bad behavior is detected, such as scanning or sending >> spam which may violate AUPs. These violations may trigger a >> requirement for the endpoint to use a service that offers >> remedies the endpoint might use. >> There could then be a time-sensitive certificate of >> compliance offered following completion of a check-list and >> an agreement to comply with the recommendations. >>=20 >> Those that remain infected after remediation, or that ignore >> the AUPs and are again detected, may find this process a >> reason to correct the situation or their behavior, or the >> provider may wish to permanently disable the account. Am I mistaken or is NEA intended to be a compliance check before a = node is allowed onto the network? As such, observed behaviour and application = abuse would seem to be issues that would be dealt with by other tools. NEA = may be used to ensure certain applications are installed and some other characteristics of the node but actual behaviour may not be evident = until such time as the node has joined the network and would be beyond the = scope of detection by NEA IMHO. NEA may be used to assist in limiting the = risk of such behaviour but that is about the extent of it that I see. My reading of the charter gives me the impression NEA is only intended = for a specific task and some of what we have been discussing seems to extend = well beyond the limited scope proposed. Darryl (Dassa) Lynch=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea -------------------------------------------------------------------------= ----- _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ------=_NextPart_001_00A8_01C6EE8C.5BC69190 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

So then this is an attempt by Cisco and IBM and = several others=20 to qualify a "SOX reporting and compliance tool" - get = real.
 
Todd Glassey
----- Original Message -----
From:=20 Frank Yeh = Jr
Sent: Thursday, October 12, = 2006 3:32=20 PM
Subject: RE: [Nea] Re: WG = Review: Network=20 Endpoint Assessment (nea)

Greetings,

Both of the existing flavors of NEA-type = protocols (Cisco=20 NAC and TNC) provide some mechanisms for integrity checking after the=20 admission process has completed and removing an endpoint's privileged = access=20 if it falls out of compliance. So IMHO, support for post-admission = integrity=20 checking willbe expected in NEA.

Collector/Verifier pairs can = use NEA=20 for pre-admission integrity checking and some other protocol for=20 post-admission checking but if a post-admission violation is found, = there=20 should be a mechanism to terminate the user's current admission = session and=20 restart the admission process.

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

3D'Inactive'=20 src=3D"cid:00a501c6eec7$081bf3b0$010aa8c0@home.glassey.com" width=3D16 = border=3D0>"Darryl \(Dassa\) Lynch" <dassa@dhs.org>


          "Darryl \(Dassa\) Lynch"=20 <dassa@dhs.org>

          10/12/2006 02:27 PM=20

Please respond=20 = to
dassa@dhs.org

<= /UL>
3D""=20
To
 3D""=20
<nea@ietf.org>
3D""=20
cc
 3D""=20
ietf@ietf.org
3D""=20
Subject
 3D""=20
RE: [Nea] Re: WG Review: = Network=20 Endpoint Assessment (nea)
3D""=20 3D""=20

Do= uglas=20 Otis wrote:
>>
>> If an application happens to be = malware,=20 it seems it would
>> be unlikely stop these applications. =  How=20 about:
>>
>> vi)   Provide application level = advisory=20 information pertaining to  
>> available services. =
>>=20
>> Points that seem to be missing are:
>> =
>> vii)=20  Notification of non-compliance. (Perhaps this could become a=20  
>> restatement of i.)
>>
>> viii) = Time or=20 sequence sensitive compliance certificates provided
>>   =  =20   following a remediation process or service.
>> =
>>=20
>> Often bad behavior is detected, such as scanning or=20 sending
>> spam which may violate AUPs.  These = violations may=20 trigger a
>> requirement for the endpoint to use a service = that=20 offers
>> remedies the endpoint might use.
>> There = could=20 then be a time-sensitive certificate of
>> compliance offered = following completion of a check-list and
>> an agreement to = comply=20 with the recommendations.
>>
>> Those that remain = infected=20 after remediation, or that ignore
>> the AUPs and are again = detected,=20 may find this process a
>> reason to correct the situation or = their=20 behavior, or the
>> provider may wish to permanently disable = the=20 account.

Am I mistaken or is NEA intended to be a compliance = check=20 before a node is
allowed onto the network?  As such, observed=20 behaviour and application abuse
would seem to be issues that would = be dealt=20 with by other tools.  NEA may be
used to ensure certain = applications=20 are installed and some other
characteristics of the node but actual = behaviour may not be evident until
such time as the node has joined = the=20 network and would be beyond the scope
of detection by NEA IMHO. =  NEA=20 may be used to assist in limiting the risk of
such behaviour but = that is=20 about the extent of it that I see.

My reading of the charter = gives me=20 the impression NEA is only intended for a
specific task and some of = what we=20 have been discussing seems to extend well
beyond the limited scope=20 proposed.

Darryl (Dassa) Lynch=20


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

_______________________________________________
Ietf mailing = = list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
<= /BLOCKQUOTE> ------=_NextPart_001_00A8_01C6EE8C.5BC69190-- ------=_NextPart_000_00A7_01C6EE8C.5BC69190 Content-Type: image/gif; name="graycol.gif" Content-Transfer-Encoding: base64 Content-ID: <00a501c6eec7$081bf3b0$010aa8c0@home.glassey.com> R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 ------=_NextPart_000_00A7_01C6EE8C.5BC69190 Content-Type: image/gif; name="ecblank.gif" Content-Transfer-Encoding: base64 Content-ID: <00a601c6eec7$081e64b0$010aa8c0@home.glassey.com> R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 ------=_NextPart_000_00A7_01C6EE8C.5BC69190-- --===============0517215544== 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 --===============0517215544==-- From nea-bounces@ietf.org Fri Oct 13 09:00:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYMeO-0002eR-Sg; Fri, 13 Oct 2006 09:00:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYMeN-0002e9-V1; Fri, 13 Oct 2006 09:00:31 -0400 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYMeM-0006GY-4q; Fri, 13 Oct 2006 09:00:31 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=TugpvK+azNWaFGaBB99ZxnmFGWIX4kf+pOEZxnw7LWj37x10qfwwVdE+rji+vtOA; 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.140] (helo=gw) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GYMeJ-0006LQ-So; Fri, 13 Oct 2006 09:00:28 -0400 Message-ID: <00c401c6eec7$9057bed0$010aa8c0@home.glassey.com> From: "todd glassey" To: "Alan DeKok" , "Brian E Carpenter" References: <20061012035941.EA8BA16E31@mail.nitros9.org> Subject: Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea) Date: Fri, 13 Oct 2006 06:00:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" 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: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79e4819079c436a475c6397b7a6714da38350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.246.45.140 X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: nea@ietf.org, ietf@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 Alan - Do you have any idea what the audit overhead will do to networks in place now? what the overhead of managing and watching a network with NEA are. By the way - how many people with audit certification are involved with NEA? Todd Glassey - CISM, CIFI ----- Original Message ----- From: "Alan DeKok" To: "Brian E Carpenter" Cc: ; Sent: Wednesday, October 11, 2006 8:59 PM Subject: Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea) > Brian E Carpenter wrote: > > What if your contractor has carefully configured the laptop to > > give all the right answers? What if it has already been infected with > > a virus that causes it to give all the right answers? > > Yes, that's a problem with NEA. No, it's not a problem for many (if > not most) people using NEA. > > The people I talk with plan on using NEA to catch the 99% case of a > misconfigured/unknown system that is used by a well-meaning but > perhaps less clueful employee or contractor. The purpose of NEA is to > enhance network security by allowing fewer insecure end hosts in the > network. > > No one can prevent a determined attacker from getting in. But by > providing fewer hosts for him to attack, the attacks become less > feasibly, and more visible. > > Alan DeKok. > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Oct 13 10:05:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYNf7-0002uS-UF; Fri, 13 Oct 2006 10:05:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYN13-0007u9-UM; Fri, 13 Oct 2006 09:23:57 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYN0z-0000hg-En; Fri, 13 Oct 2006 09:23:57 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 75DA7259702; Fri, 13 Oct 2006 15:21:18 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04080-02; Fri, 13 Oct 2006 15:21:11 +0200 (CEST) Received: from [127.0.0.1] (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 92FDE2596FD; Fri, 13 Oct 2006 15:21:11 +0200 (CEST) Message-ID: <452F9361.5070905@alvestrand.no> Date: Fri, 13 Oct 2006 06:23:45 -0700 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.5 (X11/20060719) MIME-Version: 1.0 To: Alan DeKok Subject: Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea) References: <20061012035941.EA8BA16E31@mail.nitros9.org> In-Reply-To: <20061012035941.EA8BA16E31@mail.nitros9.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 X-Mailman-Approved-At: Fri, 13 Oct 2006 10:05:20 -0400 Cc: Brian E Carpenter , nea@ietf.org, ietf@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 A typical NEA case (taken out of what Cisco's NAC is supposed to be good for): - Worker goes on holiday, takes laptop - New attack is discovered that exploits a newly discovered Windows vulnerability - Patch is created, distributed and installed - NEA posture requirement is increased to "must have patch" - Worker comes back, plugs in laptop Without NEA-like functionality: - Worker is admitted - Worker gets attacked & compromised - IDS & other alarms go off - Remediation efforts do what they usually do With NEA: - Worker gets sandboxed - Worker gets upgraded - Worker gets admitted - No compromise, so no remediation No ill intent on the part of any participant (except the attacker). Just a TCO issue. The fact that some fruit is low-hanging doesn't mean it's not worth picking. Harald Alan DeKok wrote: > Brian E Carpenter wrote: > >> What if your contractor has carefully configured the laptop to >> give all the right answers? What if it has already been infected with >> a virus that causes it to give all the right answers? >> > > Yes, that's a problem with NEA. No, it's not a problem for many (if > not most) people using NEA. > > The people I talk with plan on using NEA to catch the 99% case of a > misconfigured/unknown system that is used by a well-meaning but > perhaps less clueful employee or contractor. The purpose of NEA is to > enhance network security by allowing fewer insecure end hosts in the > network. > > No one can prevent a determined attacker from getting in. But by > providing fewer hosts for him to attack, the attacks become less > feasibly, and more visible. > > Alan DeKok. > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > > _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Oct 13 13:40:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYR1Z-0004Wd-Ee; Fri, 13 Oct 2006 13:40:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYR1X-0004TH-0r; Fri, 13 Oct 2006 13:40:43 -0400 Received: from e35.co.us.ibm.com ([32.97.110.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYR1T-0003yO-46; Fri, 13 Oct 2006 13:40:42 -0400 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 k9DHec5Q017274; Fri, 13 Oct 2006 13:40:38 -0400 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 k9DHecw1331162; Fri, 13 Oct 2006 11:40:38 -0600 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 k9DHebTm028039; Fri, 13 Oct 2006 11:40:37 -0600 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 k9DHebgY028011; Fri, 13 Oct 2006 11:40:37 -0600 In-Reply-To: <00af01c6eec7$2f325c50$010aa8c0@home.glassey.com> Subject: Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea) To: "todd glassey" X-Mailer: Lotus Notes Release 7.0 HF242 April 21, 2006 Message-ID: From: Frank Yeh Jr Date: Fri, 13 Oct 2006 10:35:29 -0700 X-MIMETrack: Serialize by Router on D03NM129/03/M/IBM(Release 7.0.1HF346 | August 4, 2006) at 10/13/2006 11:40:37 MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: d437399464e10b52abe9a34ed7e712d0 Cc: nea@ietf.org, ietf@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="===============1260726824==" Errors-To: nea-bounces@ietf.org --===============1260726824== Content-type: multipart/alternative; Boundary="0__=07BBF895DFCD5AEF8f9e8a93df938690918c07BBF895DFCD5AEF" Content-Disposition: inline --0__=07BBF895DFCD5AEF8f9e8a93df938690918c07BBF895DFCD5AEF Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Greetings, "todd glassey" wrote on 10/13/2006 05:56:42 AM= : > So then this is an attempt by Cisco and IBM and several others to > qualify a "SOX reporting and compliance tool" - get real. > > Todd Glassey I'm not sure I follow how you can infer that post-admission statu= s checks are Cisco and IBM's attempt to qualify a "SOX reporting and compliance tool". That's one of the wildest leaps of (il)logic I have s= een. While my comments here do not represent IBM in any official capac= ity I can say that IMHO, a Sox compliance and reporting tool based solely o= n NEA (or Cisco NAC or TNC) would be woefully inadequate. Could the data collected for an NEA posture check be stored as part of an audit trail = and would this data be useful? Absolutely! Does that make this a Sox compli= ance and reporting tool? No way! It would just become another trail of interesting information that would be aggregated in a REAL compliance a= nd reporting tool. One might also consider that the original post concerned post-admission integrity checking as opposed to checking at admission o= nly. The data collected during the admission process would be just as suitab= le for compliance and reporting as post-admission data. So why does the addition of post-admission checking suddenly make this a compliance and= reporting tool? While logic can sometimes be dangerous ("my logic is undeniable")= , I tend to rely on it in the absence of anything better. I don't understan= d the logic behind your statement. Regards, Frank Yeh > ----- Original Message ----- > From: Frank Yeh Jr > To: dassa@dhs.org > Cc: nea@ietf.org ; ietf@ietf.org > Sent: Thursday, October 12, 2006 3:32 PM > Subject: RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea) > > Greetings, > > Both of the existing flavors of NEA-type protocols (Cisco NAC and > TNC) provide some mechanisms for integrity checking after the > admission process has completed and removing an endpoint's > privileged access if it falls out of compliance. So IMHO, support > for post-admission integrity checking willbe expected in NEA. > > Collector/Verifier pairs can use NEA for pre-admission integrity > checking and some other protocol for post-admission checking but if > a post-admission violation is found, there should be a mechanism to > terminate the user's current admission session and restart the > admission process. > > Regards, > Frank Yeh > Corporate Security Strategy Team > IBM > Tivoli Software > > [image removed] "Darryl \(Dassa\) Lynch" > > > "Darryl \(Dassa\) Lynch" > 10/12/2006 02:27 PM > > Please respond to > dassa@dhs.org > > [image removed] > To > > [image removed] > > > [image removed] > cc > > [image removed] > ietf@ietf.org > > [image removed] > Subject > > [image removed] > RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea) > > [image removed] > > [image removed] > > > Douglas Otis wrote: > >> > >> If an application happens to be malware, it seems it would > >> be unlikely stop these applications. How about: > >> > >> vi) Provide application level advisory information pertaining to= > >> available services. > >> > >> Points that seem to be missing are: > >> > >> vii) Notification of non-compliance. (Perhaps this could become a= > >> restatement of i.) > >> > >> viii) Time or sequence sensitive compliance certificates provided > >> following a remediation process or service. > >> > >> > >> Often bad behavior is detected, such as scanning or sending > >> spam which may violate AUPs. These violations may trigger a > >> requirement for the endpoint to use a service that offers > >> remedies the endpoint might use. > >> There could then be a time-sensitive certificate of > >> compliance offered following completion of a check-list and > >> an agreement to comply with the recommendations. > >> > >> Those that remain infected after remediation, or that ignore > >> the AUPs and are again detected, may find this process a > >> reason to correct the situation or their behavior, or the > >> provider may wish to permanently disable the account. > > Am I mistaken or is NEA intended to be a compliance check before a no= de is > allowed onto the network? As such, observed behaviour and applicatio= n abuse > would seem to be issues that would be dealt with by other tools. NEA= may be > used to ensure certain applications are installed and some other > characteristics of the node but actual behaviour may not be evident u= ntil > such time as the node has joined the network and would be beyond the scope > of detection by NEA IMHO. NEA may be used to assist in limiting the = risk of > such behaviour but that is about the extent of it that I see. > > My reading of the charter gives me the impression NEA is only intende= d for a > specific task and some of what we have been discussing seems to exten= d well > beyond the limited scope proposed. > > Darryl (Dassa) Lynch > > > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf= --0__=07BBF895DFCD5AEF8f9e8a93df938690918c07BBF895DFCD5AEF Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Greetings,

"todd glassey" <tglassey@earthlink.net> wrote on 10= /13/2006 05:56:42 AM:

> So then this is an attempt by Cisco and IBM and several others to =
> qualify a "SOX reporting and compliance tool" - get real= .
>  
> Todd Glassey

I'm not sure I follow how you can infer that post-admission status= checks are Cisco and IBM's attempt to qualify a "SOX reporting an= d compliance tool". That's one of the wildest leaps of (il)logic I= have seen.

While my comments here do not represent IBM in any official capaci= ty I can say that IMHO, a Sox compliance and reporting tool based solel= y on NEA (or Cisco NAC or TNC) would be woefully inadequate. Could the = data collected for an NEA posture check be stored as part of an audit t= rail and would this data be useful? Absolutely! Does that make this a S= ox compliance and reporting tool? No way! It would just become another = trail of interesting information that would be aggregated in a REAL com= pliance and reporting tool.

One might also consider that the original post concerned post-admi= ssion integrity checking as opposed to checking at admission only. The = data collected during the admission process would be just as suitable f= or compliance and reporting as post-admission data. So why does the add= ition of post-admission checking suddenly make this a compliance and re= porting tool?

While logic can sometimes be dangerous ("my logic is undeniab= le"), I tend to rely on it in the absence of anything better. I do= n't understand the logic behind your statement.

Regards,
Frank Yeh


> ----- Original Message -----
> From: Frank Yeh Jr
> To: dassa@dhs.org
> Cc: nea@ietf.org ; ietf@ietf.org
> Sent: Thursday, October 12, 2006 3:32 PM
> Subject: RE: [Nea] Re: WG Review: Network Endpoint Assessment = (nea)
>
> Greetings,
>
> Both of the existing flavors of NEA-type protocols (Cisco NAC and =
> TNC) provide some mechanisms for integrity checking after the
= > admission process has completed and removing an endpoint's
> privileged access if it falls out of compliance. So IMHO, support =
> for post-admission integrity checking willbe expected in NEA.
>
> Collector/Verifier pairs can use NEA for pre-admission integrity <= br> > checking and some other protocol for post-admission checking but i= f
> a post-admission violation is found, there should be a mechanism t= o
> terminate the user's current admission session and restart the > admission process.
>
> Regards,
> Frank Yeh
> Corporate Security Strategy Team
> IBM
> Tivoli Software
>
> [image removed] "Darryl \(Dassa\) Lynch" <dassa@dhs.o= rg>
>

>
> "Darryl \(Dassa\) Lynch" <dassa@dhs.org>
= > 10/12/2006 02:27 PM
>
> Please respond to
> dassa@dhs.org
>
> [image removed]
> To
>
> [image removed]
> <nea@ietf.org>
>
> [image removed]
> cc
>
> [image removed]
> ietf@ietf.org
>
> [image removed]
> Subject
>
> [image removed]
> RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea) >
> [image removed]
>
> [image removed]
>
>
> Douglas Otis wrote:
> >>
> >> If an application happens to be malware, it seems it woul= d
> >> be unlikely stop these applications.  How about:
= > >>
> >> vi)   Provide application level advisory information= pertaining to  
> >> available services.
> >>
> >> Points that seem to be missing are:
> >>
> >> vii)  Notification of non-compliance. (Perhaps this = could become a  
> >> restatement of i.)
> >>
> >> viii) Time or sequence sensitive compliance certificates = provided
> >>       following a remediation process or s= ervice.
> >>
> >>
> >> Often bad behavior is detected, such as scanning or sendi= ng
> >> spam which may violate AUPs.  These violations may t= rigger a
> >> requirement for the endpoint to use a service that offers=
> >> remedies the endpoint might use.
> >> There could then be a time-sensitive certificate of
> >> compliance offered following completion of a check-list a= nd
> >> an agreement to comply with the recommendations.
> >>
> >> Those that remain infected after remediation, or that ign= ore
> >> the AUPs and are again detected, may find this process a<= br> > >> reason to correct the situation or their behavior, or the=
> >> provider may wish to permanently disable the account.
= >
> Am I mistaken or is NEA intended to be a compliance check before a= node is
> allowed onto the network?  As such, observed behaviour and ap= plication abuse
> would seem to be issues that would be dealt with by other tools. &= nbsp;NEA may be
> used to ensure certain applications are installed and some other > characteristics of the node but actual behaviour may not be eviden= t until
> such time as the node has joined the network and would be beyond t= he scope
> of detection by NEA IMHO.  NEA may be used to assist in limit= ing the risk of
> such behaviour but that is about the extent of it that I see.
>
> My reading of the charter gives me the impression NEA is only inte= nded for a
> specific task and some of what we have been discussing seems to ex= tend well
> beyond the limited scope proposed.
>
> Darryl (Dassa) Lynch
>
>
> _______________________________________________
> Nea mailing list
> Nea@ietf.org
> https://www= 1.ietf.org/mailman/listinfo/nea

>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://ww= w1.ietf.org/mailman/listinfo/ietf= --0__=07BBF895DFCD5AEF8f9e8a93df938690918c07BBF895DFCD5AEF-- --===============1260726824== 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 --===============1260726824==-- From nea-bounces@ietf.org Fri Oct 13 16:37:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYTmP-0007O2-Kj; Fri, 13 Oct 2006 16:37:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYSwE-00020e-4d; Fri, 13 Oct 2006 15:43:22 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYSwB-0000uL-SD; Fri, 13 Oct 2006 15:43:22 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id B6B81E0127; Fri, 13 Oct 2006 15:43:11 -0400 (EDT) From: Sam Hartman To: Frank Yeh Jr Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) References: Date: Fri, 13 Oct 2006 15:43:11 -0400 In-Reply-To: (Frank Yeh, Jr.'s message of "Mon, 9 Oct 2006 10:41:51 -0700") 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: d6b246023072368de71562c0ab503126 X-Mailman-Approved-At: Fri, 13 Oct 2006 16:37:16 -0400 Cc: Ted Hardie , nea@ietf.org, ietf@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 >>>>> "Frank" == Frank Yeh writes: Frank> Standardized VS vendor-specific attributes is not something that needs to be Frank> solved today. Solutions can start with vendor-specific and migrate toward a Frank> standard, if one develops, without changing the protocol. The specification Frank> should not preclude the addition of standardized attributes. IE the Frank> specification is like an alphabet, attributes are like vocabulary. You can add Frank> new words without changing the letters. One of the things coming out of the most recent BOF was a strong desire for PA-level interoperability. That can be accomplished through standardized attributes or vendor-specific attributes that are sufficiently well documented (and not subject to patents) that third parties can implement collectors or analysis tools that interoperate with the vendor tools for the vendor attributes. Will we be able to meet these interoperability goals? Why or why not? _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Oct 16 04:46:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZO7M-0004oY-Dh; Mon, 16 Oct 2006 04:46:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZO7J-0004mb-Ht; Mon, 16 Oct 2006 04:46:37 -0400 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZO7D-0005zj-3Z; Mon, 16 Oct 2006 04:46:37 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 344393C2B7; Mon, 16 Oct 2006 10:46:20 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 28671-01-73; Mon, 16 Oct 2006 10:46:19 +0200 (CEST) Received: from [150.214.58.216] (unknown [150.214.58.216]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 0A2A53C2AE; Mon, 16 Oct 2006 10:46:18 +0200 (CEST) Message-ID: <453346D8.30309@it.su.se> Date: Mon, 16 Oct 2006 10:46:16 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Lakshminath Dondeti Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) References: <4527685D.1090904@alvestrand.no> <7.0.1.0.2.20061007100953.059f1120@qualcomm.com> In-Reply-To: <7.0.1.0.2.20061007100953.059f1120@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.665 tagged_above=-99 required=7 tests=[BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Harald Alvestrand , nea@ietf.org, iesg@ietf.org, ietf@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 Lakshminath Dondeti wrote: > At 01:42 AM 10/7/2006, Harald Alvestrand wrote: >>> >> Many universities require their students to buy their own laptops, >> but prohibit certain types of activity from those laptops (like >> spamming, DDOS-attacks and the like). They would love to have the >> ability to run some kind of NEA procedure to ensure that laptops are >> reasonably virus-free and free from known vulnerabilities, and are >> important enough in their students' lives that they can probably >> enforce it without a complaint about "violation of privacy". >> >> Just pointing out that there's one use case with user-managed >> endpoints where NEA is not obviously a bad idea. > > My email ventures into a bit of non-IETF territory, but we are > discussing use cases, and so I guess it's on topic. Universities > should be the last places to try antics like NEA. Whereas an > operational network would be a priority to them, it is also important > that they allow students to experiment with new applications. If we > are believing that general purpose computing will be taken away from > college students, we are indeed talking about a different world. > > In any event, the bottomline is NEA as a solution to "network > protection" is a leaky bucket at best. > > NEA at best *may* raise the bar in attacking a "closed" network where > endpoints are owned and tightly controlled by the organization that > owns the network. > Lets not forget that when (not if) NEA/NAP/NAC is deployed the IDSen people have deployed today to solve the lying-client-problem by scanning for common/current vulnerabilities as part of the network admission process will have to interface with PDPs part of a NEA intfrastructure. Cheers Leif _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Oct 16 05:01:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZOLZ-0004Ay-5x; Mon, 16 Oct 2006 05:01:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZOLX-0004Ag-Bb; Mon, 16 Oct 2006 05:01:19 -0400 Received: from smtp1.su.se ([130.237.162.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZOLW-000152-2a; Mon, 16 Oct 2006 05:01:19 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id 328C5744B5; Mon, 16 Oct 2006 11:01:03 +0200 (CEST) Received: from smtp1.su.se ([127.0.0.1]) by localhost (smtp1.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 16410-01-19; Mon, 16 Oct 2006 11:01:02 +0200 (CEST) Received: from [150.214.58.216] (unknown [150.214.58.216]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp1.su.se (Postfix) with ESMTP id 044C07449E; Mon, 16 Oct 2006 11:01:01 +0200 (CEST) Message-ID: <45334A4B.6090601@it.su.se> Date: Mon, 16 Oct 2006 11:00:59 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Narayanan, Vidya" Subject: Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.665 tagged_above=-99 required=7 tests=[BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: nea@ietf.org, ietf@ietf.org, iesg@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 Extreme clipping below: > v) IDS/IPS to detect and prevent intrusions > > NEA might help here by providing a common semantics for communicating the result of IDS scans of hosts to policy decision points. Cheers Leif _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Oct 16 06:16:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZPWL-0001uR-Qv; Mon, 16 Oct 2006 06:16:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZPWL-0001uG-6g; Mon, 16 Oct 2006 06:16:33 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZPWJ-0005Q1-RW; Mon, 16 Oct 2006 06:16:33 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k9GAGQan022996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 16 Oct 2006 03:16:27 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-64-191.qualcomm.com [10.50.64.191]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k9GAGHKF009438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Oct 2006 03:16:21 -0700 (PDT) Message-Id: <7.0.1.0.2.20061016031319.04880dd0@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Mon, 16 Oct 2006 03:16:10 -0700 To: Leif Johansson From: Lakshminath Dondeti Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) In-Reply-To: <453346D8.30309@it.su.se> References: <4527685D.1090904@alvestrand.no> <7.0.1.0.2.20061007100953.059f1120@qualcomm.com> <453346D8.30309@it.su.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Harald Alvestrand , nea@ietf.org, iesg@ietf.org, ietf@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 01:46 AM 10/16/2006, Leif Johansson wrote: >Lakshminath Dondeti wrote: > > At 01:42 AM 10/7/2006, Harald Alvestrand wrote: > >>> > >> Many universities require their students to buy their own laptops, > >> but prohibit certain types of activity from those laptops (like > >> spamming, DDOS-attacks and the like). They would love to have the > >> ability to run some kind of NEA procedure to ensure that laptops are > >> reasonably virus-free and free from known vulnerabilities, and are > >> important enough in their students' lives that they can probably > >> enforce it without a complaint about "violation of privacy". > >> > >> Just pointing out that there's one use case with user-managed > >> endpoints where NEA is not obviously a bad idea. > > > > My email ventures into a bit of non-IETF territory, but we are > > discussing use cases, and so I guess it's on topic. Universities > > should be the last places to try antics like NEA. Whereas an > > operational network would be a priority to them, it is also important > > that they allow students to experiment with new applications. If we > > are believing that general purpose computing will be taken away from > > college students, we are indeed talking about a different world. > > > > In any event, the bottomline is NEA as a solution to "network > > protection" is a leaky bucket at best. > > > > NEA at best *may* raise the bar in attacking a "closed" network where > > endpoints are owned and tightly controlled by the organization that > > owns the network. > > >Lets not forget that when (not if) NEA/NAP/NAC is deployed the IDSen >people have deployed today to >solve the lying-client-problem by scanning for common/current >vulnerabilities as part of the network admission >process will have to interface with PDPs part of a NEA intfrastructure. Could you rephrase please? I am afraid I don't understand what you are saying. Oh, and lying endpoint problem cannot be solved by scanning for common vulnerabilities! In fact, the two have no relation whatsoever. Lakshminath > Cheers Leif _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Oct 16 08:32:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZRdU-0000Z7-HF; Mon, 16 Oct 2006 08:32:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GYmGi-0000hF-Lo for nea@ietf.org; Sat, 14 Oct 2006 12:21:48 -0400 Received: from omr9.networksolutionsemail.com ([205.178.146.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GYmGh-0002OJ-DE for nea@ietf.org; Sat, 14 Oct 2006 12:21:48 -0400 Received: from mail.networksolutionsemail.com (ns-omr9.mgt.hosting.dc2.netsol.com [10.49.6.72]) by omr9.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k9EGLjRr006814 for ; Sat, 14 Oct 2006 12:21:45 -0400 Received: (qmail 15326 invoked by uid 78); 14 Oct 2006 16:21:45 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@70.40.54.192) by ns-omr9.lb.hosting.dc2.netsol.com with SMTP; 14 Oct 2006 16:21:45 -0000 Message-ID: <45310E92.7000203@andybierman.com> Date: Sat, 14 Oct 2006 09:21:38 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Harald Alvestrand Subject: Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea) References: <20061012035941.EA8BA16E31@mail.nitros9.org> <452F9361.5070905@alvestrand.no> In-Reply-To: <452F9361.5070905@alvestrand.no> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 X-Mailman-Approved-At: Mon, 16 Oct 2006 08:32:03 -0400 Cc: nea@ietf.org, ietf@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 Harald Alvestrand wrote: > A typical NEA case (taken out of what Cisco's NAC is supposed to be good > for): > > - Worker goes on holiday, takes laptop > - New attack is discovered that exploits a newly discovered Windows > vulnerability > - Patch is created, distributed and installed > - NEA posture requirement is increased to "must have patch" > - Worker comes back, plugs in laptop > > Without NEA-like functionality: > - Worker is admitted > - Worker gets attacked & compromised > - IDS & other alarms go off > - Remediation efforts do what they usually do > > With NEA: > - Worker gets sandboxed > - Worker gets upgraded > - Worker gets admitted > - No compromise, so no remediation > > No ill intent on the part of any participant (except the attacker). Just > a TCO issue. > > The fact that some fruit is low-hanging doesn't mean it's not worth > picking. I don't agree that this is low-hanging fruit. The server component of this system seems like a wonderful new target for DDoS and masquerade attacks. > > Harald Andy > > > Alan DeKok wrote: >> Brian E Carpenter wrote: >> >>> What if your contractor has carefully configured the laptop to >>> give all the right answers? What if it has already been infected with >>> a virus that causes it to give all the right answers? >>> >> >> Yes, that's a problem with NEA. No, it's not a problem for many (if >> not most) people using NEA. >> >> The people I talk with plan on using NEA to catch the 99% case of a >> misconfigured/unknown system that is used by a well-meaning but >> perhaps less clueful employee or contractor. The purpose of NEA is to >> enhance network security by allowing fewer insecure end hosts in the >> network. >> >> No one can prevent a determined attacker from getting in. But by >> providing fewer hosts for him to attack, the attacks become less >> feasibly, and more visible. >> >> Alan DeKok. >> >> _______________________________________________ >> Ietf mailing list >> Ietf@ietf.org >> https://www1.ietf.org/mailman/listinfo/ietf >> >> > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > > _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Oct 16 08:32:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZRdV-0000hD-M0; Mon, 16 Oct 2006 08:32:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZLgL-0000Qb-Gm; Mon, 16 Oct 2006 02:10:37 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZLgK-0005tU-7P; Mon, 16 Oct 2006 02:10:37 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 15 Oct 2006 23:10:35 -0700 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 k9G6AZjt017463; Sun, 15 Oct 2006 23:10:35 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9G6AYAo021591; Sun, 15 Oct 2006 23:10:34 -0700 (PDT) Received: from [212.254.247.5] (ams3-vpn-dhcp100.cisco.com [10.61.64.100]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9G5wfob006335; Sun, 15 Oct 2006 22:58:42 -0700 Message-ID: <45332258.4010200@cisco.com> Date: Mon, 16 Oct 2006 08:10:32 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Andy Bierman Subject: Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea) References: <20061012035941.EA8BA16E31@mail.nitros9.org> <452F9361.5070905@alvestrand.no> <45310E92.7000203@andybierman.com> In-Reply-To: <45310E92.7000203@andybierman.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-2.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=1100; t=1160979035; x=1161843035; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Re=3A=20[Nea]=20Re=3A=20WG=20Review=3A=20Network=20Endpoint=20Assessment =20(nea); X=v=3Dcisco.com=3B=20h=3D21VFERE51ZoLNGJvKF5Kth2rBIo=3D; b=FT3Frnd1dfBFKLcAJjChD4y1w/zKqN5Q7y0ULPeMZ1MDTiqQiKrYl2EaTmHOeA8ok113XVFs Z81VL4xf+OXETXkOPJxkaHR/VYVxE3ykZkTtoAGngl0KS/WTU+KEw+IY; X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-Mailman-Approved-At: Mon, 16 Oct 2006 08:32:03 -0400 Cc: Harald Alvestrand , nea@ietf.org, IETF Discussion 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 Andy Bierman wrote: > I don't agree that this is low-hanging fruit. > The server component of this system seems like a wonderful > new target for DDoS and masquerade attacks. Well, first of all I don't see why this is any different than a radius server. In fact it could be that the access box forwards information in a very similar way. But let's say that it doesn't work that way just for yucks. Another approach is that the clients themselves must have a server on them and the queries go the other way. In this case the server need only check either a source address or a transaction ID. Furthermore, there is no reason for clients outside of that AS to have access to that server, so it's a good candidate for an ACL. Of course this creates a risk of attack on the clients themselves, which brings me to one of my greater concerns: In many of the mechanisms that communicate between client and network we are not finding good ways to prove the legitimacy of the service to the client. This is an area that perhaps it would be good to get the IRTF to work on. Eliot _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Oct 16 10:05:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZT5r-0002Jp-4f; Mon, 16 Oct 2006 10:05:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZSam-0002M4-UK for nea@ietf.org; Mon, 16 Oct 2006 09:33:20 -0400 Received: from omr1.networksolutionsemail.com ([205.178.146.51]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZSak-0004ci-N6 for nea@ietf.org; Mon, 16 Oct 2006 09:33:20 -0400 Received: from mail.networksolutionsemail.com (ns-omr1.mgt.netsol.com [10.49.6.64]) by omr1.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id k9GDXHA7018410 for ; Mon, 16 Oct 2006 09:33:18 -0400 Received: (qmail 4394 invoked by uid 78); 16 Oct 2006 13:33:17 -0000 Received: from unknown (HELO ?192.168.0.12?) (andy@andybierman.com@70.40.54.192) by ns-omr1.lb.hosting.dc2.netsol.com with SMTP; 16 Oct 2006 13:33:17 -0000 Message-ID: <45338A17.6040700@andybierman.com> Date: Mon, 16 Oct 2006 06:33:11 -0700 From: Andy Bierman User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Eliot Lear Subject: Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea) References: <20061012035941.EA8BA16E31@mail.nitros9.org> <452F9361.5070905@alvestrand.no> <45310E92.7000203@andybierman.com> <45332258.4010200@cisco.com> In-Reply-To: <45332258.4010200@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 X-Mailman-Approved-At: Mon, 16 Oct 2006 10:05:26 -0400 Cc: Harald Alvestrand , nea@ietf.org, IETF Discussion 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 Eliot Lear wrote: > Andy Bierman wrote: >> I don't agree that this is low-hanging fruit. >> The server component of this system seems like a wonderful >> new target for DDoS and masquerade attacks. > Well, first of all I don't see why this is any different than a radius > server. In fact it could be that the access box forwards information in > a very similar way. But let's say that it doesn't work that way just > for yucks. Another approach is that the clients themselves must have a > server on them and the queries go the other way. In this case the > server need only check either a source address or a transaction ID. > Furthermore, there is no reason for clients outside of that AS to have > access to that server, so it's a good candidate for an ACL. Of course > this creates a risk of attack on the clients themselves, which brings me > to one of my greater concerns: > > In many of the mechanisms that communicate between client and network we > are not finding good ways to prove the legitimacy of the service to the > client. This is an area that perhaps it would be good to get the IRTF > to work on. > My comment was on Harald's characterization of this work effort as 'low hanging fruit'. IMO, that term is reserved for huge gains for very little effort. I don't think that is the case here. > Eliot > Andy _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Oct 16 20:06:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZcTB-0006kh-FS; Mon, 16 Oct 2006 20:06:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZcTA-0006kV-I6; Mon, 16 Oct 2006 20:06:08 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZcT8-0007sn-65; Mon, 16 Oct 2006 20:06:08 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k9H063TL024794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 16 Oct 2006 17:06:04 -0700 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k9H061S3005092; Mon, 16 Oct 2006 17:06:02 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Oct 2006 17:06:00 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea) Date: Mon, 16 Oct 2006 17:06:02 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] WG Review: Network Endpoint Assessment (nea) Thread-Index: AcbvAGai8Lr4TLgARk+68FBGr5Ot/ACMUjnQ From: "Narayanan, Vidya" To: "Sam Hartman" , "Frank Yeh Jr" X-OriginalArrivalTime: 17 Oct 2006 00:06:00.0999 (UTC) FILETIME=[07771370:01C6F180] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: "Hardie, Ted" , nea@ietf.org, ietf@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 Sam,=20 > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu]=20 > Sent: Friday, October 13, 2006 12:43 PM > To: Frank Yeh Jr > Cc: Hardie, Ted; nea@ietf.org; ietf@ietf.org > Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) >=20 > >>>>> "Frank" =3D=3D Frank Yeh writes: >=20 > Frank> Standardized VS vendor-specific attributes is not=20 > something that needs to be > Frank> solved today. Solutions can start with=20 > vendor-specific and migrate toward a > Frank> standard, if one develops, without changing the=20 > protocol. The specification > Frank> should not preclude the addition of standardized=20 > attributes. IE the > Frank> specification is like an alphabet, attributes are=20 > like vocabulary. You can add > Frank> new words without changing the letters. >=20 >=20 > One of the things coming out of the most recent BOF was a=20 > strong desire for PA-level interoperability. That can be=20 > accomplished through standardized attributes or=20 > vendor-specific attributes that are sufficiently well=20 > documented (and not subject to patents) that third parties=20 > can implement collectors or analysis tools that interoperate=20 > with the vendor tools for the vendor attributes. >=20 > Will we be able to meet these interoperability goals? Why or why not? >=20 I am very apprehensive of achieving any meaningful PA-level interoperability. I am not sure what minimum set of PA attributes will be standardized, but, whatever that set is, I doubt will be sufficient to provide any acceptable level of security, even for the endpoints. Even assuming ongoing standardization of vendor specific attributes, it is not totally realistic to assume that all applications will support the appropriate attributes. The rate of standardization is also very likely to be much slower than the rate of the growth in the number of attributes needed for any continued meaningful protection.=20 Regards, Vidya _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Oct 16 20:39:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZczn-0000Ee-IK; Mon, 16 Oct 2006 20:39:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZczk-0008Lh-Vp; Mon, 16 Oct 2006 20:39:49 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZczj-0004pN-HP; Mon, 16 Oct 2006 20:39:48 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k9H0d28P005127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 16 Oct 2006 17:39:03 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k9H0bZnJ026960; Mon, 16 Oct 2006 17:38:47 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Oct 2006 17:37:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea) Date: Mon, 16 Oct 2006 17:37:34 -0700 Message-ID: In-Reply-To: <452F9361.5070905@alvestrand.no> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Re: WG Review: Network Endpoint Assessment (nea) Thread-Index: Acbuy5ry0H8NSnYvS0aZqpTnvLKEUACtoIPg From: "Narayanan, Vidya" To: "Harald Alvestrand" , "Alan DeKok" X-OriginalArrivalTime: 17 Oct 2006 00:37:34.0330 (UTC) FILETIME=[6FFA75A0:01C6F184] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: nea@ietf.org, ietf@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 Harald, This seems to be missing the point. I think there is a general sense that NEA could be helpful for some level of protection to complying endpoints in an enterprise scenario, which is exactly what you have described below. The disagreement seems to be on the topics of what NEA does for the network and whether it makes any sense in the provider model where the network and end device owners are different.=20 On the network protection issue, I still have not seen anything that NEA provides that is not provided (in a better manner) by protection mechanisms that the network must use to protect itself against any unknown vulnerabilities and compromised endpoints. Everything that has been said still seems to be a subset of that larger threat which must be protected against anyway. Having said that, the use of NEA for the provider model doesn't make sense, since providers are interested in protecting their networks more than protecting the devices they don't own. Not to mention that they cannot really hope to get compliance from devices they don't own.=20 Vidya=20 > -----Original Message----- > From: Harald Alvestrand [mailto:harald@alvestrand.no]=20 > Sent: Friday, October 13, 2006 6:24 AM > To: Alan DeKok > Cc: nea@ietf.org; ietf@ietf.org > Subject: Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea) >=20 > A typical NEA case (taken out of what Cisco's NAC is supposed=20 > to be good > for): >=20 > - Worker goes on holiday, takes laptop > - New attack is discovered that exploits a newly discovered=20 > Windows vulnerability > - Patch is created, distributed and installed > - NEA posture requirement is increased to "must have patch" > - Worker comes back, plugs in laptop >=20 > Without NEA-like functionality: > - Worker is admitted > - Worker gets attacked & compromised > - IDS & other alarms go off > - Remediation efforts do what they usually do >=20 > With NEA: > - Worker gets sandboxed > - Worker gets upgraded > - Worker gets admitted > - No compromise, so no remediation >=20 > No ill intent on the part of any participant (except the=20 > attacker). Just a TCO issue. >=20 > The fact that some fruit is low-hanging doesn't mean it's not=20 > worth picking. >=20 > Harald >=20 >=20 > Alan DeKok wrote: > > Brian E Carpenter wrote: > > =20 > >> What if your contractor has carefully configured the=20 > laptop to give=20 > >> all the right answers? What if it has already been infected with a=20 > >> virus that causes it to give all the right answers? > >> =20 > > > > Yes, that's a problem with NEA. No, it's not a problem=20 > for many (if=20 > > not most) people using NEA. > > > > The people I talk with plan on using NEA to catch the 99%=20 > case of a=20 > > misconfigured/unknown system that is used by a well-meaning but=20 > > perhaps less clueful employee or contractor. The purpose=20 > of NEA is to=20 > > enhance network security by allowing fewer insecure end=20 > hosts in the=20 > > network. > > > > No one can prevent a determined attacker from getting in. But by=20 > > providing fewer hosts for him to attack, the attacks become less=20 > > feasibly, and more visible. > > > > Alan DeKok. > > > > _______________________________________________ > > Ietf mailing list > > Ietf@ietf.org > > https://www1.ietf.org/mailman/listinfo/ietf > > > > =20 >=20 >=20 > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Oct 16 20:43:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZd3O-0003MN-Tx; Mon, 16 Oct 2006 20:43:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZd3M-0003KW-FZ; Mon, 16 Oct 2006 20:43:32 -0400 Received: from a.mail.sonic.net ([64.142.16.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZd3L-0005EG-0N; Mon, 16 Oct 2006 20:43:32 -0400 Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG [168.61.10.151]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id k9H0hMNT018005 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 16 Oct 2006 17:43:22 -0700 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: <3F17F099-F1C7-4151-8D2B-CA63D787665A@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea) Date: Mon, 16 Oct 2006 17:43:40 -0700 To: dassa@dhs.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: nea@ietf.org, ietf@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 Oct 12, 2006, at 2:27 PM, Darryl ((Dassa)) Lynch wrote: > Am I mistaken or is NEA intended to be a compliance check before a > node is allowed onto the network? It seems impractical to specify system requirements or expect a suitable examination be done realtime prior to obtaining access. NEA should be seen more as a notification process with the goal of avoiding self inflicted trouble tickets. Bad actors will always be able to falsify this information, so the NEA does not offer protection. > As such, observed behaviour and application abuse would seem to be > issues that would be dealt with by other tools. Agreed. When these other tools withdraw services after bad behavior is detected, NEA can notify the endpoint nothing is malfunctioning, but rather these services have been withheld. A selection of certificates may then be required before additional (or any) services are subsequently granted. The NEA should be viewed as a process that eliminates many of the security related support calls. > NEA may be used to ensure certain applications are installed and > some other characteristics of the node but actual behaviour may not > be evident until such time as the node has joined the network and > would be beyond the scope of detection by NEA IMHO. NEA may be > used to assist in limiting the risk of such behaviour but that is > about the extent of it that I see. It seems impractical to expect NEA will prevent bad actors from producing the expected results. There is little that prevents the NEA from providing falsified information. There are anti-virus and OS updating services that could produce a certificate that includes: 1) certificate creator for validation 2) a time-stamp 3) class 4) the user/host identifier 5) resources required for updating the certificate It seems unwise to expect an endpoint to open their robes to the access point. However, the access point could offer certification services they require prior to granting access. This service may be something as simple as agreeing to the AUP presented on a web-form, or agreeing to remedy the cause of abusive behavior. The NEA should also be helpful in deciding whether a range of services are acceptable, and how this can be changed. Perhaps different certificates are required before specific services are granted. Rather than talking about the posture of the endpoint, consider the NEA to be little more than a repository for time- sensitive compliance certificates offering just the five points listed. > My reading of the charter gives me the impression NEA is only > intended for a specific task and some of what we have been > discussing seems to extend well beyond the limited scope proposed. It seems that the NEA charter delves into too many details. The NEA can act as a bidirectional notification of services. From the access standpoint, these are services granted and compliance services required to upgrade what is being granted. From the endpoint standpoint, their certificates indicate which compliance services have been previously obtained, and the resources needed to renew these certificates when they are considered out-of-date by the access point. -Doug _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 17 02:12:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZiBr-0002C0-Bh; Tue, 17 Oct 2006 02:12:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZiBd-0001mL-TO; Tue, 17 Oct 2006 02:12:25 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZi4D-0000UB-W0; Tue, 17 Oct 2006 02:04:47 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 16 Oct 2006 23:02:14 -0700 X-IronPort-AV: i="4.09,318,1157353200"; d="scan'208"; a="602931461:sNHT50754454" 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] WG Review: Network Endpoint Assessment (nea) Date: Tue, 17 Oct 2006 02:04:42 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] WG Review: Network Endpoint Assessment (nea) Thread-index: AcbvAGai8Lr4TLgARk+68FBGr5Ot/ACMUjnQABhxn6A= From: "Stephen Hanna" To: "Narayanan, Vidya" , "Sam Hartman" , "Frank Yeh Jr" X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: "Hardie, Ted" , nea@ietf.org, ietf@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Vidya Narayanan wrote: > I am very apprehensive of achieving any meaningful PA-level > interoperability. I am not sure what minimum set of PA attributes will > be standardized, but, whatever that set is, I doubt will be sufficient > to provide any acceptable level of security, even for the endpoints. This is not surprising, since you have said that you don't see any security value to NEA. > Even assuming ongoing standardization of vendor specific attributes, it > is not totally realistic to assume that all applications will support > the appropriate attributes. The rate of standardization is also very > likely to be much slower than the rate of the growth in the number of > attributes needed for any continued meaningful protection. =20 NEA is not based on applications supporting attributes. Attributes are supported by Posture Collectors and Posture Validators, specialized NEA components. An AV Posture Collector will handle attributes pertaining to AV, perhaps by interfacing with an existing AV application. Still, I agree that a given endpoint will typically only support a small subset of the universe of possible attributes. Not a problem. As long as the endpoint supports enough attributes that the Posture Broker can evaluate its compliance with the posture policy, that's enough. Thanks, Steve -----Original Message----- From: Narayanan, Vidya [mailto:vidyan@qualcomm.com]=20 Sent: Monday, October 16, 2006 5:06 PM To: Sam Hartman; Frank Yeh Jr Cc: Hardie, Ted; nea@ietf.org; ietf@ietf.org Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea) Sam,=20 > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu]=20 > Sent: Friday, October 13, 2006 12:43 PM > To: Frank Yeh Jr > Cc: Hardie, Ted; nea@ietf.org; ietf@ietf.org > Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) >=20 > >>>>> "Frank" =3D=3D Frank Yeh writes: >=20 > From nea-bounces@ietf.org Tue Oct 17 02:12:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZiBr-0002C0-Bh; Tue, 17 Oct 2006 02:12:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZiBd-0001mL-TO; Tue, 17 Oct 2006 02:12:25 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZi4D-0000UB-W0; Tue, 17 Oct 2006 02:04:47 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 16 Oct 2006 23:02:14 -0700 X-IronPort-AV: i="4.09,318,1157353200"; d="scan'208"; a="602931461:sNHT50754454" 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] WG Review: Network Endpoint Assessment (nea) Date: Tue, 17 Oct 2006 02:04:42 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] WG Review: Network Endpoint Assessment (nea) Thread-index: AcbvAGai8Lr4TLgARk+68FBGr5Ot/ACMUjnQABhxn6A= From: "Stephen Hanna" To: "Narayanan, Vidya" , "Sam Hartman" , "Frank Yeh Jr" X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: "Hardie, Ted" , nea@ietf.org, ietf@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Vidya Narayanan wrote: > I am very apprehensive of achieving any meaningful PA-level > interoperability. I am not sure what minimum set of PA attributes will > be standardized, but, whatever that set is, I doubt will be sufficient > to provide any acceptable level of security, even for the endpoints. This is not surprising, since you have said that you don't see any security value to NEA. > Even assuming ongoing standardization of vendor specific attributes, it > is not totally realistic to assume that all applications will support > the appropriate attributes. The rate of standardization is also very > likely to be much slower than the rate of the growth in the number of > attributes needed for any continued meaningful protection. =20 NEA is not based on applications supporting attributes. Attributes are supported by Posture Collectors and Posture Validators, specialized NEA components. An AV Posture Collector will handle attributes pertaining to AV, perhaps by interfacing with an existing AV application. Still, I agree that a given endpoint will typically only support a small subset of the universe of possible attributes. Not a problem. As long as the endpoint supports enough attributes that the Posture Broker can evaluate its compliance with the posture policy, that's enough. Thanks, Steve -----Original Message----- From: Narayanan, Vidya [mailto:vidyan@qualcomm.com]=20 Sent: Monday, October 16, 2006 5:06 PM To: Sam Hartman; Frank Yeh Jr Cc: Hardie, Ted; nea@ietf.org; ietf@ietf.org Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea) Sam,=20 > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu]=20 > Sent: Friday, October 13, 2006 12:43 PM > To: Frank Yeh Jr > Cc: Hardie, Ted; nea@ietf.org; ietf@ietf.org > Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) >=20 > >>>>> "Frank" =3D=3D Frank Yeh writes: >=20 > Frank> Standardized VS vendor-specific attributes is not=20 > something that needs to be > Frank> solved today. Solutions can start with=20 > vendor-specific and migrate toward a > Frank> standard, if one develops, without changing the=20 > protocol. The specification > Frank> should not preclude the addition of standardized=20 > attributes. IE the > Frank> specification is like an alphabet, attributes are=20 > like vocabulary. You can add > Frank> new words without changing the letters. >=20 >=20 > One of the things coming out of the most recent BOF was a=20 > strong desire for PA-level interoperability. That can be=20 > accomplished through standardized attributes or=20 > vendor-specific attributes that are sufficiently well=20 > documented (and not subject to patents) that third parties=20 > can implement collectors or analysis tools that interoperate=20 > with the vendor tools for the vendor attributes. >=20 > Will we be able to meet these interoperability goals? Why or why not? >=20 I am very apprehensive of achieving any meaningful PA-level interoperability. I am not sure what minimum set of PA attributes will be standardized, but, whatever that set is, I doubt will be sufficient to provide any acceptable level of security, even for the endpoints. Even assuming ongoing standardization of vendor specific attributes, it is not totally realistic to assume that all applications will support the appropriate attributes. The rate of standardization is also very likely to be much slower than the rate of the growth in the number of attributes needed for any continued meaningful protection.=20 Regards, Vidya _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 17 02:12:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZiBr-0002CX-Oq; Tue, 17 Oct 2006 02:12:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZiBd-0001fr-Ui; Tue, 17 Oct 2006 02:12:26 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZi4C-0000UB-Ea; Tue, 17 Oct 2006 02:04:45 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 16 Oct 2006 23:02:13 -0700 X-IronPort-AV: i="4.09,318,1157353200"; d="scan'208"; a="602931444:sNHT30787392" 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] WG Review: Network Endpoint Assessment (nea) Date: Tue, 17 Oct 2006 02:04:42 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] WG Review: Network Endpoint Assessment (nea) Thread-index: AcbvAJSUDhwrT67TSpKp42129a9w1QCkwdvg From: "Stephen Hanna" To: "Sam Hartman" , "Frank Yeh Jr" X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Ted Hardie , nea@ietf.org, ietf@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 Sam Hartman wrote: > One of the things coming out of the most recent BOF was a=20 > strong desire for PA-leFrank> Standardized VS vendor-specific attributes is not=20 > something that needs to be > Frank> solved today. Solutions can start with=20 > vendor-specific and migrate toward a > Frank> standard, if one develops, without changing the=20 > protocol. The specification > Frank> should not preclude the addition of standardized=20 > attributes. IE the > Frank> specification is like an alphabet, attributes are=20 > like vocabulary. You can add > Frank> new words without changing the letters. >=20 >=20 > One of the things coming out of the most recent BOF was a=20 > strong desire for PA-level interoperability. That can be=20 > accomplished through standardized attributes or=20 > vendor-specific attributes that are sufficiently well=20 > documented (and not subject to patents) that third parties=20 > can implement collectors or analysis tools that interoperate=20 > with the vendor tools for the vendor attributes. >=20 > Will we be able to meet these interoperability goals? Why or why not? >=20 I am very apprehensive of achieving any meaningful PA-level interoperability. I am not sure what minimum set of PA attributes will be standardized, but, whatever that set is, I doubt will be sufficient to provide any acceptable level of security, even for the endpoints. Even assuming ongoing standardization of vendor specific attributes, it is not totally realistic to assume that all applications will support the appropriate attributes. The rate of standardization is also very likely to be much slower than the rate of the growth in the number of attributes needed for any continued meaningful protection.=20 Regards, Vidya _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 17 02:12:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZiBr-0002CX-Oq; Tue, 17 Oct 2006 02:12:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZiBd-0001fr-Ui; Tue, 17 Oct 2006 02:12:26 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZi4C-0000UB-Ea; Tue, 17 Oct 2006 02:04:45 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 16 Oct 2006 23:02:13 -0700 X-IronPort-AV: i="4.09,318,1157353200"; d="scan'208"; a="602931444:sNHT30787392" 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] WG Review: Network Endpoint Assessment (nea) Date: Tue, 17 Oct 2006 02:04:42 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] WG Review: Network Endpoint Assessment (nea) Thread-index: AcbvAJSUDhwrT67TSpKp42129a9w1QCkwdvg From: "Stephen Hanna" To: "Sam Hartman" , "Frank Yeh Jr" X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Ted Hardie , nea@ietf.org, ietf@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 Sam Hartman wrote: > One of the things coming out of the most recent BOF was a=20 > strong desire for PA-level interoperability. That can be=20 > accomplished through standardized attributes or=20 > vendor-specific attributes that are sufficiently well=20 > documented (and not subject to patents) that third parties=20 > can implement collectors or analysis tools that interoperate=20 > with the vendor tools for the vendor attributes. >=20 > Will we be able to meet these interoperability goals? Why or why not? Yes, we can. If we define a small set of standardized attributes (OS and app version, AV status, etc.) and make them mandatory to implement, then we will have interoperability with respect to those attributes. We should allow the definition of attributes that go beyond this minimal standard mandatory to implement (MTI) set but the MTI set will provide a baseline of information available for all endpoints that implement NEA. Thanks, Steve _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea vel interoperability. That can be=20 > accomplished through standardized attributes or=20 > vendor-specific attributes that are sufficiently well=20 > documented (and not subject to patents) that third parties=20 > can implement collectors or analysis tools that interoperate=20 > with the vendor tools for the vendor attributes. >=20 > Will we be able to meet these interoperability goals? Why or why not? Yes, we can. If we define a small set of standardized attributes (OS and app version, AV status, etc.) and make them mandatory to implement, then we will have interoperability with respect to those attributes. We should allow the definition of attributes that go beyond this minimal standard mandatory to implement (MTI) set but the MTI set will provide a baseline of information available for all endpoints that implement NEA. Thanks, Steve _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 17 03:01:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZix5-00048a-LD; Tue, 17 Oct 2006 03:01:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZix4-00043l-0u; Tue, 17 Oct 2006 03:01:26 -0400 Received: from mga01.intel.com ([192.55.52.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZiwa-00006K-SP; Tue, 17 Oct 2006 03:00:58 -0400 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by mga01.intel.com with ESMTP; 17 Oct 2006 00:00:54 -0700 Received: from orsmsx002.jf.intel.com (HELO orsmsx002.amr.corp.intel.com) ([10.22.226.91]) by fmsmga002.fm.intel.com with ESMTP; 17 Oct 2006 00:00:53 -0700 X-ExtLoop1: 1 X-IronPort-AV: i="4.09,318,1157353200"; d="scan'208"; a="4593921:sNHT24718320" Received: from orsmsx411.amr.corp.intel.com ([10.22.226.47]) by orsmsx002.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 00:00:53 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea) Date: Tue, 17 Oct 2006 00:00:52 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] WG Review: Network Endpoint Assessment (nea) thread-index: AcbvB3unhwFYsXI4SVS0pYub2n7FvwCr8X/w From: "Khosravi, Hormuzd M" To: "Sam Hartman" , "Frank Yeh Jr" X-OriginalArrivalTime: 17 Oct 2006 07:00:53.0393 (UTC) FILETIME=[FC7CF810:01C6F1B9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: Ted Hardie , nea@ietf.org, ietf@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 Sam, I believe if we move 'quickly' in this WG we will be able to meet interoperability goals to certain extent atleast. The bottom-line is this technology is already being deployed by different vendors in academia and enterprises. The question is should IETF get involved in standardizing this or leave it to the individual vendors. I believe the IETF should and that standardization will certainly help the community, if we can move fast enough. The recent email by Jari Arkko to standardize some of the EAP methods which are being used and deployed today but no RFCs exist for them, is certainly a step in the right direction. My 2 cents, Hormuzd -----Original Message----- From: Sam Hartman [mailto:hartmans-ietf@mit.edu]=20 Sent: Friday, October 13, 2006 12:43 PM To: Frank Yeh Jr Cc: Ted Hardie; nea@ietf.org; ietf@ietf.org Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) >>>>> "Frank" =3D=3D Frank Yeh writes: Frank> Standardized VS vendor-specific attributes is not something that needs to be Frank> solved today. Solutions can start with vendor-specific and migrate toward a Frank> standard, if one develops, without changing the protocol. The specification Frank> should not preclude the addition of standardized attributes. IE the Frank> specification is like an alphabet, attributes are like vocabulary. You can add Frank> new words without changing the letters. One of the things coming out of the most recent BOF was a strong desire for PA-level interoperability. That can be accomplished through standardized attributes or vendor-specific attributes that are sufficiently well documented (and not subject to patents) that third parties can implement collectors or analysis tools that interoperate with the vendor tools for the vendor attributes. Will we be able to meet these interoperability goals? Why or why not? _______________________________________________ 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 Oct 17 03:18:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZjDh-0006t3-B8; Tue, 17 Oct 2006 03:18:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZjDf-0006r2-SG; Tue, 17 Oct 2006 03:18:35 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZj7i-0002Ad-DS; Tue, 17 Oct 2006 03:12:28 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k9H7CIPQ023191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 17 Oct 2006 00:12:19 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-64-36.qualcomm.com [10.50.64.36]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k9H7CCPf015210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Oct 2006 00:12:15 -0700 (PDT) Message-Id: <7.0.1.0.2.20061016235145.04723000@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 17 Oct 2006 00:12:06 -0700 To: Harald Alvestrand , "Narayanan, Vidya" From: Lakshminath Dondeti Subject: Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea) In-Reply-To: <453472DC.1020503@alvestrand.no> References: <453472DC.1020503@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: nea@ietf.org, ietf@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 11:06 PM 10/16/2006, Harald Alvestrand wrote: >Narayanan, Vidya wrote: >>Harald, >> >Noting the scenarios above, I claim that NEA-like functionality has >proved useful already in protecting "the computing environment of an >enterprise". I have not seen compelling evidence that it has any use >in "the layer 3 infrastructure used to carry customer traffic at an ISP". > >But I think that's beside the point - the use cases for which we >know that NEA may be useful are already compelling enough that we >should stop debating whether or not to charter the group and get on >with the work. It seems that there are a number of people believing that NEA might be useful in Enterprise networks where the network and the endpoints attaching to the network are owned and "controlled" by the same entity. I know your words are "proved" useful; but perhaps we might agree that it's an arms race, so to speak. Note that the notion of "proved" useful is unlike the type of guarantees we are used to in the Security area. The charter currently says in part "There is an open issue with respect to NEA applicability in deployment scenarios where the endpoint is owned by a party that is different from the organization providing network access." That is ambiguous. I suggested adding the following applicability statement before: "NEA is applicable to networks where endpoints accessing the network are owned and tightly controlled by the organization that owns and operates the network. In all other cases, NEA and associated procedures and protocols are ineffective." That also seems ambiguous as per the recent discussions, so I propose the following revision, based on your words Harald: "NEA is applicable to computing environments of enterprises 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. In all other cases, NEA and associated procedures and protocols are ineffective." Let us make that change so it is clear to everyone as to what NEA might and might not do. Lakshminath >My opinion. > > Harald > > >_______________________________________________ >Ietf mailing list >Ietf@ietf.org >https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 17 03:28:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZjNc-0005AY-6x; Tue, 17 Oct 2006 03:28:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZjNb-00057l-EB; Tue, 17 Oct 2006 03:28:51 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZjNa-0005B9-3S; Tue, 17 Oct 2006 03:28:51 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k9H7SmG8027051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 17 Oct 2006 00:28:49 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-64-36.qualcomm.com [10.50.64.36]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k9H7Se4I021017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Oct 2006 00:28:43 -0700 (PDT) Message-Id: <7.0.1.0.2.20061017001426.048be920@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 17 Oct 2006 00:28:33 -0700 To: "Khosravi, Hormuzd M" , "Sam Hartman" , "Frank Yeh Jr" From: Lakshminath Dondeti Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea) In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Ted Hardie , nea@ietf.org, ietf@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 12:00 AM 10/17/2006, Khosravi, Hormuzd M wrote: >Sam, > >I believe if we move 'quickly' in this WG we will be able to meet >interoperability goals to certain extent atleast. The bottom-line is >this technology is already being deployed by different vendors in >academia and enterprises. The question is should IETF get involved in >standardizing this or leave it to the individual vendors. I believe the >IETF should and that standardization will certainly help the community, >if we can move fast enough. Whereas interoperability is a noble goal, the IETF also has the good habit of clearly specifying what our protocols do and don't do. Our bar is thankfully higher than marketing literature for example. >The recent email by Jari Arkko to standardize some of the EAP methods >which are being used and deployed today but no RFCs exist for them, is >certainly a step in the right direction. Good example actually: 3748 contains brutal truths about some of the legacy EAP methods, for instance on MD5-Challenge -- which no one should really be using for access control -- it says: Auth. mechanism: Password or pre-shared key. Ciphersuite negotiation: No Mutual authentication: No Integrity protection: No Replay protection: No Confidentiality: No Key derivation: No Key strength: N/A Dictionary attack prot.: No Fast reconnect: No Crypt. binding: N/A Session independence: N/A Fragmentation: No Channel binding: No In other words, someone who uses that protocol gets zilch! Now of course, in the "real" world, a variant of this protocol was used and soon after publicly demonstrated to be useless. best regards, Lakshminath >My 2 cents, >Hormuzd _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 17 03:40:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZjYc-0008G1-6D; Tue, 17 Oct 2006 03:40:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZjYa-0008Fj-Dt; Tue, 17 Oct 2006 03:40:12 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZjYX-0006fR-UL; Tue, 17 Oct 2006 03:40:12 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k9H7e4tr026753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 17 Oct 2006 00:40:05 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-64-36.qualcomm.com [10.50.64.36]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k9H7dreF000400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 17 Oct 2006 00:39:58 -0700 (PDT) Message-Id: <7.0.1.0.2.20061017003718.074e8de0@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 17 Oct 2006 00:39:48 -0700 To: Harald Alvestrand From: Lakshminath Dondeti Subject: Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea) In-Reply-To: <45348656.4020600@alvestrand.no> References: <453472DC.1020503@alvestrand.no> <7.0.1.0.2.20061016235145.04723000@qualcomm.com> <45348656.4020600@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: nea@ietf.org, ietf@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 12:29 AM 10/17/2006, Harald Alvestrand wrote: >Lakshminath Dondeti wrote: >>At 11:06 PM 10/16/2006, Harald Alvestrand wrote: >>>Narayanan, Vidya wrote: >>>>Harald, >>>> >>>> >> >>"NEA is applicable to computing environments of enterprises 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. In all other cases, NEA and >>associated procedures and protocols are ineffective." >> >>Let us make that change so it is clear to everyone as to what NEA >>might and might not do. >I don't think we have any proof that this statement is true. I can >think of scenarios where NEA would be useful, but they depend on >various circumstances that either would be very specialized or >require a great deal of faith in order to believe they would happen. > >I suggest: > >"All other cases are outside the scope of the NEA charter, since we >do not know that NEA would be useful in such cases." Ok. For the benefit of the editor: Let us replace: "There is an open issue with respect to NEA applicability in deployment scenarios where the endpoint is owned by a party that is different from the organization providing network access." with "NEA is applicable to computing environments of enterprises 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." Lakshminath _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 17 06:33:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZmFl-0000US-Jt; Tue, 17 Oct 2006 06:32:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZmFi-0000SQ-TD; Tue, 17 Oct 2006 06:32:54 -0400 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 1GZm71-0004bh-9v; Tue, 17 Oct 2006 06:23:59 -0400 Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 4192B16E31; Tue, 17 Oct 2006 06:17:34 -0400 (EDT) From: "Alan DeKok" To: Douglas Otis Subject: Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea) In-Reply-To: Your message of "Mon, 16 Oct 2006 17:43:40 PDT." <3F17F099-F1C7-4151-8D2B-CA63D787665A@mail-abuse.org> Date: Tue, 17 Oct 2006 06:17:34 -0400 Message-Id: <20061017101734.4192B16E31@mail.nitros9.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: nea@ietf.org, ietf@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 Douglas Otis wrote: > It seems impractical to specify system requirements or expect a > suitable examination be done realtime prior to obtaining access. Maybe you're saying that a complete systems check would take too long. That is true, but that isn't how the NEA variants are being designed or deployed. > Bad actors will always be able to falsify this information, so the > NEA does not offer protection. This issue has already been discussed. > The NEA should be viewed as a process that eliminates many of the > security related support calls. That is not a priority for any customers I talked to. I've never head this as a justification for NEA from anyone. > It seems impractical to expect NEA will prevent bad actors from > producing the expected results. Which is why recent discussions on the NEA list made it clear that no one was expecting that from NEA. > There are anti-virus and OS updating services that could produce a > certificate that includes: ... Which is a good idea, and substantially similar to validation and remediation services currently offered. That information still has to be propogated to the device that controls network access. > It seems unwise to expect an endpoint to open their robes to the > access point. However, the access point could offer certification > services they require prior to granting access. This service may be > something as simple as agreeing to the AUP presented on a web-form, > or agreeing to remedy the cause of abusive behavior. People are doing something similar to this today with quarantine networks, and remediation sites. But it's ad-hoc, and not automated. > Rather than talking about the posture of the endpoint, > consider the NEA to be little more than a repository for time- > sensitive compliance certificates offering just the five points listed. Pretty much, yes. With the addition of a protocol to carry that information from the end point to elsewhere in the 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 Oct 17 09:11:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZoj3-00009H-K1; Tue, 17 Oct 2006 09:11:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZjOP-0005lj-5X; Tue, 17 Oct 2006 03:29:41 -0400 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZjOL-0005EF-JI; Tue, 17 Oct 2006 03:29:41 -0400 Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B5C872596EB; Tue, 17 Oct 2006 09:26:55 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02288-01; Tue, 17 Oct 2006 09:26:50 +0200 (CEST) Received: from [172.28.60.246] (unknown [62.92.16.50]) by eikenes.alvestrand.no (Postfix) with ESMTP id 268CA2596C3; Tue, 17 Oct 2006 09:26:50 +0200 (CEST) Message-ID: <45348656.4020600@alvestrand.no> Date: Tue, 17 Oct 2006 09:29:26 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Lakshminath Dondeti Subject: Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea) References: <453472DC.1020503@alvestrand.no> <7.0.1.0.2.20061016235145.04723000@qualcomm.com> In-Reply-To: <7.0.1.0.2.20061016235145.04723000@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 X-Mailman-Approved-At: Tue, 17 Oct 2006 09:11:19 -0400 Cc: nea@ietf.org, ietf@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 Lakshminath Dondeti wrote: > At 11:06 PM 10/16/2006, Harald Alvestrand wrote: >> Narayanan, Vidya wrote: >>> Harald, >>> >> Noting the scenarios above, I claim that NEA-like functionality has >> proved useful already in protecting "the computing environment of an >> enterprise". I have not seen compelling evidence that it has any use >> in "the layer 3 infrastructure used to carry customer traffic at an >> ISP". >> >> But I think that's beside the point - the use cases for which we know >> that NEA may be useful are already compelling enough that we should >> stop debating whether or not to charter the group and get on with the >> work. > > It seems that there are a number of people believing that NEA might be > useful in Enterprise networks where the network and the endpoints > attaching to the network are owned and "controlled" by the same > entity. I know your words are "proved" useful; but perhaps we might > agree that it's an arms race, so to speak. Note that the notion of > "proved" useful is unlike the type of guarantees we are used to in the > Security area. > > The charter currently says in part "There is an open issue with > respect to NEA applicability in deployment scenarios where the > endpoint is owned by a party that is different from the organization > providing network access." > > That is ambiguous. I suggested adding the following applicability > statement before: > > "NEA is applicable to networks where endpoints accessing the network > are owned and tightly controlled by the organization that owns and > operates the network. In all other cases, NEA and associated > procedures and protocols are ineffective." > > That also seems ambiguous as per the recent discussions, so I propose > the following revision, based on your words Harald: > > "NEA is applicable to computing environments of enterprises 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. In all other cases, NEA and associated > procedures and protocols are ineffective." > > Let us make that change so it is clear to everyone as to what NEA > might and might not do. I don't think we have any proof that this statement is true. I can think of scenarios where NEA would be useful, but they depend on various circumstances that either would be very specialized or require a great deal of faith in order to believe they would happen. I suggest: "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 mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 17 09:30:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZp1N-000694-Fk; Tue, 17 Oct 2006 09:30:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZp1M-00068w-Og; Tue, 17 Oct 2006 09:30:16 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZp1L-0000EP-Dx; Tue, 17 Oct 2006 09:30:16 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 17 Oct 2006 06:27:45 -0700 X-IronPort-AV: i="4.09,320,1157353200"; d="scan'208"; a="603092187:sNHT39271272" X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Oct 2006 09:30:13 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: WG Review: Network Endpoint Assessment (nea) Thread-index: AcbxUKV5ax+ON1aVT3yGtSbOdRLqqgAnvdxA From: "Stephen Hanna" To: "Hardie, Ted" X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: nea@ietf.org, ietf@ietf.org Subject: [Nea] Re: WG Review: Network Endpoint Assessment (nea) X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Ted, As I understand your concerns expressed below, you are concerned that standardizing attributes for NEA would be redundant and pointless: redundant because vendor-specific attributes will cover the same information in more detail and pointless because remediation will not be possible given the limited information available through the standardized attributes. Is that right? If so, maybe it would help to explain why we want to have standardized attributes. The goal is to ensure that any NEA endpoint and server can interoperate in a meaningful manner without making the assumption that endpoint and server have the same vendor "plug-ins" installed. For this to be true, we must ensure that every NEA endpoint provides a basic set of information to the NEA server. That basic set of information will be the standardized attributes. If the endpoint and server both understand vendor-specific attributes that provide more information, that's great. But we want to ensure a base level of interoperability. Yes, remediation may be difficult using only the information in the standardized attributes. But a captive portal technique can be used to provide information to the endpoint user about how to remediate. Thanks, Steve Ted Hardie wrote: > I have a very basic fear that this working group is getting chartered > with a bunch of aims added by people who will not take on the > task of doing the work. After private discussion with folks > involved, my sense is that the very core of this work is a perceived=20 > need to be able to pass opaque strings between a host and the network=20 > prior to the host attaching. Those opaque strings are, essentially, > the vendor-specific strings currently associated with posture assessment. > The standard protocol carrying these strings would connect on the network > side to a system that has plug-ins which understand the vendor-specific > strings. =20 >=20 > With a charter that clarified that this was intended to assist the end > systems with vulnerabilities prior to attachment because the > network they are attaching to might be filled with danger, I=20 > think this work would get done reasonably quickly. (As a control > mechanism to protect the network, I agree with the point made > clearly by others that this is not appropriate). >=20 > I am less sure of the task of standardizing attributes. >=20 > I am not sure that the number of attributes which can be standardized > will ever be high enough to be truly useful, and I am pretty sure > that all of these will be already covered by vendor-specific attributes. > Since there must be an assessor in place on the client for those few > standardized attributes to be assessed and that assessor will likely already > have these covered by vendor-specific attributes, in other words, > we seem to be standardizing redundancy. On the network attachment > side, it is possible, of course, that an offer of remediation could be made > based on just the standard attributes, but it seems far more likely that > it would be a two step process (assess standard attributes, then pass > vendor-specific attributes to vendor plug-in). Again, if the vendor's > attributes cover the standard attributes, then this is largely redundant > and may add measurable latency; it seems far more likely that=20 > step one would simply be skipped if there were a vendor-specific string > and an available plug-in. Since there has to be an assessor, the first > seems very likely to me. If you don't have a vendor's plug-in, then > I suppose there is some chance that you will trust and act based on the standard > attributes, but the chance of getting the right remediation seems > pretty slight in those circumstances. Especially when many vulnerabilities > are a combination of conditions, (Browser version Foo on OS patch level Bar)=20 > that you could remediate by upgrading either one, checking for and > acting on the attributes which could be standardized seems of very, very=20 > limited utility. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 17 16:06:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZvCk-0002hZ-SF; Tue, 17 Oct 2006 16:06:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZvCK-00024n-TE; Tue, 17 Oct 2006 16:06:01 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZuws-0004bQ-LM; Tue, 17 Oct 2006 15:50:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 8076C26E5A; Tue, 17 Oct 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GZuws-0007JQ-D1; Tue, 17 Oct 2006 15:50:02 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: ietf-announce@ietf.org From: IESG Secretary Message-Id: Date: Tue, 17 Oct 2006 15:50:02 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 Cc: nea@ietf.org Subject: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org A new IETF working group has been proposed in the Security Area. The IESG has not made any determination as yet. The following UPDATED draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by October 23rd. +++ Network Endpoint Assessment (nea) =================================== Current Status: Proposed Working Group Chair(s): TBD Security Area Director(s): Russ Housley Sam Hartman Security Area Advisor: Russ Housley Mailing List: nea@ietf.org Description of Working Group: Network Endpoint Assessment (NEA) architectures have been implemented in the industry 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. An endpoint that does not comply with posture policy may be vulnerable to a number of known threats that may exist on the network. The intent of NEA is to facilitate corrective actions to address these known vulnerabilities before a host is exposed to potential attack. Note that an endpoint that is deemed compliant may still be vulnerable to unknown 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. Posture refers to the hardware or software configuration of an endpoint as it pertains to an organization's security 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. On network access and while connected, an endpoint supporting NEA protocols can be queried for such posture information. 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"). 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 one mandatory to implement PT protocol to ensure interoperability. 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. Vendor-specific attributes will also be supported, but vendor-specific attributes must be documented in an RFC. 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 can be limited in its applicability when the endpoint and the organization providing network access are owned by different parties. 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: October 2006: * Submit first draft of NEA Requirements I-D November 2006: * At IETF 67, discuss issues with 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 * Deadline for submission of candidate specs for PA and PB March 2007: * At IETF 68, resolve outstanding issues with requirements I-D * Report from NEA protocol evaluation team April 2007: * Submit NEA Evaluation I-D June 2007: * Submit revised NEA Evaluation I-D * WGLC on NEA Evaluation I-D July 2007: * At IETF 69, review outstanding comments on evaluation I-D August 2007: * Submit first draft of PA and PB spec October 2007: * Submit revised draft of PA and PB spec * Decide how to address MTI PT, recharter if needed December 2007: * At IETF70, discuss and resolve issues with PA and PB spec February 2008: * WGLC on PA and PB spec _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 17 16:49:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZvrw-0005CM-St; Tue, 17 Oct 2006 16:49:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZvSs-0004yW-HJ for nea@ietf.org; Tue, 17 Oct 2006 16:23:06 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZvSY-00020s-4Q for nea@ietf.org; Tue, 17 Oct 2006 16:23:05 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 17 Oct 2006 13:22:46 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9HKMj9o021819 for ; Tue, 17 Oct 2006 13:22:45 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k9HKMVOv017213 for ; Tue, 17 Oct 2006 13:22:45 -0700 (PDT) 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); Tue, 17 Oct 2006 16:22:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Oct 2006 16:22:24 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Updated charter [UPDATED: WG Review: Network Endpoint Assessment (nea)] Thread-Index: AcbyJXIIfq0oC309RpSbY7pyjnv1cwAAV1Ow From: "Susan Thomson \(sethomso\)" To: X-OriginalArrivalTime: 17 Oct 2006 20:22:26.0579 (UTC) FILETIME=[F642C630:01C6F229] DKIM-Signature: a=rsa-sha1; q=dns; l=8113; t=1161116565; x=1161980565; c=relaxed/relaxed; s=sjdkim8002; 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:FW=3A=20Updated=20charter=20[UPDATED=3A=20WG=20Review=3A=20Network=20End point=20Assessment=20(nea)]; X=v=3Dcisco.com=3B=20h=3DJPxmnIcwaIYQt14OS67HiUkeOUk=3D; b=V/WW8Aep76QqLMn03Yux34/Ij0j/GEkZ6jDPMiKWzzcMPmeHWeXsoLSsWDYm9aGOGZcyWXDk R+hjv1eCRynFq16oQja7F9p2oGXKiuA4GImPZpoBEkxW4ydNFIEruvGH; Authentication-Results: sj-dkim-8.cisco.com; header.From=sethomso@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 Subject: [Nea] FW: Updated charter [UPDATED: WG Review: Network Endpoint Assessment (nea)] X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Folks This is a charter update based on discussions on mailing list up to about a week ago. It includes the following changes: 1. Be explicit about what NEA is not protecting against 2. Modified text on mandatory/advisory mode to make clear subject to policy and not limited to the deployment modes mentioned=20 3. Moved posture definition closer to beginning 4. Revised text on endpoint ownership issue=20 5. Modified milestone dates to be more realistic There is an open issue that is subject of an ongoing thread re scope of standard attributes. I expect another update based on resolution of that thread along with a few other clarifications that have been requested. Thanks Susan -----Original Message----- From: IESG Secretary [mailto:iesg-secretary@ietf.org]=20 Sent: Tuesday, October 17, 2006 3:50 PM To: ietf-announce@ietf.org Cc: nea@ietf.org Subject: UPDATED: WG Review: Network Endpoint Assessment (nea)=20 A new IETF working group has been proposed in the Security Area. =20 The IESG has not made any determination as yet. The following UPDATED=20 draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by October 23rd. +++ Network Endpoint Assessment (nea) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Current Status: Proposed Working Group Chair(s):=20 TBD Security Area Director(s): Russ Housley Sam Hartman Security Area Advisor: Russ Housley Mailing List: nea@ietf.org Description of Working Group: 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=20 that may exist on the network. The intent of NEA is to facilitate=20 corrective actions to address these known vulnerabilities before a=20 host is exposed to potential attack. Note that an endpoint that is=20 deemed compliant may still be vulnerable to unknown threats that may=20 exist on the network. The network may thus continue to be exposed to=20 such threats as well as the range of other threats not addressed by=20 maintaining endpoint compliance. Posture refers to the hardware or software configuration of an=20 endpoint as it pertains to an organization's security policy. Posture=20 may include knowledge that software installed to protect the machine=20 (e.g. patch management software, anti-virus software, host firewall=20 software, host intrusion protection software or any custom software)=20 is enabled and up-to-date. On network access and while connected, an=20 endpoint supporting NEA protocols can be queried for such posture information. 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=20 this 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=20 purposes and any essential services until an endpoint is in=20 compliance ("mandatory mode"). Since NEA involves many different components from different vendors,=20 interoperability is important. The priority of the NEA working group=20 is to develop standard protocols at the higher layers in the=20 architecture: the Posture Attribute protocol (PA) and the Posture=20 Broker protocol (PB). PA and PB will be designed to support a variety=20 of lower layer protocols. When used with standards for lower layers,=20 the PA and PB protocols will allow interoperability between an NEA=20 Client from one vendor and an NEA Server from another. Since there are already several non-standard protocols at these=20 higher layers, the NEA working group will consider these existing=20 protocols as candidates for the standard protocols. A requirements=20 document will be written and used as a basis for evaluating the=20 candidate protocols. The working group may decide to standardize one=20 of the candidate protocols, use one of them as a basis for a new or=20 revised protocol, or decide that a new protocol is needed. 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). PT protocols may be standardized in other WGs since these=20 protocols may not be specific to NEA. The NEA WG will identify one=20 mandatory to implement PT protocol to ensure interoperability. The PA (Posture Attribute) protocol consists of posture attributes=20 that are carried between a particular Posture Collector in a NEA=20 client and a particular Posture Validator in a NEA Server. The PA=20 protocol is carried inside the PB protocol. A base set of standard=20 posture attributes will be specified. Vendor-specific attributes=20 will also be supported, but vendor-specific attributes must be=20 documented in an RFC. The PB (Posture Broker) protocol aggregates posture attributes from=20 one or more Posture Collectors in an NEA client and sends them to the=20 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=20 at this time. The expectation is that an existing protocol can be=20 used for the PT. 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,=20 the protocols developed by the NEA WG must be designed to accommodate=20 emerging technologies for identifying and dealing with lying endpoints. Note that NEA is not chartered to develop standard protocols for=20 remediation. NEA is intended to be used with new or existing tools=20 that can be used in the absence of NEA. NEA can be limited in its=20 applicability when the endpoint and the organization providing=20 network access are owned by different parties. NEA applicability and=20 security considerations will be described in the appropriate NEA documents. Further work in the NEA WG will be considered via the rechartering=20 process after the completion of these milestones. Milestones: October 2006: * Submit first draft of NEA Requirements I-D November 2006: * At IETF 67, discuss issues with 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 * Deadline for submission of candidate specs for PA and PB March 2007: * At IETF 68, resolve outstanding issues with requirements I-D * Report from NEA protocol evaluation team April 2007: * Submit NEA Evaluation I-D June 2007: * Submit revised NEA Evaluation I-D * WGLC on NEA Evaluation I-D July 2007: * At IETF 69, review outstanding comments on evaluation I-D August 2007: * Submit first draft of PA and PB spec October 2007: * Submit revised draft of PA and PB spec * Decide how to address MTI PT, recharter if needed December 2007: * At IETF70, discuss and resolve issues with PA and PB spec February 2008: * WGLC on PA and PB spec _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 17 17:01:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZw4S-0004vw-0l; Tue, 17 Oct 2006 17:01:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZw4Q-0004qj-EM; Tue, 17 Oct 2006 17:01:54 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZw4P-0002Yg-29; Tue, 17 Oct 2006 17:01:54 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k9HL1jAR012354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 17 Oct 2006 14:01:46 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k9HKxdtk001831; Tue, 17 Oct 2006 14:01:44 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 14:01:04 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] Re: WG Review: Network Endpoint Assessment (nea) Date: Tue, 17 Oct 2006 14:01:03 -0700 Message-ID: In-Reply-To: <7.0.1.0.2.20061017003718.074e8de0@qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Re: WG Review: Network Endpoint Assessment (nea) Thread-Index: Acbxv3eQbTNb3njOR4iLuNBm2PQGrgAYOpog From: "Narayanan, Vidya" To: "Dondeti, Lakshminath" , "Harald Alvestrand" X-OriginalArrivalTime: 17 Oct 2006 21:01:04.0796 (UTC) FILETIME=[5C069DC0:01C6F22F] X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: nea@ietf.org, ietf@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 Lakshminath, Harald,=20 > -----Original Message----- > From: Lakshminath Dondeti [mailto:ldondeti@qualcomm.com]=20 > Sent: Tuesday, October 17, 2006 12:40 AM > To: Harald Alvestrand > Cc: Narayanan, Vidya; nea@ietf.org; ietf@ietf.org; Alan DeKok > Subject: Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea) >=20 > At 12:29 AM 10/17/2006, Harald Alvestrand wrote: > >Lakshminath Dondeti wrote: > >>At 11:06 PM 10/16/2006, Harald Alvestrand wrote: > >>>Narayanan, Vidya wrote: > >>>>Harald, > >>>> > >>>> > >> > >>"NEA is applicable to computing environments of enterprises where=20 > >>endpoints accessing the enterprise's network are owned=20 > and/or expected=20 > >>to conform to the policies set forth by the organization=20 > that owns and=20 > >>operates the network. In all other cases, NEA and associated=20 > >>procedures and protocols are ineffective." > >> > >>Let us make that change so it is clear to everyone as to what NEA=20 > >>might and might not do. > >I don't think we have any proof that this statement is true. I can=20 > >think of scenarios where NEA would be useful, but they depend on=20 > >various circumstances that either would be very specialized=20 > or require=20 > >a great deal of faith in order to believe they would happen. > > > >I suggest: > > > >"All other cases are outside the scope of the NEA charter,=20 > since we do=20 > >not know that NEA would be useful in such cases." >=20 > Ok. >=20 > For the benefit of the editor: >=20 > Let us replace: >=20 > "There is an open issue with respect to NEA applicability in=20 > deployment scenarios where the endpoint is owned by a party=20 > that is different from the organization providing network access." >=20 > with >=20 > "NEA is applicable to computing environments of enterprises=20 > where endpoints accessing the enterprise's network are owned=20 > and/or expected to conform to the policies set forth by the=20 > organization that owns and operates the network. All other=20 > cases are outside the scope of the NEA charter, since we do=20 > not know that NEA would be useful in such cases." >=20 This text sounds okay to me.=20 Vidya > Lakshminath=20 >=20 >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 17 18:07:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZx5d-0007oe-Me; Tue, 17 Oct 2006 18:07:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZx5b-0007oF-FV; Tue, 17 Oct 2006 18:07:11 -0400 Received: from a.mail.sonic.net ([64.142.16.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZx5a-0002BE-1h; Tue, 17 Oct 2006 18:07:11 -0400 Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG [168.61.10.151]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id k9HM78xZ022557 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 17 Oct 2006 15:07:09 -0700 In-Reply-To: <45351F81.9000800@cisco.com> References: <45351F81.9000800@cisco.com> 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] WG Review: Network Endpoint Assessment (nea) Date: Tue, 17 Oct 2006 15:07:26 -0700 To: Eliot Lear X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: nea@ietf.org, IETF Discussion 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 Oct 17, 2006, at 11:22 AM, Eliot Lear wrote: > I would think that five or six values are appropriate: > > 1. Vendor name (string) > 2. Vendor engine version (integer) > 3. Vendor virus definitions version (integer) > 4. Enabled? (binary) > 5. Buggered? (binary) > 6. Other gobbledigook the vendor wants to include that might get > standardized later. (blob) This still seems like too much. Information offered for access can be contained within one or more certificates. The information within these certificates should be limited to a minimal set of values: 1) creator 2) class 3) user-host 4) time-stamp 5) update resources The essential information would be the creator/class/user-host/time- stamp fields. When protection is not enabled or is buggered, then a newer certificate should not be offered. The virus definitions or patch updates can be deduced from the time-stamp or by extensions added to class, i.e. AVX-VISTA-37. If a vulnerability is reported subsequent to the time-stamp regarding the creator/class of service, then a new certificate could be required. This would simplify tracking at the access point. By keeping the information exchanged and decisions limited to this minimal information, NEA should provide a valuable services in many environments. Perhaps there should be some consideration given regarding which sets of certificates are offered in various environments. Allowing the certificates to be accessed beyond an authentication process seems to increase security exposures. As this information is not trustworthy, there would be also little gained sharing this information elsewhere. In fact, sharing this information may increase infection rates when this aids malware. -Doug _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 17 20:14:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZz54-0004Hm-08; Tue, 17 Oct 2006 20:14:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZro3-0000Kp-UF; Tue, 17 Oct 2006 12:28:43 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZrnz-0003cG-IH; Tue, 17 Oct 2006 12:28:43 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k9HGSbVj001559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 17 Oct 2006 09:28:38 -0700 Received: from [10.0.1.4] (vpn-10-50-16-143.qualcomm.com [10.50.16.143]) by crowley.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k9HGSXYf029636; Tue, 17 Oct 2006 09:28:35 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 17 Oct 2006 09:28:32 -0700 To: "Stephen Hanna" , "Sam Hartman" , "Frank Yeh Jr" From: Ted Hardie Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea) Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-Mailman-Approved-At: Tue, 17 Oct 2006 20:14:44 -0400 Cc: nea@ietf.org, ietf@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 2:04 AM -0400 10/17/06, Stephen Hanna wrote: > > Will we be able to meet these interoperability goals? Why or why not? > >Yes, we can. If we define a small set of standardized attributes >(OS and app version, AV status, etc.) and make them mandatory to >implement, Sorry, but doesn't "AV status" above refer to the existing, proprietary anti-virus systems? How does standardizing an attribute for carrying that help create a standardized understanding of what it means? Don't I still have to treat that as, essentially, a vendor attribute, since I have to know which vendor statuses cover which vulnerabilities? Or do you mean "there is some anti-virus software here"? Ted Hardie _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 17 20:14:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZz54-0004Hw-VS; Tue, 17 Oct 2006 20:14:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZuZ3-0001uE-Nt; Tue, 17 Oct 2006 15:25:25 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZuYz-0000og-BX; Tue, 17 Oct 2006 15:25:25 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k9HJPH61005302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 17 Oct 2006 12:25:19 -0700 Received: from [10.0.1.4] (dhcp-campbell-41.qualcomm.com [129.46.225.24]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k9HJPEdI027881; Tue, 17 Oct 2006 12:25:16 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <45351F81.9000800@cisco.com> References: In-Reply-To: References: Date: Tue, 17 Oct 2006 09:28:32 -0700 To: "Stephen Hanna" , "Sam Hartman" , "Frank Yeh Jr" From: Ted Hardie Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea) Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-Mailman-Approved-At: Tue, 17 Oct 2006 20:14:44 -0400 Cc: nea@ietf.org, ietf@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 2:04 AM -0400 10/17/06, Stephen Hanna wrote: > > Will we be able to meet these interoperability goals? Why or why not? > >Yes, we can. If we define a small set of standardized attributes >(OS and app version, AV status, etc.) and make them mandatory to >implement, Sorry, but doesn't "AV status" above refer to the existing, proprietary anti-virus systems? How does standardizing an attribute for carrying that help create a standardized understanding of what it means? Don't I still have to treat that as, essentially, a vendor attribute, since I have to know which vendor statuses cover which vulnerabilities? Or do you mean "there is some anti-virus software here"? Ted Hardie _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 17 20:14:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZz54-0004Hw-VS; Tue, 17 Oct 2006 20:14:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZuZ3-0001uE-Nt; Tue, 17 Oct 2006 15:25:25 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZuYz-0000og-BX; Tue, 17 Oct 2006 15:25:25 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k9HJPH61005302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 17 Oct 2006 12:25:19 -0700 Received: from [10.0.1.4] (dhcp-campbell-41.qualcomm.com [129.46.225.24]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k9HJPEdI027881; Tue, 17 Oct 2006 12:25:16 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <45351F81.9000800@cisco.com> References: <45351F81.9000800@cisco.com> Date: Tue, 17 Oct 2006 12:25:01 -0700 To: Eliot Lear From: Ted Hardie Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-Mailman-Approved-At: Tue, 17 Oct 2006 20:14:44 -0400 Cc: Sam Hartman , nea@ietf.org, ietf@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 8:22 PM +0200 10/17/06, Eliot Lear wrote: > would think that five or six values are appropriate: > > 1. Vendor name (string) > 2. Vendor engine version (integer) > 3. Vendor virus definitions version (integer) > 4. Enabled? (binary) > 5. Buggered? (binary) > 6. Other gobbledigook the vendor wants to include that might get > standardized later. (blob) > >I could envision 3 being a bit of an issue if it is possible to update specific viruses but not others. Thanks for this. I was assuming we were talking primarily about a "1 and 3" combined value. As it stands now, you need access to the vendor's database to know what viruses are covered by any specific version (your 3). For the charter discussions, I want to know whether it will be an aim of the working group to standardize: * a way of carrying this information * the structure of this information (but not its content) * a standard representation of the content, so that access to the vendor database is no longer required The tasks are substantially different in scope, and the level of interoperabilty the community can expect from them are similarly different. regards, Ted Hardie _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea @proton.jnpr.net> <45351F81.9000800@cisco.com> Date: Tue, 17 Oct 2006 12:25:01 -0700 To: Eliot Lear From: Ted Hardie Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-Mailman-Approved-At: Tue, 17 Oct 2006 20:14:44 -0400 Cc: Sam Hartman , nea@ietf.org, ietf@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 8:22 PM +0200 10/17/06, Eliot Lear wrote: > would think that five or six values are appropriate: > > 1. Vendor name (string) > 2. Vendor engine version (integer) > 3. Vendor virus definitions version (integer) > 4. Enabled? (binary) > 5. Buggered? (binary) > 6. Other gobbledigook the vendor wants to include that might get > standardized later. (blob) > >I could envision 3 being a bit of an issue if it is possible to update specific viruses but not others. Thanks for this. I was assuming we were talking primarily about a "1 and 3" combined value. As it stands now, you need access to the vendor's database to know what viruses are covered by any specific version (your 3). For the charter discussions, I want to know whether it will be an aim of the working group to standardize: * a way of carrying this information * the structure of this information (but not its content) * a standard representation of the content, so that access to the vendor database is no longer required The tasks are substantially different in scope, and the level of interoperabilty the community can expect from them are similarly different. regards, Ted Hardie _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 17 20:14:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZz54-0004Hr-4c; Tue, 17 Oct 2006 20:14:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZtah-00032e-HI; Tue, 17 Oct 2006 14:23:03 -0400 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 1GZtaf-0001lC-7x; Tue, 17 Oct 2006 14:23:03 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 17 Oct 2006 11:23:00 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9HIN0uN002662; Tue, 17 Oct 2006 11:23:00 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9HIN0Ao013756; Tue, 17 Oct 2006 11:23:00 -0700 (PDT) Received: from [212.254.247.5] (ams3-vpn-dhcp100.cisco.com [10.61.64.100]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9HIB0HP022105; Tue, 17 Oct 2006 11:11:01 -0700 Message-ID: <45351F81.9000800@cisco.com> Date: Tue, 17 Oct 2006 20:22:57 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Ted Hardie Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-3.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=1130; t=1161109380; x=1161973380; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Re=3A=20[Nea]=20WG=20Review=3A=20Network=20Endpoint=20Assessment=20(nea); X=v=3Dcisco.com=3B=20h=3DbSaezX0FVSS+QpzS8t3vAQ2bx2c=3D; b=QbSiMyg+vjlxqSd0xM37u4oZtwIn9OPdtwJBFx6bH/DnBKXgh5cUAmahVNnqdrCUCIgbntj5 SkR5Clvk4Rl70q89akgekuF2rtnqGvuRKWFWRD6cb/QpUn15B+9BFcps; X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-Mailman-Approved-At: Tue, 17 Oct 2006 20:14:44 -0400 Cc: nea@ietf.org, Sam Hartman , ietf@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 Ted, > Sorry, but doesn't "AV status" above refer to the existing, proprietary anti-virus > systems? How does standardizing an attribute for carrying that help > create a standardized understanding of what it means? Don't I still > have to treat that as, essentially, a vendor attribute, since I have > to know which vendor statuses cover which vulnerabilities? > > Or do you mean "there is some anti-virus software here"? > > I would think that five or six values are appropriate: 1. Vendor name (string) 2. Vendor engine version (integer) 3. Vendor virus definitions version (integer) 4. Enabled? (binary) 5. Buggered? (binary) 6. Other gobbledigook the vendor wants to include that might get standardized later. (blob) I could envision 3 being a bit of an issue if it is possible to update specific viruses but not others. I would expect the normal enterprise administrator to be able to act on the first 5. The 6th is there as a placeholder. I'm not sure I'd trust 5 if it's false. I'd also suggest we're well into solving the problem at this point. Eliot _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Oct 18 01:32:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga42X-0005E4-4M; Wed, 18 Oct 2006 01:32:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga42W-0005Dz-DB for nea@ietf.org; Wed, 18 Oct 2006 01:32:28 -0400 Received: from [207.47.37.170] (helo=SCES1.sc.nevisnetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga42V-0003If-3p for nea@ietf.org; Wed, 18 Oct 2006 01:32:28 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 17 Oct 2006 22:32:11 -0700 Message-ID: <126EBB1F0092E14B9E595D03263235AAE3D99E@SCES1.sc.nevisnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Is the WG approved? Thread-Index: AcbydsLQ/aQK4lcIR4eAqTCiNnilAg== From: "Joseph Tardo" To: "Stephen Hanna" , X-Spam-Score: 0.2 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: Subject: [Nea] Is the WG approved? 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="===============1170688164==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============1170688164== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F276.CA7E7604" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F276.CA7E7604 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Steve, =20 I just noticed that NEA has appeared on the San Diego agenda for Wednesday, Nov. 8, at 9 am. =20 Does this mean the WG has been approved? =20 Thanks, --Joe ------_=_NextPart_001_01C6F276.CA7E7604 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Steve,

 

I just noticed that NEA has appeared on the San Diego = agenda for Wednesday, Nov. 8, at 9 am.

 

Does this mean the WG has been = approved?

 

Thanks,

--Joe

------_=_NextPart_001_01C6F276.CA7E7604-- --===============1170688164== 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 --===============1170688164==-- From nea-bounces@ietf.org Wed Oct 18 09:25:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaBQ7-0002jU-5l; Wed, 18 Oct 2006 09:25:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaBQ0-0002eO-Ao; Wed, 18 Oct 2006 09:25:12 -0400 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaBGs-0004NB-2X; Wed, 18 Oct 2006 09:15:50 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 1B11A3BFB0; Wed, 18 Oct 2006 15:15:31 +0200 (CEST) Received: from smtp3.su.se ([127.0.0.1]) by localhost (smtp3.su.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 01763-01-73; Wed, 18 Oct 2006 15:15:30 +0200 (CEST) Received: from [130.239.128.205] (unknown [130.239.128.205]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 60FF33BF86; Wed, 18 Oct 2006 15:15:30 +0200 (CEST) Message-ID: <453628EF.4040805@it.su.se> Date: Wed, 18 Oct 2006 15:15:27 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Lakshminath Dondeti Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) References: <4527685D.1090904@alvestrand.no> <7.0.1.0.2.20061007100953.059f1120@qualcomm.com> <453346D8.30309@it.su.se> <7.0.1.0.2.20061016031319.04880dd0@qualcomm.com> In-Reply-To: <7.0.1.0.2.20061016031319.04880dd0@qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.612 tagged_above=-99 required=7 tests=[AWL=0.053, BAYES_00=-1.665] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: Harald Alvestrand , nea@ietf.org, iesg@ietf.org, ietf@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 >> >> > >> Lets not forget that when (not if) NEA/NAP/NAC is deployed the IDSen >> people have deployed today to >> solve the lying-client-problem by scanning for common/current >> vulnerabilities as part of the network admission >> process will have to interface with PDPs part of a NEA intfrastructure. > > Could you rephrase please? I am afraid I don't understand what you > are saying. > It has been pointed out on this list that the main deliverable from NEA might well turn out to be the way host postures are described - the schema if you will. I'm positive that if someone deployes NEA/NAP/NAC etc the admin will want to combine data from the on-client posture client with information from external IDS (etc) services to a common Policy Decision Point. That means that a reason to do NEA is to get this schema standardized even if some people who care about lying clients to never use and/or trust client posture clients. > Oh, and lying endpoint problem cannot be solved by scanning for common > vulnerabilities! In fact, the two have no relation whatsoever. They have the single relation of both expressing claims about the state of a host. Cheers Leif _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Oct 18 09:25:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaBQK-0002vB-25; Wed, 18 Oct 2006 09:25:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaBQ8-0002kt-UF for nea@ietf.org; Wed, 18 Oct 2006 09:25:20 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaBDH-0003rl-03 for nea@ietf.org; Wed, 18 Oct 2006 09:12:08 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 18 Oct 2006 09:12:03 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9IDC2ie015267; Wed, 18 Oct 2006 09:12:02 -0400 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 k9IDC1YN025297; Wed, 18 Oct 2006 09:12:02 -0400 (EDT) Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Oct 2006 09:12:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Nea] Is the WG approved? Date: Wed, 18 Oct 2006 09:12:00 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Is the WG approved? Thread-Index: AcbydsLQ/aQK4lcIR4eAqTCiNnilAgAPLKMA From: "Susan Thomson \(sethomso\)" To: "Joseph Tardo" , "Stephen Hanna" , X-OriginalArrivalTime: 18 Oct 2006 13:12:01.0838 (UTC) FILETIME=[FFEDC4E0:01C6F2B6] DKIM-Signature: a=rsa-sha1; q=dns; l=5328; t=1161177122; x=1162041122; c=relaxed/simple; s=rtpdkim1001; 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:RE=3A=20[Nea]=20Is=20the=20WG=20approved? |To:=22Joseph=20Tardo=22=20, =0A=20=20=20=20= 20=20=20=20=22Stephen=20Hanna=22=20,=20; X=v=3Dcisco.com=3B=20h=3DtaRZdPEGEYrUsDBk7UoPOFtF/BQ=3D; b=ma4//B114CEIKvlwAbULeXFGNkodkvOvcM5QBykQ1MpgPiofx6LGLE0TtyHoU0yVlxed50Sp Wtp7Xh0Qrc4KXFQ+TpIsBASEQibNiXKdVjKnAH6KfXk311c895ZptnEk; Authentication-Results: rtp-dkim-1.cisco.com; header.From=sethomso@cisco.com; dkim=pass ( 43 extraneous bytes; sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1615239002==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============1615239002== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F2B6.FFBC9EFC" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6F2B6.FFBC9EFC Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable No, it is not approved. =20 The IESG has posted an updated charter to the list. Please see my note on the updated charter. The aim is to close on the outstanding issues by the end of this week and produce a revised version that can be reviewed by the IESG at their next telechat next week. =20 Thanks Susan ________________________________ From: Joseph Tardo [mailto:joseph.tardo@nevisnetworks.com]=20 Sent: Wednesday, October 18, 2006 1:32 AM To: Stephen Hanna; nea@ietf.org Subject: [Nea] Is the WG approved? =09 =09 Steve, =20 I just noticed that NEA has appeared on the San Diego agenda for Wednesday, Nov. 8, at 9 am. =20 Does this mean the WG has been approved? =20 Thanks, --Joe ------_=_NextPart_001_01C6F2B6.FFBC9EFC Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
No, it is not approved.
 
The IESG has posted an updated charter to the = list. Please=20 see my note on the updated charter.  The aim is to close on = the=20 outstanding issues by the end of this week and produce a = revised=20 version that can be reviewed by the IESG at their next telechat next=20 week.
 
Thanks
Susan

From: Joseph Tardo=20 [mailto:joseph.tardo@nevisnetworks.com]
Sent: Wednesday, = October=20 18, 2006 1:32 AM
To: Stephen Hanna; = nea@ietf.org
Subject:=20 [Nea] Is the WG approved?

Steve,

 

I just noticed that NEA = has=20 appeared on the San Diego agenda for Wednesday, Nov. 8, at 9=20 am.

 

Does this mean the WG = has been=20 approved?

 

Thanks,

--Joe

------_=_NextPart_001_01C6F2B6.FFBC9EFC-- --===============1615239002== 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 --===============1615239002==-- From nea-bounces@ietf.org Wed Oct 18 18:04:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaJX1-000716-Ef; Wed, 18 Oct 2006 18:04:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaJ6C-0001WW-BC for nea@ietf.org; Wed, 18 Oct 2006 17:37:16 -0400 Received: from b.mail.sonic.net ([64.142.19.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaHsZ-0007f8-Jd for nea@ietf.org; Wed, 18 Oct 2006 16:19:12 -0400 Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG [168.61.10.151]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id k9IKJ4IU007627 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 18 Oct 2006 13:19:04 -0700 In-Reply-To: References: <45351F81.9000800@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <145E191A-8F7E-48F0-96AA-80C48DE3CEBE@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [Nea] Well into solution space: PA interop Date: Wed, 18 Oct 2006 13:19:24 -0700 To: Sam Hartman X-Mailer: Apple Mail (2.752.2) 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 On Oct 18, 2006, at 7:37 AM, Sam Hartman wrote: > > Douglas> 1) creator 2) class 3) user-host 4) time-stamp 5) update > resources > > How do I get a new cert if mine is expired? Go for remediation and > get it there? > > I actually like a lot of what you specify. The NEA server indicates required certificates by presenting sets of certificates where user-host is identified as "hostmaster/ ." The NEA client then offers a matching certificate for each set obtained from a variety of services such as: 1) Acknowledge AUP web-form 2) Acknowledge Deficiency web-form 3) Network Configuration 4) OS Update 5) AV Update 6) System Scan Upon completion of NEA negotiations, the granted network environment is returned. -- remediation -- When a certificate is considered expired or required by the NEA server, the service associated with the creator/update-resources generates their certificate with a relevant time-stamp only upon successful completion. The time-stamp would be relative to the service and not always the current time. When an update service detects that a related mechanism is not functioning, prior certificates it may have produced should be withdrawn from the NEA client. "Update resources" could be defined as a list of URLs. When the endpoint is placed into a walled garden, these resources are enabled to allow access to the services. Upon completion of the service, a new certificate is generated and appended to those held by the NEA client. Modifying the list of certificates could then trigger a new NEA negotiation. Once a valid certificate is presented by the NEA client, the NEA server has only one additional check to make before deciding whether to accept the certificate. Has the creator/class time-stamp expired? This may expire when a vulnerability is reported by the related service since a time-stamp or perhaps when a deficiency has been detected. This minimal structure should be suitable for any service type and use environment, without adding unneeded complexity to the NEA client/ server. Security would be reduced by exchanging service related details with NEA server. These services should be considered separate and independent of the NEA protocol, except for the service generated certificates. Service related details should not be exposed to untrusted third-parties. -Doug _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Oct 18 21:42:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaMvF-00045r-Nt; Wed, 18 Oct 2006 21:42:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaMvF-00045d-5T for nea@ietf.org; Wed, 18 Oct 2006 21:42:13 -0400 Received: from b.mail.sonic.net ([64.142.19.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaMv9-0002gY-No for nea@ietf.org; Wed, 18 Oct 2006 21:42:13 -0400 Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG [168.61.10.151]) (authenticated bits=0) by b.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id k9J1g5EP020819 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 18 Oct 2006 18:42:06 -0700 In-Reply-To: References: <45351F81.9000800@cisco.com> <145E191A-8F7E-48F0-96AA-80C48DE3CEBE@mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8D2B1447-3F75-4F34-8E51-5C5C85AC9234@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [Nea] Well into solution space: PA interop Date: Wed, 18 Oct 2006 18:42:26 -0700 To: Sam Hartman X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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 Oct 18, 2006, at 2:15 PM, Sam Hartman wrote: > You didn't really answer the question I asked. I'll try again. > I think you have the core of a really cool idea here. I strongly > urge you to find someone who cares a lot about the details of how > you get these certificates and how the overall user experience > works. The two of you should write up a concrete proposal. I > think this is well outside of what current work in the NEA space is > doing, but I think it might provide better interoperability. This concept might still fit within the NEA charter. The suggestion was to use a type of PKI certificate ("Posture-Cert") as a proxy for the "posture" details defined within the NEA descriptions. Private keys generating Posture-Certs would be held by Service servers, and not by Service clients. Service servers and clients are external to the NEA protocol. Once a Service updates the OS or AV software, does a system scan, or checks configuration settings and completes satisfactorily, a Posture- Cert is generated for the User-Host identity. This Posture-Cert is sent to the Service client at the end of the Service exchange, which is then placed into the NEA Posture-Cert repository visible to the NEA client as .nea/repo/creator--class. Posture-Certs prevent exposure of Service related details to third- parties where security might be compromised. The NEA server may decide to trust a Service server's Posture-Certs. At that point, the NEA server only needs to track when these Posture-Certs expire. Expiry could be published for each class by the creator or independently asserted by the NEA server. A user's experience could be controlled by automatically invoking related Service Update-Resources when needed, by prompting for their execution, or by offering a launching mechanism when network status indicates interaction is required. These resources are defined as URLs such as: os-update-deamon://some-os-distro.com:6002/repo/version-xyz/ A web-form service might use the URL: https://www.some-isp.com:443/members/agreement.html The web-form could inform users of their obligations when accessing the network resources being offered. Once the user agrees to the terms, the web-form prompts for a download of the created Posture- Cert then stored in the NEA client Posture-Cert repository. These Services are not part of the NEA protocol. The Service Posture- Certs Update-Resource URLs may help ensure a Service still functions when access is constrained. A Service Posture-Cert may also be needed to obtain full access. Regardless of the Service, the underlying details are not exposed, where granting access is based only upon the Posture-Cert's creator/class/time-stamp information. -Doug _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Oct 18 23:03:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaOBy-0002FW-IR; Wed, 18 Oct 2006 23:03:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga7rz-0000U8-1T for nea@ietf.org; Wed, 18 Oct 2006 05:37:51 -0400 Received: from mtagate1.uk.ibm.com ([195.212.29.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga7rx-0006xm-Gd for nea@ietf.org; Wed, 18 Oct 2006 05:37:51 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate1.uk.ibm.com (8.13.8/8.13.8) with ESMTP id k9I9biwi056126 for ; Wed, 18 Oct 2006 09:37:47 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id k9I9eCvE2527310 for ; Wed, 18 Oct 2006 10:40:12 +0100 Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k9I9bf54006944 for ; Wed, 18 Oct 2006 10:37:41 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av02.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k9I9bfmi006915; Wed, 18 Oct 2006 10:37:41 +0100 Received: from zurich.ibm.com ([9.4.210.83]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA83846; Wed, 18 Oct 2006 11:37:40 +0200 Message-ID: <4535F5E4.5060607@zurich.ibm.com> Date: Wed, 18 Oct 2006 11:37:40 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Douglas Otis Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) References: <45351F81.9000800@cisco.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 X-Mailman-Approved-At: Wed, 18 Oct 2006 23:03:33 -0400 Cc: nea@ietf.org, Eliot Lear 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 Seems like you are starting the WG discussion on the IETF list. Bad idea? (ietf list dropped) My picky comment fwiw: > 2. Vendor engine version (integer) > 3. Vendor virus definitions version (integer) These need to be strings. Version numbers are often more complex than an integer. Brian Douglas Otis wrote: > > On Oct 17, 2006, at 11:22 AM, Eliot Lear wrote: > >> I would think that five or six values are appropriate: >> >> 1. Vendor name (string) >> 2. Vendor engine version (integer) >> 3. Vendor virus definitions version (integer) >> 4. Enabled? (binary) >> 5. Buggered? (binary) >> 6. Other gobbledigook the vendor wants to include that might get >> standardized later. (blob) > > > This still seems like too much. Information offered for access can be > contained within one or more certificates. The information within > these certificates should be limited to a minimal set of values: > > 1) creator > 2) class > 3) user-host > 4) time-stamp > 5) update resources > > The essential information would be the creator/class/user-host/time- > stamp fields. When protection is not enabled or is buggered, then a > newer certificate should not be offered. The virus definitions or > patch updates can be deduced from the time-stamp or by extensions added > to class, i.e. AVX-VISTA-37. If a vulnerability is reported subsequent > to the time-stamp regarding the creator/class of service, then a new > certificate could be required. This would simplify tracking at the > access point. By keeping the information exchanged and decisions > limited to this minimal information, NEA should provide a valuable > services in many environments. > > Perhaps there should be some consideration given regarding which sets > of certificates are offered in various environments. Allowing the > certificates to be accessed beyond an authentication process seems to > increase security exposures. As this information is not trustworthy, > there would be also little gained sharing this information elsewhere. > In fact, sharing this information may increase infection rates when > this aids malware. > > -Doug > > > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Oct 18 23:03:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaOBy-0002Fr-Mx; Wed, 18 Oct 2006 23:03:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga8Jt-0005eo-RL for nea@ietf.org; Wed, 18 Oct 2006 06:06:41 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga8Jr-0001xm-Ho for nea@ietf.org; Wed, 18 Oct 2006 06:06:41 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 18 Oct 2006 03:06:39 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9IA6d0h013233; Wed, 18 Oct 2006 03:06:39 -0700 Received: from imail.cisco.com (sjc12-sbr-sw3-3f5.cisco.com [172.19.96.182]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9IA6cAo022206; Wed, 18 Oct 2006 03:06:38 -0700 (PDT) Received: from [212.254.247.5] (ams3-vpn-dhcp4259.cisco.com [10.61.80.162]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id k9I9sbTk010086; Wed, 18 Oct 2006 02:54:38 -0700 Message-ID: <4535FCAC.3020106@cisco.com> Date: Wed, 18 Oct 2006 12:06:36 +0200 From: Eliot Lear User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea) References: <45351F81.9000800@cisco.com> <4535F5E4.5060607@zurich.ibm.com> In-Reply-To: <4535F5E4.5060607@zurich.ibm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Authentication-Results: sj-dkim-4.cisco.com; header.From=lear@cisco.com; dkim=pass ( sig from cisco.com verified; ); DKIM-Signature: a=rsa-sha1; q=dns; l=1359; t=1161165999; x=1162029999; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:Eliot=20Lear=20 |Subject:Re=3A=20[Nea]=20WG=20Review=3A=20Network=20Endpoint=20Assessment=20(nea); X=v=3Dcisco.com=3B=20h=3DbSaezX0FVSS+QpzS8t3vAQ2bx2c=3D; b=ZE/CG1vDf/NQUEPZSAG9VxzOJVXBOphU77CJGGo+u+R8dmA+5hVmqvBczk8pD9+hYBEXlXxP Eg8D4re2/b0UhUGLBXET8nw5wdU09iscc8qCFXClhenoDGaVBojoxLsM; X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 X-Mailman-Approved-At: Wed, 18 Oct 2006 23:03:33 -0400 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 Brian E Carpenter wrote: > Seems like you are starting the WG discussion on the > IETF list. Bad idea? > > (ietf list dropped) > > My picky comment fwiw: > >> 2. Vendor engine version (integer) >> 3. Vendor virus definitions version (integer) > > These need to be strings. Version numbers are often more complex > than an integer. I really don't have a horse in this race, so I won't claim to know what's best. I do know that were I a network administrator I would want to say something like, "if engine name = "Norton" and engine version < X, then as an action reject or whine. Forcing the use of an = sign for version information, particularly for virus definitions, would seem suboptimal from a configuration standpoint. Obviously we at Cisco are not fond of simple integers. Consider the case of 12.2(21)XS. Fortunately, in my case I'm doing unto others and not unto ourselves ;-) Of course, one could allow for an overloaded C++esque verison of '<' and leave to implementations to understand what's earlier. But this might be overkill for the problem. Clearly the major AV people should have their say, here. Anyway, my real point to Ted was simply that I believe this problem is NOT insurmountable and I would agree with you that it is best discussed in a smaller audience, like a WG. Eliot _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Oct 18 23:03:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaOBy-0002Gc-Rl; Wed, 18 Oct 2006 23:03:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaCY4-0002qU-2a; Wed, 18 Oct 2006 10:37:36 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaCY0-0001tU-Ok; Wed, 18 Oct 2006 10:37:36 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 11EEEE0128; Wed, 18 Oct 2006 10:37:22 -0400 (EDT) From: Sam Hartman To: Douglas Otis Subject: Re: [Nea] Well into solution space: PA interop References: <45351F81.9000800@cisco.com> Date: Wed, 18 Oct 2006 10:37:22 -0400 In-Reply-To: (Douglas Otis's message of "Tue, 17 Oct 2006 15:07:26 -0700") 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: ea4ac80f790299f943f0a53be7e1a21a X-Mailman-Approved-At: Wed, 18 Oct 2006 23:03:33 -0400 Cc: nea@ietf.org, IETF Discussion , Eliot Lear 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 >>>>> "Douglas" == Douglas Otis writes: Douglas> This still seems like too much. Information offered for Douglas> access can be contained within one or more certificates. Douglas> The information within these certificates should be Douglas> limited to a minimal set of values: Douglas> 1) creator 2) class 3) user-host 4) time-stamp 5) update Douglas> resources Douglas> The essential information would be the Douglas> creator/class/user-host/time- stamp fields. When Douglas> protection is not enabled or is buggered, then a newer Douglas> certificate should not be offered. The virus definitions Douglas> or patch updates can be deduced from the time-stamp or by Douglas> extensions added to class, i.e. AVX-VISTA-37. If a Douglas> vulnerability is reported subsequent to the time-stamp Douglas> regarding the creator/class of service, then a new Douglas> certificate could be required. This would simplify Douglas> tracking at the access point. By keeping the information Douglas> exchanged and decisions limited to this minimal Douglas> information, NEA should provide a valuable services in Douglas> many environments. How do I get a new cert if mine is expired? Go for remediation and get it there? I actually like a lot of what you specify. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Oct 18 23:03:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaOBz-0002HA-0F; Wed, 18 Oct 2006 23:03:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaJ7N-0001oj-Lo; Wed, 18 Oct 2006 17:38:29 -0400 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaJ7L-0007dP-Nj; Wed, 18 Oct 2006 17:38:29 -0400 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M8IAVBENSW00JQZK@mauve.mrochek.com>; Wed, 18 Oct 2006 14:38:25 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M8I7FA638G0008CX@mauve.mrochek.com>; Wed, 18 Oct 2006 14:37:58 -0700 (PDT) To: Harald Alvestrand Message-id: <01M8IAUSZIP60008CX@mauve.mrochek.com> Date: Wed, 18 Oct 2006 14:25:35 -0700 (PDT) From: Ned Freed Subject: Re: [Nea] Re: WG Review: Network Endpoint Assessment (nea) In-reply-to: "Your message dated Tue, 17 Oct 2006 08:06:20 +0200" <453472DC.1020503@alvestrand.no> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed References: <453472DC.1020503@alvestrand.no> X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-Mailman-Approved-At: Wed, 18 Oct 2006 23:03:33 -0400 Cc: nea@ietf.org, ietf@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 > Noting the scenarios above, I claim that NEA-like functionality has > proved useful already in protecting "the computing environment of an > enterprise". I have not seen compelling evidence that it has any use in > "the layer 3 infrastructure used to carry customer traffic at an ISP". > But I think that's beside the point - the use cases for which we know > that NEA may be useful are already compelling enough that we should stop > debating whether or not to charter the group and get on with the work. > My opinion. I concur. I will also add that my concerns about this work being used outside it's domain of applicability (which as a practical matter we have little control over) pale in comparison to concerns about there being mulitple proprietary schemes for this sort of thing. The last thing we need to be doing is encouraging monocultures through the work we do (or don't) do. I also think this discussion is well over the line of charter debate and into the realm of protocol design. Let's finalize the charter (I thought the latest proposed text regarding scope looked fine) and do the protocol work in the WG. Ned _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Oct 18 23:03:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaOBz-0002HZ-6f; Wed, 18 Oct 2006 23:03:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaJ4H-0001LT-2Y for nea@ietf.org; Wed, 18 Oct 2006 17:35:17 -0400 Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaIlF-0005Lo-AK for nea@ietf.org; Wed, 18 Oct 2006 17:15:38 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 44315E0127; Wed, 18 Oct 2006 17:15:29 -0400 (EDT) From: Sam Hartman To: Douglas Otis Subject: Re: [Nea] Well into solution space: PA interop References: <45351F81.9000800@cisco.com> <145E191A-8F7E-48F0-96AA-80C48DE3CEBE@mail-abuse.org> Date: Wed, 18 Oct 2006 17:15:29 -0400 In-Reply-To: <145E191A-8F7E-48F0-96AA-80C48DE3CEBE@mail-abuse.org> (Douglas Otis's message of "Wed, 18 Oct 2006 13:19:24 -0700") 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.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 X-Mailman-Approved-At: Wed, 18 Oct 2006 23:03:33 -0400 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 You didn't really answer the question I asked. I think you have the core of a really cool idea here. I strongly erge you to find someone who cares a lot about the details of how you get these certificates and how the overall user experience works. The two of you should write up a concrete proposal. I think this is well outside of what current work in the NEA space is doing, but I think it might provide better interoperability. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Oct 19 04:57:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaTil-000724-8d; Thu, 19 Oct 2006 04:57:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaTii-0006zv-Np for nea@ietf.org; Thu, 19 Oct 2006 04:57:44 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaTZ1-0000a5-6V for nea@ietf.org; Thu, 19 Oct 2006 04:47:45 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7D00DNZKL5AP@szxga01-in.huawei.com> for nea@ietf.org; Thu, 19 Oct 2006 16:51:05 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7D00774KL39V@szxga01-in.huawei.com> for nea@ietf.org; Thu, 19 Oct 2006 16:51:05 +0800 (CST) Received: from y34728 ([10.110.108.66]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J7D007QMKZWNK@szxml04-in.huawei.com> for nea@ietf.org; Thu, 19 Oct 2006 16:59:56 +0800 (CST) Date: Thu, 19 Oct 2006 16:46:28 +0800 From: Yin Han To: nea@ietf.org Message-id: <00b401c6f35b$11c16ba0$426c6e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Mailer: Microsoft Outlook Express 5.50.4927.1200 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.3 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Subject: [Nea] What's the relationship betweetn vendor-specific attributes and interoprability? 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="===============0003336166==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============0003336166== Content-type: multipart/alternative; boundary="Boundary_(ID_OBRZ9ImxUhKdnSM/28CtoA)" This is a multi-part message in MIME format. --Boundary_(ID_OBRZ9ImxUhKdnSM/28CtoA) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Hi What's the relationship betweetn vendor-specific attributes and interoprability? In NEA architecture, more than one Posture Collector(PC) will be installed on one NEA client. Centainly, the different PC will collect informaiton about different area on the NEA client. Since NEA WG is expected to realize the interoperability between the PC and Posture Validators(PV) from dfifferent vendor, a NEA client that complies with the security policy of a network owner should get the access to the network no matter what PC is installed on it. Is it ture? On the other words, a NEA client that installed PC provided by corporation_a can get the access to network of Corporation_a ,corporation_b or corporation_c if it is compliant to their policies. My question is whether this scenario is practical? Will a corpration grant the NEA client installing another corporation PC the access to its own network? In my opinion, every corporation can have its own policy. So, the corporation may consider that only the PC developed by itself can provide the information it take care. In NEA Architecture,these particular informations should be classified as vendor-specific attributes. I am apprehensive that most functions would be completed through vendor-specific attributes and standard attributes are only basic information. If NEA allows too much flexibility originated from vendor-specific attributes, could we realize the interoprability between "an NEA Client from one vendor and an NEA Server from another"? If a PV can not make assessment without its own vendor-specific attributes, the NEA client must install the PC from the same vendor that provides the PV. Because there would be no such a PC that can support all kinds of vendor-specific attributes if these vendor-specific attributes are major in PA-level. Thearefore, as the the figure in requirement doccument, the PC and PV always appear in pair. Additionally, whether an endpoint could access the corporation network lies on whether the endpoint installed the PC provided by the corporation but not whether the endpoint is compliant to the corporation secutiry policy. Therefore, the statment should be added into the charter:"To realize interoperability, the most attributes are standard in PA-level and PV must be able to make such assessment that NEA server can permit the NEA cllient to access the network even though the PC could not provide the vendor-specific attributes." If we can not reach it, the interoperability will be impractical. --Boundary_(ID_OBRZ9ImxUhKdnSM/28CtoA) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
Hi
  What's the relationship betweetn vendor-specific attributes and interoprability?
  In NEA architecture, more than one Posture Collector(PC) will be installed on one NEA client. Centainly, the different PC will collect informaiton about different area on the NEA client. Since NEA WG is expected to realize the interoperability between the PC and Posture Validators(PV) from dfifferent vendor, a NEA client that complies with the security policy of a network owner should get the access to the network no matter what PC is installed on it. Is it ture?
  On the other words, a NEA client that installed PC provided by corporation_a can get the access to network of Corporation_a ,corporation_b or corporation_c if it is compliant to their policies. My question is whether this scenario is practical? Will a corpration grant the NEA client installing another corporation PC the access to its own network?
  In my opinion, every corporation can have its own policy. So, the corporation may consider that only the PC developed by itself can provide the information it take care. In NEA Architecture,these particular informations should be classified as vendor-specific attributes. I am apprehensive that most functions would be completed through vendor-specific attributes and standard attributes are only basic information. If NEA allows too much flexibility originated from vendor-specific attributes, could we realize the interoprability between "an NEA Client from one vendor and an NEA Server from another"?
  If a PV can not make  assessment without its own vendor-specific attributes, the NEA client must install the PC from the same vendor that provides the PV. Because there would be no such a PC that can support all kinds of vendor-specific attributes if these vendor-specific attributes are major in PA-level. Thearefore, as the the figure in requirement doccument, the PC and PV always appear in pair. Additionally, whether an endpoint could access the corporation network lies on whether the endpoint installed the PC provided by the corporation but not whether the endpoint is compliant to the corporation secutiry policy.
  Therefore, the statment should be added into the charter:"To realize interoperability, the most attributes are standard in PA-level and PV must be able to make such assessment that NEA server can permit the NEA cllient to access the network even though the PC could not provide the vendor-specific attributes." If we can not reach it, the interoperability will be impractical.
--Boundary_(ID_OBRZ9ImxUhKdnSM/28CtoA)-- --===============0003336166== 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 --===============0003336166==-- From nea-bounces@ietf.org Thu Oct 19 09:14:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaXjL-0005Rs-Ur; Thu, 19 Oct 2006 09:14:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaXjK-0005Op-Fo for nea@ietf.org; Thu, 19 Oct 2006 09:14:38 -0400 Received: from wx-out-0506.google.com ([66.249.82.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaXjE-0001xo-RD for nea@ietf.org; Thu, 19 Oct 2006 09:14:38 -0400 Received: by wx-out-0506.google.com with SMTP id h30so673994wxd for ; Thu, 19 Oct 2006 06:14:32 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=VY3aCIUQzJgdu0MFyKPFJokOiq4HO9bJgxV9jNx/ig9lEFr9YsvT1gPm1ubbxcQapE9QfNmB0Ll6H181YA6Fhh0F5RfYlCwP016LHVzEurSdNm0+aTKyST46sF+KHrqG648FHtl0ysh9gJS7FuBHUx18gbPw1Gmc09MpnqdO6ZA= Received: by 10.70.103.12 with SMTP id a12mr18352302wxc; Thu, 19 Oct 2006 06:14:32 -0700 (PDT) Received: by 10.65.156.6 with HTTP; Thu, 19 Oct 2006 06:14:31 -0700 (PDT) Message-ID: Date: Thu, 19 Oct 2006 09:14:31 -0400 From: "Mike Fratto" To: "Sam Hartman" , nea@ietf.org Subject: Re: [Nea] Well into solution space: PA interop In-Reply-To: <8D2B1447-3F75-4F34-8E51-5C5C85AC9234@mail-abuse.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45351F81.9000800@cisco.com> <145E191A-8F7E-48F0-96AA-80C48DE3CEBE@mail-abuse.org> <8D2B1447-3F75-4F34-8E51-5C5C85AC9234@mail-abuse.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed 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 > The suggestion was to use a type of PKI certificate ("Posture-Cert") > as a proxy for the "posture" details defined within the NEA > descriptions. Private keys generating Posture-Certs would be held by > Service servers, and not by Service clients. Service servers and > clients are external to the NEA protocol. Or you can just roll out Microsoft's Network Access Protection. :) _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Oct 19 09:25:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaXto-0003BX-QD; Thu, 19 Oct 2006 09:25:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaXto-0003BP-Eg for nea@ietf.org; Thu, 19 Oct 2006 09:25:28 -0400 Received: from nz-out-0102.google.com ([64.233.162.201]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaXtf-0004IB-UD for nea@ietf.org; Thu, 19 Oct 2006 09:25:28 -0400 Received: by nz-out-0102.google.com with SMTP id q3so261605nzb for ; Thu, 19 Oct 2006 06:25:19 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pjtJaruq2uxJHbKi8PDk+ua5jB79kOxesRwDEyvXpq5WqZPImf0pAK1Gxz1uNAs/GOvU3YhGzxHjM5WxxZhqxJKbiqztUACLHZxkrFx+fypUD7C85SZlG8+8E+aeIZrNl4EnypkhZ1uNe0msHZkrvzcwJyBHiGQAj9S3CKOipcM= Received: by 10.65.214.19 with SMTP id r19mr733817qbq; Thu, 19 Oct 2006 06:25:19 -0700 (PDT) Received: by 10.65.156.6 with HTTP; Thu, 19 Oct 2006 06:25:19 -0700 (PDT) Message-ID: Date: Thu, 19 Oct 2006 09:25:19 -0400 From: "Mike Fratto" To: "Yin Han" Subject: Re: [Nea] What's the relationship betweetn vendor-specific attributes and interoprability? In-Reply-To: <00b401c6f35b$11c16ba0$426c6e0a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <00b401c6f35b$11c16ba0$426c6e0a@china.huawei.com> X-Spam-Score: 0.0 (/) 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 > Therefore, the statment should be added into the charter:"To realize > interoperability, the most attributes are standard in PA-level and PV must > be able to make such assessment that NEA server can permit the NEA cllient > to access the network even though the PC could not provide the > vendor-specific attributes." If we can not reach it, the interoperability > will be impractical. Yin, I think what your talking about is an implementation and local policy issue, and not a interoperation issue, and therefore not really an issue for standardization. Whether a foreign computer is allowed to provide it's own posture assessment is a matter of local policy for the trusting company. That the posture collectors and posture validators can exchange information is a matter of standardization to that point that the formats are standardized for attribute exchange but not necessarily the meaning of those attributes. RADIUS attribute extensions work in a similar manner and probably provides a decent model to work off of. mike _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Oct 19 10:07:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaYYi-0007Z1-7F; Thu, 19 Oct 2006 10:07:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaQ9Q-0001SC-0b for nea@ietf.org; Thu, 19 Oct 2006 01:09:04 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaQ9O-0000Sj-MG for nea@ietf.org; Thu, 19 Oct 2006 01:09:03 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id D3E92E0127; Thu, 19 Oct 2006 01:08:53 -0400 (EDT) From: Sam Hartman To: Douglas Otis Subject: Re: [Nea] Well into solution space: PA interop References: <45351F81.9000800@cisco.com> <145E191A-8F7E-48F0-96AA-80C48DE3CEBE@mail-abuse.org> <8D2B1447-3F75-4F34-8E51-5C5C85AC9234@mail-abuse.org> Date: Thu, 19 Oct 2006 01:08:53 -0400 In-Reply-To: <8D2B1447-3F75-4F34-8E51-5C5C85AC9234@mail-abuse.org> (Douglas Otis's message of "Wed, 18 Oct 2006 18:42:26 -0700") 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: e5ba305d0e64821bf3d8bc5d3bb07228 X-Mailman-Approved-At: Thu, 19 Oct 2006 10:07:43 -0400 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 >>>>> "Douglas" == Douglas Otis writes: Douglas> On Oct 18, 2006, at 2:15 PM, Sam Hartman wrote: >> You didn't really answer the question I asked. Douglas> I'll try again. Still failed. You are failing to focus on the detail that NEA intends to run *before* network access. The obvious implementation of what you are proposing depends on network access to work. But I don't need an answer at this point. I've been convinced that I personally think the idea is worth developing as something for NEA to consider. >> I think you have the core of a really cool idea here. I >> strongly urge you to find someone who cares a lot about the >> details of how you get these certificates and how the overall >> user experience works. The two of you should write up a >> concrete proposal. I think this is well outside of what >> current work in the NEA space is doing, but I think it might >> provide better interoperability. Douglas> This concept might still fit within the NEA charter. I believe it does. I don't think it is what NEA proponents were thinking of when they proposed the charter but I think it falls within the charter. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Oct 19 10:45:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaZ99-0000IA-BQ; Thu, 19 Oct 2006 10:45:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaZ97-0000HR-St; Thu, 19 Oct 2006 10:45:21 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaZ8C-0002f5-Sc; Thu, 19 Oct 2006 10:44:28 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 19 Oct 2006 07:41:51 -0700 X-IronPort-AV: i="4.09,330,1157353200"; d="scan'208"; a="604262763:sNHT29819220" 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] WG Review: Network Endpoint Assessment (nea) Date: Thu, 19 Oct 2006 10:44:23 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] WG Review: Network Endpoint Assessment (nea) Thread-index: AcbySnf9kAb6yNBnQeuHML30VoAk6wBQZ3kA From: "Stephen Hanna" To: "Ted Hardie" , "Eliot Lear" X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: nea@ietf.org, Sam Hartman , ietf@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 Ted Hardie wrote: > For the charter discussions, I want to know whether it will > be an aim of the working group to standardize: > > * a way of carrying this information > * the structure of this information (but not its content) > * a standard representation of the content, so that access to the vendor database > is no longer required I believe that we'll need to define all three of these. There may be times when access to an external database would be useful (if you want to know exactly which viruses are covered by which AV defs version, for example) but such access should not be required to use the standard attributes. Thanks, Steve _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Oct 19 13:11:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GabQ9-00052A-1H; Thu, 19 Oct 2006 13:11:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GabQ7-00051y-Sp for nea@ietf.org; Thu, 19 Oct 2006 13:11:03 -0400 Received: from a.mail.sonic.net ([64.142.16.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GabI7-0003Nv-Od for nea@ietf.org; Thu, 19 Oct 2006 13:02:50 -0400 Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG [168.61.10.151]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id k9JH2jtx025403 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 19 Oct 2006 10:02:47 -0700 In-Reply-To: References: <45351F81.9000800@cisco.com> <145E191A-8F7E-48F0-96AA-80C48DE3CEBE@mail-abuse.org> <8D2B1447-3F75-4F34-8E51-5C5C85AC9234@mail-abuse.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <13F08F8A-4EB0-4F98-AA70-C524ACB2E9E6@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [Nea] Well into solution space: PA interop Date: Thu, 19 Oct 2006 10:03:07 -0700 To: Sam Hartman X-Mailer: Apple Mail (2.752.2) 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 Oct 18, 2006, at 10:08 PM, Sam Hartman wrote: > Douglas> On Oct 18, 2006, at 2:15 PM, Sam Hartman wrote: > >>> You didn't really answer the question I asked. > > Douglas> I'll try again. > > Still failed. > > You are failing to focus on the detail that NEA intends to run > *before* network access. The obvious implementation of what you > are proposing depends on network access to work. But I don't need > an answer at this point. I've been convinced that I personally > think the idea is worth developing as something for NEA to consider. Understood. NEA can be used as a method to prompt for remediation where non-essential services are constrained until these needed Services have been preformed. Normally Posture-Certs are obtained in the background during normal use. When walled-garden or sandbox techniques are not available or considered adequate, then another mode of network operation can be used. Part of the NEA protocol may include a network tunnel. This tunnel could work much like SSH with port forwarding. This tunnel allows only the connections found in the Posture-Certs Update-Resources presented by the NEA server. The changes required to accommodate hundreds of existing Services that could become a component of NEA requirements are thereby minimized. -Doug _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Oct 19 14:26:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gacao-0002iA-Qx; Thu, 19 Oct 2006 14:26:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gacan-0002gL-U4 for nea@ietf.org; Thu, 19 Oct 2006 14:26:09 -0400 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 1GacPj-00012d-DO for nea@ietf.org; Thu, 19 Oct 2006 14:14:45 -0400 Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id E12A816CE0; Thu, 19 Oct 2006 14:04:02 -0400 (EDT) From: "Alan DeKok" To: Douglas Otis Subject: Re: [Nea] Well into solution space: PA interop In-Reply-To: Your message of "Thu, 19 Oct 2006 10:03:07 PDT." <13F08F8A-4EB0-4F98-AA70-C524ACB2E9E6@mail-abuse.org> Date: Thu, 19 Oct 2006 14:04:02 -0400 Message-Id: <20061019180402.E12A816CE0@mail.nitros9.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: nea@ietf.org, 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 Douglas Otis wrote: > Part of the NEA protocol may include a network tunnel. This tunnel > could work much like SSH with port forwarding. Or 802.1x, which already sets up an SSL tunnel between the end machine and a AAA server. The AAA server is already doing authentication and authorization. AAA servers already perform a limited form of assesment and control of end devices. Adding posture assessment and remediation isn't much of a stretch. 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 Mon Oct 23 22:48:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcCLI-0001eq-Tu; Mon, 23 Oct 2006 22:48:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcCLI-0001cr-0a for nea@ietf.org; Mon, 23 Oct 2006 22:48:40 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcCLG-00045y-5h for nea@ietf.org; Mon, 23 Oct 2006 22:48:39 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7M00CIMDB5G2@szxga01-in.huawei.com> for nea@ietf.org; Tue, 24 Oct 2006 10:52:17 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7M00FM1DB4FT@szxga01-in.huawei.com> for nea@ietf.org; Tue, 24 Oct 2006 10:52:17 +0800 (CST) Received: from lenovo6424df74 ([10.78.36.131]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J7M00IOZDDWLM@szxml03-in.huawei.com> for nea@ietf.org; Tue, 24 Oct 2006 10:53:56 +0800 (CST) Date: Tue, 24 Oct 2006 10:47:23 +0800 From: yinhan Subject: Re: [Nea] What's the relationship betweetn vendor-specific attributes and interoprability? To: mfratto@gmail.com, nea@ietf.org Message-id: <007c01c6f716$c29c9260$83244e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <01b601c6f68b$930e1ae0$83244e0a@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Hi Mike I think it is about the depth of interoperability. Vendor-specific attributes should be minor. Additionally, The NEA Server should not deny the NEA Client because the endpoint can not provide vendor-specific attribute. If that, the posture validator will only have to interoperate well with the posture collector that can give the vendor-specific attribute the validator requires and and complete the normal function. Therefore, the most attributes should be standardized, and the standardized attributes should include the binding of version, update time and threads > ----- Original Message ----- > From: "Mike Fratto" > To: "Yin Han" > Cc: > Sent: Thursday, October 19, 2006 9:25 PM > Subject: Re: [Nea] What's the relationship betweetn vendor-specific attributes and interoprability? > > >>> Therefore, the statment should be added into the charter:"To realize >>> interoperability, the most attributes are standard in PA-level and PV must >>> be able to make such assessment that NEA server can permit the NEA cllient >>> to access the network even though the PC could not provide the >>> vendor-specific attributes." If we can not reach it, the interoperability >>> will be impractical. >> >> Yin, I think what your talking about is an implementation and local >> policy issue, and not a interoperation issue, and therefore not really >> an issue for standardization. >> >> Whether a foreign computer is allowed to provide it's own posture >> assessment is a matter of local policy for the trusting company. >> >> That the posture collectors and posture validators can exchange >> information is a matter of standardization to that point that the >> formats are standardized for attribute exchange but not necessarily >> the meaning of those attributes. >> >> RADIUS attribute extensions work in a similar manner and probably >> provides a decent model to work off of. >> >> mike _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 24 02:15:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcFZA-0006nM-Pa; Tue, 24 Oct 2006 02:15:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcFZ8-0006mp-DH; Tue, 24 Oct 2006 02:15:10 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcFZ5-0004K6-P1; Tue, 24 Oct 2006 02:15:10 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k9O6F5p1001966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 23 Oct 2006 23:15:06 -0700 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k9O6F4R5009145; Mon, 23 Oct 2006 23:15:05 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Oct 2006 23:15:03 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) Date: Mon, 23 Oct 2006 23:14:54 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) Thread-Index: AcbyJ9pT4Qs5Q6ljRB2oCe4NXvzMFwFClSFQ From: "Narayanan, Vidya" To: , X-OriginalArrivalTime: 24 Oct 2006 06:15:03.0719 (UTC) FILETIME=[BE724370:01C6F733] X-Spam-Score: 0.0 (/) X-Scan-Signature: f884eb1d4ec5a230688d7edc526ea665 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, This charter is definitely clearer on some of the points that were discussed based on the last version, but a couple of things still remain to be clarified. Based on several discussions that we've had lately, I have two suggestions for further clarity:=20 1. Let's add the text suggested by Harald and Lakshminath (there seemed to be agreement on this text on the list). Quoting the change proposed:=20 Replace: "NEA can be limited in its applicability when the endpoint and the organization providing network access are owned by different parties." with "NEA is applicable to computing environments of enterprises 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 2. On the mandatory-to-implement PT protocol, I would like to see the clarification that the protocol must allow the NEA process to run either at the time of network access or while connected. This clarification seems mainly needed because there is text elsewhere in the charter about allowing NEA runs "at network access or while connected" - if that text is removed, this clarification won't be required.=20 Thanks, Vidya > -----Original Message----- > From: IESG Secretary [mailto:iesg-secretary@ietf.org]=20 > Sent: Tuesday, October 17, 2006 12:50 PM > To: ietf-announce@ietf.org > Cc: nea@ietf.org > Subject: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)=20 >=20 > A new IETF working group has been proposed in the Security Area. =20 > The IESG has not made any determination as yet. The following=20 > UPDATED draft charter was submitted, and is provided for=20 > informational purposes only. Please send your comments to the=20 > IESG mailing list (iesg@ietf.org) by October 23rd. >=20 > +++ >=20 > Network Endpoint Assessment (nea) > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Current Status: Proposed Working Group >=20 > Chair(s):=20 > TBD >=20 > Security Area Director(s): > Russ Housley > Sam Hartman >=20 > Security Area Advisor: > Russ Housley >=20 > Mailing List: nea@ietf.org >=20 > Description of Working Group: >=20 > Network Endpoint Assessment (NEA) architectures have been=20 > implemented in the industry to assess the "posture" of=20 > endpoint devices for the purposes of monitoring compliance to=20 > an organization's posture policy and optionally restricting=20 > access until the endpoint has been updated to satisfy the=20 > posture requirements. An endpoint that does not comply with=20 > posture policy may be vulnerable to a number of known threats=20 > that may exist on the network. The intent of NEA is to=20 > facilitate corrective actions to address these known=20 > vulnerabilities before a host is exposed to potential attack.=20 > Note that an endpoint that is deemed compliant may still be=20 > vulnerable to unknown threats that may exist on the network.=20 > The network may thus continue to be exposed to such threats=20 > as well as the range of other threats not addressed by=20 > maintaining endpoint compliance. >=20 > Posture refers to the hardware or software configuration of=20 > an endpoint as it pertains to an organization's security=20 > policy. Posture may include knowledge that software installed=20 > to protect the machine (e.g. patch management software,=20 > anti-virus software, host firewall software, host intrusion=20 > protection software or any custom software) is enabled and=20 > up-to-date. On network access and while connected, an=20 > endpoint supporting NEA protocols can be queried for such=20 > posture information. >=20 > An organization may make a range of policy decisions based on=20 > the posture of an endpoint. NEA is not intended to be=20 > prescriptive in this regard. Supported deployment scenarios=20 > will include, but are not limited to, providing normal access=20 > regardless of compliance result along with any=20 > recommendations for remediation ("advisory mode"), as well as=20 > providing restricted access sufficient for remediation=20 > purposes and any essential services until an endpoint is in=20 > compliance ("mandatory mode"). >=20 > Since NEA involves many different components from different=20 > vendors, interoperability is important. The priority of the=20 > NEA working group is to develop standard protocols at the=20 > higher layers in the > architecture: the Posture Attribute protocol (PA) and the=20 > Posture Broker protocol (PB). PA and PB will be designed to=20 > support a variety of lower layer protocols. When used with=20 > standards for lower layers, the PA and PB protocols will=20 > allow interoperability between an NEA Client from one vendor=20 > and an NEA Server from another. >=20 > Since there are already several non-standard protocols at=20 > these higher layers, the NEA working group will consider=20 > these existing protocols as candidates for the standard=20 > protocols. A requirements document will be written and used=20 > as a basis for evaluating the candidate protocols. The=20 > working group may decide to standardize one of the candidate=20 > protocols, use one of them as a basis for a new or revised=20 > protocol, or decide that a new protocol is needed. >=20 > The NEA Requirements document will include a problem=20 > statement, definition of terms, requirements for the PA and=20 > PB protocols, and an overall security analysis. It will also=20 > include generic requirements for the protocol transporting=20 > PA, PB: the Posture Transport protocol (PT). PT protocols may=20 > be standardized in other WGs since these protocols may not be=20 > specific to NEA. The NEA WG will identify one mandatory to=20 > implement PT protocol to ensure interoperability. >=20 > The PA (Posture Attribute) protocol consists of posture=20 > attributes that are carried between a particular Posture=20 > Collector in a NEA client and a particular Posture Validator=20 > in a NEA Server. The PA protocol is carried inside the PB=20 > protocol. A base set of standard posture attributes will be=20 > specified. Vendor-specific attributes will also be supported,=20 > but vendor-specific attributes must be documented in an RFC. >=20 > The PB (Posture Broker) protocol aggregates posture=20 > attributes from one or more Posture Collectors in an NEA=20 > client and sends them to the NEA server for assessment by one=20 > or more Posture Validators. >=20 > The PT (Posture Transport) protocol carries the PB protocol. >=20 > The NEA working group will not specify protocols other than=20 > PA and PB at this time. The expectation is that an existing=20 > protocol can be used for the PT. >=20 > One commonly discussed issue with NEA systems is how to=20 > handle compromised endpoints, whose reports of their own=20 > posture may not be accurate. Detecting or handling such=20 > endpoints is out of scope of the NEA WG. Work on PA will=20 > focus on attributes useful for assessing posture of those=20 > endpoints reporting accurate information. However, the=20 > protocols developed by the NEA WG must be designed to=20 > accommodate emerging technologies for identifying and dealing=20 > with lying endpoints. >=20 > Note that NEA is not chartered to develop standard protocols=20 > for remediation. NEA is intended to be used with new or=20 > existing tools that can be used in the absence of NEA. NEA=20 > can be limited in its applicability when the endpoint and the=20 > organization providing network access are owned by different=20 > parties. NEA applicability and security considerations will=20 > be described in the appropriate NEA documents. >=20 > Further work in the NEA WG will be considered via the=20 > rechartering process after the completion of these milestones. >=20 > Milestones: >=20 > October 2006: > * Submit first draft of NEA Requirements I-D >=20 > November 2006: > * At IETF 67, discuss issues with NEA Requirements I-D > * Agree on solutions to issues with NEA Requirements I-D >=20 > December 2007: > * Submit revised requirements I-D >=20 > February 2007: > * WGLC on NEA Requirements I-D > * Deadline for submission of candidate specs for PA and PB >=20 > March 2007: > * At IETF 68, resolve outstanding issues with requirements I-D > * Report from NEA protocol evaluation team >=20 > April 2007: > * Submit NEA Evaluation I-D >=20 > June 2007: > * Submit revised NEA Evaluation I-D > * WGLC on NEA Evaluation I-D >=20 > July 2007: > * At IETF 69, review outstanding comments on evaluation I-D >=20 > August 2007: > * Submit first draft of PA and PB spec >=20 > October 2007: > * Submit revised draft of PA and PB spec > * Decide how to address MTI PT, recharter if needed >=20 > December 2007: > * At IETF70, discuss and resolve issues with PA and PB spec >=20 > February 2008: > * WGLC on PA and PB spec >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 24 07:43:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcKgb-0004WF-Rj; Tue, 24 Oct 2006 07:43:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcKgY-0004Uj-R8; Tue, 24 Oct 2006 07:43:10 -0400 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcKgV-00085T-Q2; Tue, 24 Oct 2006 07:43:10 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=lJyn/ihC5I/qqD5cTOzIPuQvgqGZQW34y3kuaEYaXNrkjilGRJYuGpTAXZmvp1mP; 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.54] (helo=gw) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GcKgS-000282-Fe; Tue, 24 Oct 2006 07:43:06 -0400 Message-ID: <002601c6f761$92f9f160$010aa8c0@home.glassey.com> From: "todd glassey" To: "Narayanan, Vidya" , , References: Subject: Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) Date: Tue, 24 Oct 2006 04:43:02 -0700 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: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec7925649b1a444a46797fe2fba0d6b2cfb2350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.246.45.54 X-Spam-Score: 0.0 (/) X-Scan-Signature: 681e62a2ce9b0804b459fe780d892beb Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Vidya is it your intent to build an auditing protocol without auditors and under the formal qualifications for an Audit Personnel??? OK, cool - by the way, I would like to know how many company's any of you have audited? Its an important question... especially for Harald. I am betting NONE is the answer, and that speaks for itself. My rework on the proposed change #1 below... Todd Glassey - as a Certified Auditor and Forensic Investigator. ----- Original Message ----- From: "Narayanan, Vidya" To: ; Cc: Sent: Monday, October 23, 2006 11:14 PM Subject: RE: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) All, This charter is definitely clearer on some of the points that were discussed based on the last version, but a couple of things still remain to be clarified. Based on several discussions that we've had lately, I have two suggestions for further clarity: 1. Let's add the text suggested by Harald and Lakshminath (there seemed to be agreement on this text on the list). Quoting the change proposed: Replace: "NEA can be limited in its applicability when the endpoint and the organization providing network access are owned by different parties." (TSG: THIS IS A STATEMENT OF A CONTROL, although its poorly written for that) with "NEA is applicable to computing environments of enterprises 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." (TSG: THIS IS A STATEMENT OF CAPABILITY) - TSG: 1) HOW ABOUT: --------------------- "NEA is a Policy Compliance Tool-set applicable to computing environments across both heterogenous and homogeneous enviornment's with differing policy constraints to them." WHY? The issue setting a boundry at the permiter of the Organization is inaccurate from an Auditing Perspective which the NEA is a key part of. Any NEA designs and deployments that do not address the auditing or controls of the Industry like COBIT DS and ME Control Activities is not likely to gain acceptance, since this product cannot go into use, until it addresses what in the Audit Profile and how its to work for the Audit Attestations. So... What does the Use of NEA do for the Auditability of IT departments. -------------------- 2. On the mandatory-to-implement PT protocol, I would like to see the clarification that the protocol must allow the NEA process to run either at the time of network access or while connected. This clarification seems mainly needed because there is text elsewhere in the charter about allowing NEA runs "at network access or while connected" - if that text is removed, this clarification won't be required. Thanks, Vidya > -----Original Message----- > From: IESG Secretary [mailto:iesg-secretary@ietf.org] > Sent: Tuesday, October 17, 2006 12:50 PM > To: ietf-announce@ietf.org > Cc: nea@ietf.org > Subject: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) > > A new IETF working group has been proposed in the Security Area. > The IESG has not made any determination as yet. The following > UPDATED draft charter was submitted, and is provided for > informational purposes only. Please send your comments to the > IESG mailing list (iesg@ietf.org) by October 23rd. > > +++ > > Network Endpoint Assessment (nea) > =================================== > > Current Status: Proposed Working Group > > Chair(s): > TBD > > Security Area Director(s): > Russ Housley > Sam Hartman > > Security Area Advisor: > Russ Housley > > Mailing List: nea@ietf.org > > Description of Working Group: > > Network Endpoint Assessment (NEA) architectures have been > implemented in the industry 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. An endpoint that does not comply with > posture policy may be vulnerable to a number of known threats > that may exist on the network. The intent of NEA is to > facilitate corrective actions to address these known > vulnerabilities before a host is exposed to potential attack. > Note that an endpoint that is deemed compliant may still be > vulnerable to unknown 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. > > Posture refers to the hardware or software configuration of > an endpoint as it pertains to an organization's security > 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. On network access and while connected, an > endpoint supporting NEA protocols can be queried for such > posture information. > > 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"). > > 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 one mandatory to > implement PT protocol to ensure interoperability. > > 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. Vendor-specific attributes will also be supported, > but vendor-specific attributes must be documented in an RFC. > > 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 > can be limited in its applicability when the endpoint and the > organization providing network access are owned by different > parties. 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: > > October 2006: > * Submit first draft of NEA Requirements I-D > > November 2006: > * At IETF 67, discuss issues with 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 > * Deadline for submission of candidate specs for PA and PB > > March 2007: > * At IETF 68, resolve outstanding issues with requirements I-D > * Report from NEA protocol evaluation team > > April 2007: > * Submit NEA Evaluation I-D > > June 2007: > * Submit revised NEA Evaluation I-D > * WGLC on NEA Evaluation I-D > > July 2007: > * At IETF 69, review outstanding comments on evaluation I-D > > August 2007: > * Submit first draft of PA and PB spec > > October 2007: > * Submit revised draft of PA and PB spec > * Decide how to address MTI PT, recharter if needed > > December 2007: > * At IETF70, discuss and resolve issues with PA and PB spec > > February 2008: > * WGLC on PA and PB spec > > _______________________________________________ > 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 Tue Oct 24 09:05:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcLy9-0004hQ-9v; Tue, 24 Oct 2006 09:05:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcLy7-0004hH-LA for nea@ietf.org; Tue, 24 Oct 2006 09:05:23 -0400 Received: from nz-out-0102.google.com ([64.233.162.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcLy3-0006aa-BH for nea@ietf.org; Tue, 24 Oct 2006 09:05:23 -0400 Received: by nz-out-0102.google.com with SMTP id 13so718284nzn for ; Tue, 24 Oct 2006 06:05:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YW7nh9FnLm6BMq6gV5LDrKaVulj4CMwtLRERBuXhBTRjgORn2NhH8xLwAlwVSIwdgCXbzN39PTOsfRUiVKY9kMAN3ehglNZ/R5jcE8BW70jS79uojeDvqB6AJZzrUl1SShWop1eSQN0a7DFx/IVNyS1KtTujoTHNqMLCfnAxV+E= Received: by 10.65.191.7 with SMTP id t7mr7358206qbp; Tue, 24 Oct 2006 06:05:18 -0700 (PDT) Received: by 10.65.156.6 with HTTP; Tue, 24 Oct 2006 06:05:18 -0700 (PDT) Message-ID: Date: Tue, 24 Oct 2006 09:05:18 -0400 From: "Mike Fratto" To: yinhan Subject: Re: [Nea] What's the relationship betweetn vendor-specific attributes and interoprability? In-Reply-To: <007c01c6f716$c29c9260$83244e0a@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <01b601c6f68b$930e1ae0$83244e0a@china.huawei.com> <007c01c6f716$c29c9260$83244e0a@china.huawei.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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 hear what your saying, but what your describing is a local security policy issue, not whether a client and server can exchange data. It is an important issue, to be sure, but not really an IETF concern. How a company chooses to handle exceptions, in this case, an NEA client that doens't have all the attributes that Validator wants, is defined by the policy. RADIUS has a similar issue. The data formats and some attributes are defined, but the vendor extensions are not. Therefore, supporting vendor extensions falls on the posture validation vendors in a similar manner that RADIUS server vendors had to import the vendor specific dictionaries. There are two perspectives on interoperation. The first is can a component from vendor A exchange information with a component from vendor B, ie, are the data formats and protocols defined and properly implemneted? That interoperation eases product development. The other perspective you are describing is does product A support product B, and for customers of these vendors, that becomes a differentiator in aking a buying decision. In theory, vendor A and vendor B should be able to ineroperate quickly. On 10/23/06, yinhan wrote: > Hi Mike > I think it is about the depth of interoperability. > Vendor-specific attributes should be minor. Additionally, The NEA Server > should not deny the NEA Client because the endpoint can not provide > vendor-specific attribute. If that, the posture validator will only have to interoperate > well with the posture collector that can give the vendor-specific attribute the validator > requires and and complete the normal function. Therefore, the most attributes should be > standardized, and the standardized attributes should include the binding of version, > update time and threads > > > > > > ----- Original Message ----- > > From: "Mike Fratto" > > To: "Yin Han" > > Cc: > > Sent: Thursday, October 19, 2006 9:25 PM > > Subject: Re: [Nea] What's the relationship betweetn vendor-specific attributes and interoprability? > > > > > >>> Therefore, the statment should be added into the charter:"To realize > >>> interoperability, the most attributes are standard in PA-level and PV must > >>> be able to make such assessment that NEA server can permit the NEA cllient > >>> to access the network even though the PC could not provide the > >>> vendor-specific attributes." If we can not reach it, the interoperability > >>> will be impractical. > >> > >> Yin, I think what your talking about is an implementation and local > >> policy issue, and not a interoperation issue, and therefore not really > >> an issue for standardization. > >> > >> Whether a foreign computer is allowed to provide it's own posture > >> assessment is a matter of local policy for the trusting company. > >> > >> That the posture collectors and posture validators can exchange > >> information is a matter of standardization to that point that the > >> formats are standardized for attribute exchange but not necessarily > >> the meaning of those attributes. > >> > >> RADIUS attribute extensions work in a similar manner and probably > >> provides a decent model to work off of. > >> > >> mike > _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 24 11:53:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcOaQ-0001DX-EN; Tue, 24 Oct 2006 11:53:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcLM1-00074e-8y; Tue, 24 Oct 2006 08:26:01 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcLLy-0006OF-V3; Tue, 24 Oct 2006 08:26:01 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id D51BF56449; Tue, 24 Oct 2006 08:24:49 -0400 (EDT) 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 FzDmCzohysxP; Tue, 24 Oct 2006 08:24:45 -0400 (EDT) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id A05F65643A; Tue, 24 Oct 2006 08:24:40 -0400 (EDT) Message-ID: <453E0649.2000503@cs.utk.edu> Date: Tue, 24 Oct 2006 08:25:45 -0400 From: Keith Moore User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: "Narayanan, Vidya" Subject: Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) 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: 8b431ad66d60be2d47c7bfeb879db82c X-Mailman-Approved-At: Tue, 24 Oct 2006 11:53:05 -0400 Cc: nea@ietf.org, iesg@ietf.org, ietf@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 -------- > All, > > This charter is definitely clearer on some of the points that were > discussed based on the last version, but a couple of things still remain > to be clarified. Based on several discussions that we've had lately, I > have two suggestions for further clarity: > > 1. Let's add the text suggested by Harald and Lakshminath (there seemed > to be agreement on this text on the list). Quoting the change proposed: > > Replace: > > "NEA can be limited in its applicability when the endpoint and the > organization providing network access are owned by different parties." > > with > > "NEA is applicable to computing environments of enterprises 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. That seems overbroad, in particular because a laptop that connects to multiple networks cannot in general be expected to adhere to conflicting policies of the networks to which it connects. As far as I can tell, this is the crux of the problem with NEA - that in general it's simply unreasonable for a network to demand that every host that connect to it conform to arbitrary policies for configuration of those hosts. IETF should not be standardizing unreasonable expectations. And even if the behavior is in some limited set of circumstances reasonable (which is debatable), IMHO IETF should hesitate to define standards for corner cases. (I do sympathize with the notion that the biggest threats to an enterprise network are from the hosts that connect directly to it, and so it makes sense to concentrate efforts for protecting the network at the points where those hosts attach to the network) The other problem I have with this charter is one that I have with many charters these days - it presupposes a particular design or architecture before the working group has actually met, when this should be an engineering decision taken by the consensus of the working group AFTER analysis of the problem space. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 24 12:12:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcOtJ-0006WR-53; Tue, 24 Oct 2006 12:12:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcOtH-0006Tv-12 for nea@ietf.org; Tue, 24 Oct 2006 12:12:35 -0400 Received: from nz-out-0102.google.com ([64.233.162.204]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcOt4-0003fq-Sv for nea@ietf.org; Tue, 24 Oct 2006 12:12:35 -0400 Received: by nz-out-0102.google.com with SMTP id 13so744884nzn for ; Tue, 24 Oct 2006 09:12:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aGBvmtZ8QBwImkZ7sZ4qpUlurgyBA0/NAs6GVYazuVeek7kVkvHf698R6kka/f/FHf14NRoeAOtLoQX1/mqm/Ero3fVxe9MujnxmZuOuUEOmVgQKOoKHrDAP0NO+TrXEzEopePR9V3/B9YFnDbTkqV/DJz8GbxbexXxnN/+FI64= Received: by 10.64.193.8 with SMTP id q8mr7682469qbf; Tue, 24 Oct 2006 09:12:22 -0700 (PDT) Received: by 10.65.156.6 with HTTP; Tue, 24 Oct 2006 09:12:21 -0700 (PDT) Message-ID: Date: Tue, 24 Oct 2006 12:12:21 -0400 From: "Mike Fratto" To: "Keith Moore" Subject: Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) In-Reply-To: <453E0649.2000503@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: <453E0649.2000503@cs.utk.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: nea@ietf.org, iesg@ietf.org, ietf@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 10/24/06, Keith Moore wrote: > As far as I can tell, this is the crux of the problem with NEA - that in > general it's simply unreasonable for a network to demand that every host > that connect to it conform to arbitrary policies for configuration of > those hosts. IETF should not be standardizing unreasonable > expectations. And even if the behavior is in some limited set of > circumstances reasonable (which is debatable), IMHO IETF should hesitate > to define standards for corner cases. Whether a company manageing a network demands that all hosts meet a specific policy is a local policy issue and the charter specifically addresses this concern: "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. " I think the intent of the working group is to standardize the data formats and protocols so that NEA components can talk together, not to say what to do with non-compliant hosts. That is a local policy decsion. But to get to that decision, the components first have to communicate. At a very high level, this isn't much different than RADIUS, which defines the data formats and protocols between a network access device such as modem pool and the RADIUS server. Vendor specific attributes are supported and the standards don't attempt to provide *meaning*--that is left upto the vendor defining the specific attributes. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 24 12:39:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcPJ5-0000L9-1d; Tue, 24 Oct 2006 12:39:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcPJ3-0000Kl-Bz; Tue, 24 Oct 2006 12:39:13 -0400 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 1GcPIy-00006C-V3; Tue, 24 Oct 2006 12:39:13 -0400 Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 9D7B616E1C; Tue, 24 Oct 2006 12:28:33 -0400 (EDT) From: "Alan DeKok" To: Keith Moore Subject: Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) In-Reply-To: Your message of "Tue, 24 Oct 2006 08:25:45 EDT." <453E0649.2000503@cs.utk.edu> Date: Tue, 24 Oct 2006 12:28:33 -0400 Message-Id: <20061024162833.9D7B616E1C@mail.nitros9.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: nea@ietf.org, iesg@ietf.org, ietf@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: > That seems overbroad, in particular because a laptop that connects to > multiple networks cannot in general be expected to adhere to conflicting > policies of the networks to which it connects. Exactly. That's why there are provisions for non-conforming systems. Network access can be denied entirely, or limited to the public (and unprotected) network. However, 99% of systems don't move networks, so those systems don't have a problem conforming to the local requirements. > As far as I can tell, this is the crux of the problem with NEA - that in > general it's simply unreasonable for a network to demand that every host > that connect to it conform to arbitrary policies for configuration of > those hosts. I'm not sure how to take this. It's unreasonable... OK, why? Is it unreasonable for me to require that I know which machines are on my network, or to deny access to machines I don't own? Given the remediation options outlined above, what part of controlling network access for unknown machines is unreasonable? > The other problem I have with this charter is one that I have with many > charters these days - it presupposes a particular design or architecture > before the working group has actually met, when this should be an > engineering decision taken by the consensus of the working group AFTER > analysis of the problem space. I think it presupposes a particular problem, not an architecture. The problem is: a) knowing who is on my network b) controlling who is on my network c) controlling the behavior of the hosts on my network. If any of those problems are unreasonable to solve, then I would be *very* confused. The proposed NEA architecture derives directly from that problem statement. The *only* assumptions I see are: a) It's a good idea to know who's on my network b) It's a good idea for me to control who is on my network c) It's a good idea for me to control the behavior of hosts on my network d) all of the above is possible to implement e) Step (d) should be standardized 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 Oct 24 12:39:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcPJL-0000PC-75; Tue, 24 Oct 2006 12:39:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcPJK-0000P1-E6; Tue, 24 Oct 2006 12:39:30 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcPJG-000093-R2; Tue, 24 Oct 2006 12:39:30 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 24 Oct 2006 12:39:27 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9OGdQx1009229; Tue, 24 Oct 2006 12:39:26 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k9OGdQYJ022362; Tue, 24 Oct 2006 12:39:26 -0400 (EDT) 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); Tue, 24 Oct 2006 12:39:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) Date: Tue, 24 Oct 2006 12:39:24 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) Thread-Index: AcbyJ9pT4Qs5Q6ljRB2oCe4NXvzMFwFClSFQABCZI9A= From: "Susan Thomson \(sethomso\)" To: "Narayanan, Vidya" X-OriginalArrivalTime: 24 Oct 2006 16:39:26.0086 (UTC) FILETIME=[F7C1D260:01C6F78A] DKIM-Signature: a=rsa-sha1; q=dns; l=11133; t=1161707966; x=1162571966; c=relaxed/simple; s=rtpdkim1001; 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:RE=3A=20[Nea]=20UPDATED=3A=20WG=20Review=3A=20Network=20Endpoint=20Asses sment=20(nea)=20 |To:=22Narayanan,=20Vidya=22=20; X=v=3Dcisco.com=3B=20h=3DZVPIz8qbBYdD6G/YusMHIhUJ1Pg=3D; b=SJg4sbDsSdzThHxkgu4ccSCHLXhU0WFvfS7/koyyj7MUkZTak2JvYgEeodEsFg5PiSieLq4B VDhW3JTamAZURCCWhE2KhT+q8Q+tSqpYO4YX4+D1GTBoaADcWuKe36E3; Authentication-Results: rtp-dkim-1.cisco.com; header.From=sethomso@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ba0d4c5f57f7c289496fce758bbf4798 Cc: nea@ietf.org, iesg@ietf.org, ietf@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 Vidya Inline ... > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com]=20 > Sent: Tuesday, October 24, 2006 2:15 AM > To: iesg@ietf.org; ietf@ietf.org > Cc: nea@ietf.org > Subject: RE: [Nea] UPDATED: WG Review: Network Endpoint=20 > Assessment (nea)=20 >=20 > All, >=20 > This charter is definitely clearer on some of the points that were > discussed based on the last version, but a couple of things=20 > still remain > to be clarified. Based on several discussions that we've had lately, I > have two suggestions for further clarity:=20 >=20 > 1. Let's add the text suggested by Harald and Lakshminath=20 > (there seemed > to be agreement on this text on the list). Quoting the change=20 > proposed:=20 >=20 > Replace: >=20 > "NEA can be limited in its applicability when the endpoint and the > organization providing network access are owned by different parties." >=20 > with >=20 > "NEA is applicable to computing environments of enterprises 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=20 > of the NEA > charter, since we do not know that NEA would be useful in=20 > such cases."=20 >=20 I don't think there is consensus around this text, and I can think of existing deployment scenarios that might be ruled out by this text and also where it might be considered to be too broad. I would rather allow the WG the time to define terminology and discuss criteria that determine applicability, e.g. who owns the endpoint versus who manages the endpoint (these may be different), so that we can do a clearer job articulating this. I don't think we are going to complete this now, and given there is an explicit action in the charter to address applicability, I think this should be good enough. > 2. On the mandatory-to-implement PT protocol, I would like to see the > clarification that the protocol must allow the NEA process to=20 > run either > at the time of network access or while connected. This clarification > seems mainly needed because there is text elsewhere in the=20 > charter about > allowing NEA runs "at network access or while connected" - if=20 > that text > is removed, this clarification won't be required.=20 >=20 I don't think this really matters, but in the interests of closing on this, will remove the text you refer to. Thanks Susan > Thanks, > Vidya >=20 > > -----Original Message----- > > From: IESG Secretary [mailto:iesg-secretary@ietf.org]=20 > > Sent: Tuesday, October 17, 2006 12:50 PM > > To: ietf-announce@ietf.org > > Cc: nea@ietf.org > > Subject: [Nea] UPDATED: WG Review: Network Endpoint=20 > Assessment (nea)=20 > >=20 > > A new IETF working group has been proposed in the Security Area. =20 > > The IESG has not made any determination as yet. The following=20 > > UPDATED draft charter was submitted, and is provided for=20 > > informational purposes only. Please send your comments to the=20 > > IESG mailing list (iesg@ietf.org) by October 23rd. > >=20 > > +++ > >=20 > > Network Endpoint Assessment (nea) > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > Current Status: Proposed Working Group > >=20 > > Chair(s):=20 > > TBD > >=20 > > Security Area Director(s): > > Russ Housley > > Sam Hartman > >=20 > > Security Area Advisor: > > Russ Housley > >=20 > > Mailing List: nea@ietf.org > >=20 > > Description of Working Group: > >=20 > > Network Endpoint Assessment (NEA) architectures have been=20 > > implemented in the industry to assess the "posture" of=20 > > endpoint devices for the purposes of monitoring compliance to=20 > > an organization's posture policy and optionally restricting=20 > > access until the endpoint has been updated to satisfy the=20 > > posture requirements. An endpoint that does not comply with=20 > > posture policy may be vulnerable to a number of known threats=20 > > that may exist on the network. The intent of NEA is to=20 > > facilitate corrective actions to address these known=20 > > vulnerabilities before a host is exposed to potential attack.=20 > > Note that an endpoint that is deemed compliant may still be=20 > > vulnerable to unknown threats that may exist on the network.=20 > > The network may thus continue to be exposed to such threats=20 > > as well as the range of other threats not addressed by=20 > > maintaining endpoint compliance. > >=20 > > Posture refers to the hardware or software configuration of=20 > > an endpoint as it pertains to an organization's security=20 > > policy. Posture may include knowledge that software installed=20 > > to protect the machine (e.g. patch management software,=20 > > anti-virus software, host firewall software, host intrusion=20 > > protection software or any custom software) is enabled and=20 > > up-to-date. On network access and while connected, an=20 > > endpoint supporting NEA protocols can be queried for such=20 > > posture information. > >=20 > > An organization may make a range of policy decisions based on=20 > > the posture of an endpoint. NEA is not intended to be=20 > > prescriptive in this regard. Supported deployment scenarios=20 > > will include, but are not limited to, providing normal access=20 > > regardless of compliance result along with any=20 > > recommendations for remediation ("advisory mode"), as well as=20 > > providing restricted access sufficient for remediation=20 > > purposes and any essential services until an endpoint is in=20 > > compliance ("mandatory mode"). > >=20 > > Since NEA involves many different components from different=20 > > vendors, interoperability is important. The priority of the=20 > > NEA working group is to develop standard protocols at the=20 > > higher layers in the > > architecture: the Posture Attribute protocol (PA) and the=20 > > Posture Broker protocol (PB). PA and PB will be designed to=20 > > support a variety of lower layer protocols. When used with=20 > > standards for lower layers, the PA and PB protocols will=20 > > allow interoperability between an NEA Client from one vendor=20 > > and an NEA Server from another. > >=20 > > Since there are already several non-standard protocols at=20 > > these higher layers, the NEA working group will consider=20 > > these existing protocols as candidates for the standard=20 > > protocols. A requirements document will be written and used=20 > > as a basis for evaluating the candidate protocols. The=20 > > working group may decide to standardize one of the candidate=20 > > protocols, use one of them as a basis for a new or revised=20 > > protocol, or decide that a new protocol is needed. > >=20 > > The NEA Requirements document will include a problem=20 > > statement, definition of terms, requirements for the PA and=20 > > PB protocols, and an overall security analysis. It will also=20 > > include generic requirements for the protocol transporting=20 > > PA, PB: the Posture Transport protocol (PT). PT protocols may=20 > > be standardized in other WGs since these protocols may not be=20 > > specific to NEA. The NEA WG will identify one mandatory to=20 > > implement PT protocol to ensure interoperability. > >=20 > > The PA (Posture Attribute) protocol consists of posture=20 > > attributes that are carried between a particular Posture=20 > > Collector in a NEA client and a particular Posture Validator=20 > > in a NEA Server. The PA protocol is carried inside the PB=20 > > protocol. A base set of standard posture attributes will be=20 > > specified. Vendor-specific attributes will also be supported,=20 > > but vendor-specific attributes must be documented in an RFC. > >=20 > > The PB (Posture Broker) protocol aggregates posture=20 > > attributes from one or more Posture Collectors in an NEA=20 > > client and sends them to the NEA server for assessment by one=20 > > or more Posture Validators. > >=20 > > The PT (Posture Transport) protocol carries the PB protocol. > >=20 > > The NEA working group will not specify protocols other than=20 > > PA and PB at this time. The expectation is that an existing=20 > > protocol can be used for the PT. > >=20 > > One commonly discussed issue with NEA systems is how to=20 > > handle compromised endpoints, whose reports of their own=20 > > posture may not be accurate. Detecting or handling such=20 > > endpoints is out of scope of the NEA WG. Work on PA will=20 > > focus on attributes useful for assessing posture of those=20 > > endpoints reporting accurate information. However, the=20 > > protocols developed by the NEA WG must be designed to=20 > > accommodate emerging technologies for identifying and dealing=20 > > with lying endpoints. > >=20 > > Note that NEA is not chartered to develop standard protocols=20 > > for remediation. NEA is intended to be used with new or=20 > > existing tools that can be used in the absence of NEA. NEA=20 > > can be limited in its applicability when the endpoint and the=20 > > organization providing network access are owned by different=20 > > parties. NEA applicability and security considerations will=20 > > be described in the appropriate NEA documents. > >=20 > > Further work in the NEA WG will be considered via the=20 > > rechartering process after the completion of these milestones. > >=20 > > Milestones: > >=20 > > October 2006: > > * Submit first draft of NEA Requirements I-D > >=20 > > November 2006: > > * At IETF 67, discuss issues with NEA Requirements I-D > > * Agree on solutions to issues with NEA Requirements I-D > >=20 > > December 2007: > > * Submit revised requirements I-D > >=20 > > February 2007: > > * WGLC on NEA Requirements I-D > > * Deadline for submission of candidate specs for PA and PB > >=20 > > March 2007: > > * At IETF 68, resolve outstanding issues with requirements I-D > > * Report from NEA protocol evaluation team > >=20 > > April 2007: > > * Submit NEA Evaluation I-D > >=20 > > June 2007: > > * Submit revised NEA Evaluation I-D > > * WGLC on NEA Evaluation I-D > >=20 > > July 2007: > > * At IETF 69, review outstanding comments on evaluation I-D > >=20 > > August 2007: > > * Submit first draft of PA and PB spec > >=20 > > October 2007: > > * Submit revised draft of PA and PB spec > > * Decide how to address MTI PT, recharter if needed > >=20 > > December 2007: > > * At IETF70, discuss and resolve issues with PA and PB spec > >=20 > > February 2008: > > * WGLC on PA and PB spec > >=20 > > _______________________________________________ > > Nea mailing list > > Nea@ietf.org > > https://www1.ietf.org/mailman/listinfo/nea > >=20 >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 24 12:45:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcPPY-0005gq-S8; Tue, 24 Oct 2006 12:45:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcPPW-0005gX-J0; Tue, 24 Oct 2006 12:45:54 -0400 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 1GcPPM-0001ZA-K8; Tue, 24 Oct 2006 12:45:54 -0400 Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id E1C7716CE0; Tue, 24 Oct 2006 12:35:09 -0400 (EDT) From: "Alan DeKok" To: "Mike Fratto" Subject: Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) In-Reply-To: Your message of "Tue, 24 Oct 2006 12:12:21 EDT." Date: Tue, 24 Oct 2006 12:35:09 -0400 Message-Id: <20061024163509.E1C7716CE0@mail.nitros9.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: nea@ietf.org, iesg@ietf.org, ietf@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 "Mike Fratto" wrote: > At a very high level, this isn't much different than RADIUS, which > defines the data formats and protocols between a network access device > such as modem pool and the RADIUS server. Vendor specific attributes > are supported and the standards don't attempt to provide > *meaning*--that is left upto the vendor defining the specific > attributes. To put it another way, many network access protocols (DHCP, RADIUS, etc.) have been doing posture assessment and network access control for a very long time. The concepts behind NEA are not new. The new part in NEA is the desire to do *more* than what the current access protocols have to offer. Even if NEA was to leverage existing protocols to their fullest extent, we would *still* need a standardized way to exchange the data needed to implement the "more" part of NEA. 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 Oct 24 12:48:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcPRv-0007dd-CQ; Tue, 24 Oct 2006 12:48:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcPRt-0007dY-RO for nea@ietf.org; Tue, 24 Oct 2006 12:48:21 -0400 Received: from a.mail.sonic.net ([64.142.16.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcPRp-000233-Bx for nea@ietf.org; Tue, 24 Oct 2006 12:48:21 -0400 Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG [168.61.10.151]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id k9OGmAP7015732 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Oct 2006 09:48:10 -0700 In-Reply-To: <453E0649.2000503@cs.utk.edu> References: <453E0649.2000503@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: Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) Date: Tue, 24 Oct 2006 09:48:36 -0700 To: Keith Moore X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) 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 On Oct 24, 2006, at 5:25 AM, Keith Moore wrote: > On Oct 23, 2006, at 11:14 PM, Vidya Narayanan wrote: >> >> This charter is definitely clearer on some of the points that were >> discussed based on the last version, but a couple of things still >> remain to be clarified. Based on several discussions that we've >> had lately, I have two suggestions for further clarity: 1. Let's >> add the text suggested by Harald and Lakshminath (there seemed to >> be agreement on this text on the list). >> Quoting the change proposed: Replace: >> >> "NEA can be limited in its applicability when the endpoint and the >> organization providing network access are owned by different >> parties." >> >> with "NEA is applicable to computing environments of enterprises >> 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. > > That seems overbroad, in particular because a laptop that connects > to multiple networks cannot in general be expected to adhere to > conflicting policies of the networks to which it connects. > > As far as I can tell, this is the crux of the problem with NEA - > that in general it's simply unreasonable for a network to demand > that every host that connect to it conform to arbitrary policies > for configuration of those hosts. IETF should not be standardizing > unreasonable expectations. And even if the behavior is in some > limited set of circumstances reasonable (which is debatable), IMHO > IETF should hesitate to define standards for corner cases. Rather than immediately exchanging vendor/environment specific details, exchange of information related to "posture" details can be instead evidenced by certificates declaring: a) an issuing service and the resources needed for the service; b) the class of service with a service relevant time-stamp; c) the user-host identity; d) text describing the service; All "posture" related details are indirectly ascertained by the services that an NEA server allows, requests, or permits. The NEA server may publish requirements as listed "sets" of hostmaster certificates. The NEA client then checks its repository for a matching certificate within each set to fulfill expectations. When no match is found or an update is determined to be required, the user might be prompted to pick a service certificate for execution. The resources listed in the certificate can permit the client and server to establish a minimal network supporting the related NEA certificate generating service. This approach should be useable in any environment, and not limited to corporate environments or specific operating systems. The NEA client/servers would not directly exchange vendor specific structured data. The NEA services would handle these details (and likely already are). Existing services would be adapted to this NEA methodology by wrapping them with script that obtains the NEA service certificates after successful completion, and then placing them into the NEA certificate repository. Upon a service failure, the related service may also expunge their certificates from the client's repository. A certificate approach offers a flexible method for notifying users and for guiding them through a selection of remediation/certification services. This strategy should reduce current IT support requirements in any environment while also making minimal changes to existing services. > (I do sympathize with the notion that the biggest threats to an > enterprise network are from the hosts that connect directly to it, > and so it makes sense to concentrate efforts for protecting the > network at the points where those hosts attach to the network) > > The other problem I have with this charter is one that I have with > many charters these days - it presupposes a particular design or > architecture before the working group has actually met, when this > should be an engineering decision taken by the consensus of the > working group AFTER analysis of the problem space. Well said. -Doug _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 24 13:12:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcPpf-0007bO-HI; Tue, 24 Oct 2006 13:12:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcPpe-0007Zt-R0; Tue, 24 Oct 2006 13:12:54 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcPoB-0006P2-A6; Tue, 24 Oct 2006 13:11:45 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k9OHBLAW017397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 24 Oct 2006 10:11:22 -0700 Received: from LDONDETI.qualcomm.com (qconnect-10-50-77-63.qualcomm.com [10.50.77.63]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k9OHBE37001338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 Oct 2006 10:11:15 -0700 (PDT) Message-Id: <7.0.1.0.2.20061024100508.06fb7a80@qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 24 Oct 2006 10:11:08 -0700 To: "Susan Thomson \(sethomso\)" , "Narayanan, Vidya" From: Lakshminath Dondeti Subject: RE: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: a4cdc653ecdd96665f2aa1c1af034c9e Cc: nea@ietf.org, iesg@ietf.org, ietf@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 Susan, Having the applicability text baselined in the charter is necessary in my view. The current charter text is vague ("can be limited"). If you want to propose a revision of the text that Harald, Vidya and I are ok with, please do so. Given that this is up for discussion and decision in 2 days, let's work quickly on it. thanks, Lakshminath At 09:39 AM 10/24/2006, Susan Thomson \(sethomso\) wrote: >Hi Vidya > >Inline ... > > > -----Original Message----- > > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] > > Sent: Tuesday, October 24, 2006 2:15 AM > > To: iesg@ietf.org; ietf@ietf.org > > Cc: nea@ietf.org > > Subject: RE: [Nea] UPDATED: WG Review: Network Endpoint > > Assessment (nea) > > > > All, > > > > This charter is definitely clearer on some of the points that were > > discussed based on the last version, but a couple of things > > still remain > > to be clarified. Based on several discussions that we've had lately, I > > have two suggestions for further clarity: > > > > 1. Let's add the text suggested by Harald and Lakshminath > > (there seemed > > to be agreement on this text on the list). Quoting the change > > proposed: > > > > Replace: > > > > "NEA can be limited in its applicability when the endpoint and the > > organization providing network access are owned by different parties." > > > > with > > > > "NEA is applicable to computing environments of enterprises 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." > > > >I don't think there is consensus around this text, and I can think of >existing deployment scenarios that might be ruled out by this text and >also where it might be considered to be too broad. I would rather allow >the WG the time to define terminology and discuss criteria that >determine applicability, e.g. who owns the endpoint versus who manages >the endpoint (these may be different), so that we can do a clearer job >articulating this. I don't think we are going to complete this now, and >given there is an explicit action in the charter to address >applicability, I think this should be good enough. > > > 2. On the mandatory-to-implement PT protocol, I would like to see the > > clarification that the protocol must allow the NEA process to > > run either > > at the time of network access or while connected. This clarification > > seems mainly needed because there is text elsewhere in the > > charter about > > allowing NEA runs "at network access or while connected" - if > > that text > > is removed, this clarification won't be required. > > > >I don't think this really matters, but in the interests of closing on >this, will remove the text you refer to. > >Thanks >Susan > > > Thanks, > > Vidya > > > > > -----Original Message----- > > > From: IESG Secretary [mailto:iesg-secretary@ietf.org] > > > Sent: Tuesday, October 17, 2006 12:50 PM > > > To: ietf-announce@ietf.org > > > Cc: nea@ietf.org > > > Subject: [Nea] UPDATED: WG Review: Network Endpoint > > Assessment (nea) > > > > > > A new IETF working group has been proposed in the Security Area. > > > The IESG has not made any determination as yet. The following > > > UPDATED draft charter was submitted, and is provided for > > > informational purposes only. Please send your comments to the > > > IESG mailing list (iesg@ietf.org) by October 23rd. > > > > > > +++ > > > > > > Network Endpoint Assessment (nea) > > > =================================== > > > > > > Current Status: Proposed Working Group > > > > > > Chair(s): > > > TBD > > > > > > Security Area Director(s): > > > Russ Housley > > > Sam Hartman > > > > > > Security Area Advisor: > > > Russ Housley > > > > > > Mailing List: nea@ietf.org > > > > > > Description of Working Group: > > > > > > Network Endpoint Assessment (NEA) architectures have been > > > implemented in the industry 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. An endpoint that does not comply with > > > posture policy may be vulnerable to a number of known threats > > > that may exist on the network. The intent of NEA is to > > > facilitate corrective actions to address these known > > > vulnerabilities before a host is exposed to potential attack. > > > Note that an endpoint that is deemed compliant may still be > > > vulnerable to unknown 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. > > > > > > Posture refers to the hardware or software configuration of > > > an endpoint as it pertains to an organization's security > > > 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. On network access and while connected, an > > > endpoint supporting NEA protocols can be queried for such > > > posture information. > > > > > > 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"). > > > > > > 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 one mandatory to > > > implement PT protocol to ensure interoperability. > > > > > > 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. Vendor-specific attributes will also be supported, > > > but vendor-specific attributes must be documented in an RFC. > > > > > > 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 > > > can be limited in its applicability when the endpoint and the > > > organization providing network access are owned by different > > > parties. 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: > > > > > > October 2006: > > > * Submit first draft of NEA Requirements I-D > > > > > > November 2006: > > > * At IETF 67, discuss issues with 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 > > > * Deadline for submission of candidate specs for PA and PB > > > > > > March 2007: > > > * At IETF 68, resolve outstanding issues with requirements I-D > > > * Report from NEA protocol evaluation team > > > > > > April 2007: > > > * Submit NEA Evaluation I-D > > > > > > June 2007: > > > * Submit revised NEA Evaluation I-D > > > * WGLC on NEA Evaluation I-D > > > > > > July 2007: > > > * At IETF 69, review outstanding comments on evaluation I-D > > > > > > August 2007: > > > * Submit first draft of PA and PB spec > > > > > > October 2007: > > > * Submit revised draft of PA and PB spec > > > * Decide how to address MTI PT, recharter if needed > > > > > > December 2007: > > > * At IETF70, discuss and resolve issues with PA and PB spec > > > > > > February 2008: > > > * WGLC on PA and PB spec > > > > > > _______________________________________________ > > > 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 Tue Oct 24 13:14:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcPrZ-0008OC-Rk; Tue, 24 Oct 2006 13:14:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcPph-0007Zt-73; Tue, 24 Oct 2006 13:12:57 -0400 Received: from is1.enterasys.com ([63.160.138.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcPnQ-0006KL-S3; Tue, 24 Oct 2006 13:10:57 -0400 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe2.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Oct 2006 13:10:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) Date: Tue, 24 Oct 2006 13:10:36 -0400 Message-ID: <3CFB564E055A594B82C4FE89D21565605A4937@MABOSEVS2.ets.enterasys.com> In-Reply-To: <453E449E.7060204@cs.utk.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) Thread-Index: Acb3jP4aJKhSnremRAy/NlF0uas34AAATAxA From: "Nelson, David" To: X-OriginalArrivalTime: 24 Oct 2006 17:10:36.0067 (UTC) FILETIME=[525A4730:01C6F78F] X-imss-version: 2.043 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ietf@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 writes... > what the WG charter says and how the WG output is used are=20 > different things. IMHO we need to consider the potential=20 > unintended consequences of our efforts in IETF, not just what=20 > we intend. network operators do not limit their use of=20 > technology to what we write in applicability statements. Should I infer from this sentiment that you believe that the IETF ought to refrain from standardizing any technology that could be used by public or private network operators to discriminate against certain classes of clients, based on the "posture" of their hosts? I'll point out that only certain kinds of discrimination are undesirable, i.e. discrimination against protected classes. Other kinds of discrimination, e.g. helping to maintain a "safe computing" environment within a network, are highly desirable. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 24 13:27:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcQ3c-0003uI-1a; Tue, 24 Oct 2006 13:27:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcQ3a-0003u5-Az for nea@ietf.org; Tue, 24 Oct 2006 13:27:18 -0400 Received: from woodstock.binhost.com ([66.150.120.2]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GcQ3X-0001yZ-KN for nea@ietf.org; Tue, 24 Oct 2006 13:27:18 -0400 Received: (qmail 24093 invoked by uid 0); 24 Oct 2006 17:27:01 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.126.161.75) by woodstock.binhost.com with SMTP; 24 Oct 2006 17:27:01 -0000 Message-Id: <7.0.0.16.2.20061024132144.076c9a38@vigilsec.com> Message-Id: <7.0.0.16.2.20061023212803.0721ac08@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Tue, 24 Oct 2006 13:27:01 -0400 To: iesg@ietf.org From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Cc: nea@ietf.org Subject: [Nea] Revised HOKEY Charter Text 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 [ BCC to IESG Secretary ] Here is the NEA Charter text to be considered on the IESG Telechat on 2006-10-26. Russ = = = = = = = = = = Chair(s): Steve Hanna Susan Thomson Security Area Director(s): Russ Housley Sam Hartman Security Area Advisor: Russ Housley Mailing List: nea@ietf.org Description of Working Group: Network Endpoint Assessment (NEA) architectures have been implemented in the industry 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. An endpoint that does not comply with posture policy may be vulnerable to a number of known threats that may exist on the network. The intent of NEA is to facilitate corrective actions to address these known vulnerabilities before a host is exposed to potential attack. 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. Posture refers to the hardware or software configuration of an endpoint as it pertains to an organization's security 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. 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. 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 can be limited in its applicability when the endpoint and the organization providing network access are owned by different parties. 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: * Submit first draft of NEA Requirements I-D * At IETF 67, discuss issues with 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 * Deadline for submission of candidate specs for PA and PB March 2007: * At IETF 68, resolve outstanding issues with requirements I-D * Report from NEA protocol evaluation team April 2007: * Submit NEA Evaluation I-D June 2007: * Submit revised NEA Evaluation I-D * WGLC on NEA Evaluation I-D July 2007: * At IETF 69, review outstanding comments on evaluation I-D August 2007: * Submit first draft of PA and PB spec October 2007: * Submit revised draft of PA and PB spec * Decide how to address MTI PT, recharter if needed December 2007: * At IETF70, discuss and resolve issues with PA and PB spec February 2008: * WGLC on PA and PB spec _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 24 13:41:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcQHc-0007Aj-8g; Tue, 24 Oct 2006 13:41:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcQHa-0007AO-VZ; Tue, 24 Oct 2006 13:41:46 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcQHW-0005TY-Fp; Tue, 24 Oct 2006 13:41:46 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k9OHfeVL028848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 24 Oct 2006 10:41:41 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.na.qualcomm.com [10.46.92.109]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k9OHfapJ000688; Tue, 24 Oct 2006 10:41:39 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Oct 2006 10:41:37 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) Date: Tue, 24 Oct 2006 10:41:24 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) Thread-Index: Acb3kcUNUe0he1BcQTC9mKnGA11xdQAAcQKA From: "Narayanan, Vidya" To: "Sam Hartman" , "Susan Thomson \(sethomso\)" X-OriginalArrivalTime: 24 Oct 2006 17:41:37.0866 (UTC) FILETIME=[A81242A0:01C6F793] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: nea@ietf.org, iesg@ietf.org, ietf@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org =20 > -----Original Message----- > From: Sam Hartman [mailto:hartmans-ietf@mit.edu]=20 > Sent: Tuesday, October 24, 2006 10:28 AM > To: Susan Thomson (sethomso) > Cc: Narayanan, Vidya; nea@ietf.org; iesg@ietf.org; ietf@ietf.org > Subject: Re: [Nea] UPDATED: WG Review: Network Endpoint=20 > Assessment (nea) >=20 > >>>>> "Susan" =3D=3D Susan Thomson (sethomso) = writes: >=20 > Susan> Hi Vidya Inline ... >=20 > >> -----Original Message----- From: Narayanan, Vidya > >> [mailto:vidyan@qualcomm.com] Sent: Tuesday, October 24, 2006 > >> 2:15 AM To: iesg@ietf.org; ietf@ietf.org Cc: nea@ietf.org > >> Subject: RE: [Nea] UPDATED: WG Review: Network Endpoint > >> Assessment (nea) > >>=20 > >> All, > >>=20 > >> This charter is definitely clearer on some of the points that > >> were discussed based on the last version, but a couple of > >> things still remain to be clarified. Based on several > >> discussions that we've had lately, I have two suggestions for > >> further clarity: > >>=20 > >> 1. Let's add the text suggested by Harald and Lakshminath > >> (there seemed to be agreement on this text on the > >> list). Quoting the change proposed: > >>=20 > >> Replace: > >>=20 > >> "NEA can be limited in its applicability when the endpoint and > >> the organization providing network access are owned by > >> different parties." > >>=20 > >> with > >>=20 > >> "NEA is applicable to computing environments of enterprises > >> 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 >=20 > Susan> I don't think there is consensus around this text, and I > Susan> can think of existing deployment scenarios that might be > Susan> ruled out by this text and also where it might be > Susan> considered to be too broad.=20 >=20 > Ah. Count me as one in favor of the text (although I do not=20 > object to the old text). I didn't speak up because I thought=20 > there was consensus. >=20 I thought so as well. There were a few who explicitly agreed and I saw no disagreements on the list.=20 Vidya _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 24 14:00:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcQa5-0002Pn-Mo; Tue, 24 Oct 2006 14:00:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcQa4-0002PO-Mr for nea@ietf.org; Tue, 24 Oct 2006 14:00:52 -0400 Received: from woodstock.binhost.com ([66.150.120.2]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GcQOL-0006h7-Tu for nea@ietf.org; Tue, 24 Oct 2006 13:48:50 -0400 Received: (qmail 13331 invoked by uid 0); 24 Oct 2006 17:48:39 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.126.161.75) by woodstock.binhost.com with SMTP; 24 Oct 2006 17:48:39 -0000 Message-Id: <7.0.0.16.2.20061024134730.0413d770@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Tue, 24 Oct 2006 13:48:41 -0400 To: iesg@ietf.org From: Russ Housley In-Reply-To: <7.0.0.16.2.20061024132144.076c9a38@vigilsec.com> References: <7.0.0.16.2.20061024132144.076c9a38@vigilsec.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Cc: nea@ietf.org Subject: [Nea] Opps: Revised NEA Charter Text 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 Obviously the subject line of my message should have been: Revised NEA Charter Text At 01:27 PM 10/24/2006, Russ Housley wrote: >[ BCC to IESG Secretary ] > >Here is the NEA Charter text to be considered on the IESG Telechat >on 2006-10-26. > >Russ > >= = = = = = = = = = > >Chair(s): Steve Hanna > Susan Thomson > >Security Area Director(s): > Russ Housley > Sam Hartman > >Security Area Advisor: > Russ Housley > >Mailing List: nea@ietf.org > >Description of Working Group: > >Network Endpoint Assessment (NEA) architectures have been implemented >in the industry 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. An endpoint that does not comply >with posture policy may be vulnerable to a number of known threats that >may exist on the network. The intent of NEA is to facilitate corrective >actions to address these known vulnerabilities before a host is exposed >to potential attack. 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. > >Posture refers to the hardware or software configuration of an endpoint >as it pertains to an organization's security 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. > >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. > >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 can be limited in its >applicability when the endpoint and the organization providing network >access are owned by different parties. 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: >* Submit first draft of NEA Requirements I-D >* At IETF 67, discuss issues with 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 >* Deadline for submission of candidate specs for PA and PB > >March 2007: >* At IETF 68, resolve outstanding issues with requirements I-D >* Report from NEA protocol evaluation team > >April 2007: >* Submit NEA Evaluation I-D > >June 2007: >* Submit revised NEA Evaluation I-D >* WGLC on NEA Evaluation I-D > >July 2007: >* At IETF 69, review outstanding comments on evaluation I-D > >August 2007: >* Submit first draft of PA and PB spec > >October 2007: >* Submit revised draft of PA and PB spec >* Decide how to address MTI PT, recharter if needed > >December 2007: >* At IETF70, discuss and resolve issues with PA and PB spec > >February 2008: >* WGLC on PA and PB spec > > _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 24 14:08:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcQhb-0000Tl-6N; Tue, 24 Oct 2006 14:08:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcPVR-0002d9-Dg; Tue, 24 Oct 2006 12:52:01 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcPVE-0002ez-Bx; Tue, 24 Oct 2006 12:52:01 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id D059A56479; Tue, 24 Oct 2006 12:50:40 -0400 (EDT) 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 Gx9Z-o71vXri; Tue, 24 Oct 2006 12:50:37 -0400 (EDT) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 1714256474; Tue, 24 Oct 2006 12:50:36 -0400 (EDT) Message-ID: <453E449E.7060204@cs.utk.edu> Date: Tue, 24 Oct 2006 12:51:42 -0400 From: Keith Moore User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Mike Fratto Subject: Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) References: <453E0649.2000503@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: 8abaac9e10c826e8252866cbe6766464 X-Mailman-Approved-At: Tue, 24 Oct 2006 14:08:38 -0400 Cc: nea@ietf.org, iesg@ietf.org, ietf@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 > Whether a company manageing a network demands that all hosts meet a > specific policy is a local policy issue and the charter specifically > addresses this concern: > > "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. " what the WG charter says and how the WG output is used are different things. IMHO we need to consider the potential unintended consequences of our efforts in IETF, not just what we intend. network operators do not limit their use of technology to what we write in applicability statements. > I think the intent of the working group is to standardize the data > formats and protocols so that NEA components can talk together, not to > say what to do with non-compliant hosts. That is a local policy > decsion. But to get to that decision, the components first have to > communicate. > > At a very high level, this isn't much different than RADIUS, which > defines the data formats and protocols between a network access device > such as modem pool and the RADIUS server. I don't think it's a good analogy because modem pools are very special-purpose devices, whereas a host can potentially do anything that needs to communicate with something else. For that matter, RADIUS doesn't have the intent of preventing some kinds of modem pools from connecting to the network. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 24 14:08:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcQhb-0000UV-Ca; Tue, 24 Oct 2006 14:08:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcPpn-0007ck-4L; Tue, 24 Oct 2006 13:13:03 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcPlw-000668-UQ; Tue, 24 Oct 2006 13:09:06 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id BE31156479; Tue, 24 Oct 2006 13:07:57 -0400 (EDT) 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 oXBXxQiaHBVN; Tue, 24 Oct 2006 13:07:54 -0400 (EDT) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 478D256474; Tue, 24 Oct 2006 13:07:53 -0400 (EDT) Message-ID: <453E48AA.7050805@cs.utk.edu> Date: Tue, 24 Oct 2006 13:08:58 -0400 From: Keith Moore User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Alan DeKok Subject: Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) References: <20061024162833.9D7B616E1C@mail.nitros9.org> In-Reply-To: <20061024162833.9D7B616E1C@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: cd26b070c2577ac175cd3a6d878c6248 X-Mailman-Approved-At: Tue, 24 Oct 2006 14:08:38 -0400 Cc: nea@ietf.org, iesg@ietf.org, ietf@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: >> That seems overbroad, in particular because a laptop that connects to >> multiple networks cannot in general be expected to adhere to conflicting >> policies of the networks to which it connects. > > Exactly. That's why there are provisions for non-conforming > systems. Network access can be denied entirely, or limited to the > public (and unprotected) network. However, 99% of systems don't move > networks, so those systems don't have a problem conforming to the > local requirements. do you have actual statistics to back that up? are 99% of hosts produced servers or desktops rather than laptops? and how are you defining a host, anyway? sorry, it just looks like a number picked out of thin air. even if the 99% figure is true today, will it be true in general in the future? personally I think that desktops as we know them are dinosaurs. they are too much of a security threat, too expensive to maintain, offer more flexibility than is needed, and are becoming a vector by which extortionist licensing fees can be extracted from owners. and the trend seems to be toward more and more mobile devices and special purpose devices. standards take a long time to produce and need to last a long time, so it make sense to define them in such a way as to be likely to continue to be useful for the foreseeable future. >> As far as I can tell, this is the crux of the problem with NEA - that in >> general it's simply unreasonable for a network to demand that every host >> that connect to it conform to arbitrary policies for configuration of >> those hosts. > > I'm not sure how to take this. It's unreasonable... OK, why? because the very nature of a personal computer is one in which every machine is customizable to suit the needs of the individual user. if the network takes away that flexibility, it also obviates the need for a user-programmable personal computer. there are better (more reliable, more secure, more effective, cheaper) ways of providing a set of functions at a user terminal than to give everyone user-programmable machines and then have the network insist that they all have a rigidly controlled configuration...and the only way to really get security out of PCs is to rigidly control their configurations. and furthermore if PCs continue to be user-programmable then it becomes possible to make NEA meaningless. (though the protocol could make it difficult for a host to forge assertions about itself by having the host sign the assertions with a key signed by the NEA software vendor, it would take some significant cleverness to prevent that key from being exposed to an attacker on that host, particularly one with physical access to the host). NEA isn't about knowing "who" is on your network in the sense of determining identity, it's about being able to delve into arbitrary details of host configuration. >> The other problem I have with this charter is one that I have with many >> charters these days - it presupposes a particular design or architecture >> before the working group has actually met, when this should be an >> engineering decision taken by the consensus of the working group AFTER >> analysis of the problem space. > > I think it presupposes a particular problem, not an architecture. > The problem is: > > a) knowing who is on my network > b) controlling who is on my network > c) controlling the behavior of the hosts on my network. > > If any of those problems are unreasonable to solve, then I would be > *very* confused. > > The proposed NEA architecture derives directly from that problem > statement. to me it seems to presuppose much more than that, by naming the kinds of actors and their roles. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 24 14:08:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcQhb-0000VC-Hg; Tue, 24 Oct 2006 14:08:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcQ1G-00020Y-7T; Tue, 24 Oct 2006 13:24:54 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcQ1D-0001Xw-Vc; Tue, 24 Oct 2006 13:24:54 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 2863356498; Tue, 24 Oct 2006 13:23:45 -0400 (EDT) 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 rAJc+kSnDfUV; Tue, 24 Oct 2006 13:23:40 -0400 (EDT) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 8972056487; Tue, 24 Oct 2006 13:23:35 -0400 (EDT) Message-ID: <453E4C58.90108@cs.utk.edu> Date: Tue, 24 Oct 2006 13:24:40 -0400 From: Keith Moore User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: "Nelson, David" Subject: Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) References: <3CFB564E055A594B82C4FE89D21565605A4937@MABOSEVS2.ets.enterasys.com> In-Reply-To: <3CFB564E055A594B82C4FE89D21565605A4937@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: 9182cfff02fae4f1b6e9349e01d62f32 X-Mailman-Approved-At: Tue, 24 Oct 2006 14:08:38 -0400 Cc: nea@ietf.org, ietf@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 >> what the WG charter says and how the WG output is used are >> different things. IMHO we need to consider the potential >> unintended consequences of our efforts in IETF, not just what >> we intend. network operators do not limit their use of >> technology to what we write in applicability statements. > > Should I infer from this sentiment that you believe that the IETF ought > to refrain from standardizing any technology that could be used by > public or private network operators to discriminate against certain > classes of clients, based on the "posture" of their hosts? I think it's dangerous territory, and IETF needs to be very careful about how the subject is approached. I don't think the current NEA charter reflects that kind of care, and I don't think that IETF processes for WG adoption really facilitate that kind of care. Within existing IETF structure defining the appropriate direction for a group like NEA probably calls for an IAB workshop - which unfortunately is a lot slower than you want if you're trying to ship product and have it blessed as a standard. Clearly there is some potential benefit at being able to identify hosts that present a risk to the network to which they are attached. But there's a very large and unpleasant camel attached to that nose. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 24 14:08:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcQhb-0000Wv-QA; Tue, 24 Oct 2006 14:08:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcQ4C-0004Hd-0E; Tue, 24 Oct 2006 13:27:56 -0400 Received: from carter-zimmerman.suchdamage.org ([69.25.196.178] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcQ49-0002AQ-R3; Tue, 24 Oct 2006 13:27:55 -0400 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 16ED6E01E6; Tue, 24 Oct 2006 13:27:43 -0400 (EDT) From: Sam Hartman To: "Susan Thomson (sethomso)" Subject: Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) References: Date: Tue, 24 Oct 2006 13:27:43 -0400 In-Reply-To: (Susan Thomson's message of "Tue, 24 Oct 2006 12:39:24 -0400") 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: c1c65599517f9ac32519d043c37c5336 X-Mailman-Approved-At: Tue, 24 Oct 2006 14:08:38 -0400 Cc: nea@ietf.org, iesg@ietf.org, ietf@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 >>>>> "Susan" == Susan Thomson (sethomso) writes: Susan> Hi Vidya Inline ... >> -----Original Message----- From: Narayanan, Vidya >> [mailto:vidyan@qualcomm.com] Sent: Tuesday, October 24, 2006 >> 2:15 AM To: iesg@ietf.org; ietf@ietf.org Cc: nea@ietf.org >> Subject: RE: [Nea] UPDATED: WG Review: Network Endpoint >> Assessment (nea) >> >> All, >> >> This charter is definitely clearer on some of the points that >> were discussed based on the last version, but a couple of >> things still remain to be clarified. Based on several >> discussions that we've had lately, I have two suggestions for >> further clarity: >> >> 1. Let's add the text suggested by Harald and Lakshminath >> (there seemed to be agreement on this text on the >> list). Quoting the change proposed: >> >> Replace: >> >> "NEA can be limited in its applicability when the endpoint and >> the organization providing network access are owned by >> different parties." >> >> with >> >> "NEA is applicable to computing environments of enterprises >> 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." >> Susan> I don't think there is consensus around this text, and I Susan> can think of existing deployment scenarios that might be Susan> ruled out by this text and also where it might be Susan> considered to be too broad. Ah. Count me as one in favor of the text (although I do not object to the old text). I didn't speak up because I thought there was consensus. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 24 14:39:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcRBu-0005KU-9p; Tue, 24 Oct 2006 14:39:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcRBs-0005K9-Ds; Tue, 24 Oct 2006 14:39:56 -0400 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 1GcRBn-0000LD-8O; Tue, 24 Oct 2006 14:39:56 -0400 Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 9B86516CE0; Tue, 24 Oct 2006 14:29:17 -0400 (EDT) From: "Alan DeKok" To: Keith Moore Subject: Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) In-Reply-To: Your message of "Tue, 24 Oct 2006 12:51:42 EDT." <453E449E.7060204@cs.utk.edu> Date: Tue, 24 Oct 2006 14:29:17 -0400 Message-Id: <20061024182917.9B86516CE0@mail.nitros9.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: nea@ietf.org, iesg@ietf.org, ietf@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 don't think it's a good analogy because modem pools are very > special-purpose devices, whereas a host can potentially do anything that > needs to communicate with something else. For that matter, RADIUS > doesn't have the intent of preventing some kinds of modem pools from > connecting to the network. No, but it has the explicit intent of preventing some kinds of hosts from connecting to the network. Current RADIUS deployments implement almost anything you can imagine to control network access for hosts and/or users, down to filtering the users network traffic. Current RADIUS deployments *already* do ad-hoc posture assessment, there are a number of startups implementing this today. I don't see how NEA is such a big philosophical change from existing RADIUS practices. 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 Oct 24 14:46:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcRI1-0002xw-12; Tue, 24 Oct 2006 14:46:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcRHz-0002xl-OE; Tue, 24 Oct 2006 14:46:15 -0400 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 1GcRHy-0001HJ-Dn; Tue, 24 Oct 2006 14:46:15 -0400 Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id E5EDD16CE0; Tue, 24 Oct 2006 14:35:43 -0400 (EDT) From: "Alan DeKok" To: Keith Moore Subject: Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) In-Reply-To: Your message of "Tue, 24 Oct 2006 13:08:58 EDT." <453E48AA.7050805@cs.utk.edu> Date: Tue, 24 Oct 2006 14:35:43 -0400 Message-Id: <20061024183543.E5EDD16CE0@mail.nitros9.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: nea@ietf.org, iesg@ietf.org, ietf@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: > do you have actual statistics to back that up? It's not meant to be an exact number, but it's pretty close to being correct, in my experience. > there are better (more reliable, more secure, more effective, > cheaper) ways of providing a set of functions at a user terminal > than to give everyone user-programmable machines and then have the > network insist that they all have a rigidly controlled > configuration... Yes. And there are mistakes in IETF protocols that have been deployed for decades, too. What are we supposed to tell the people who have billions of dollars invested in their current systems? "You got it wrong, we're not going to come up with a solution to your problems." ? > to me it seems to presuppose much more than that, by naming the kinds of > actors and their roles. The actors and roles are nothing new. End-hosts, authentication servers, administrators, etc. have all been around for years. The NEA names are new, because people are starting to realize that there are classes of behavior that cannot be adequately described using the existing names. 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 Oct 24 15:10:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcRfv-0004RN-9W; Tue, 24 Oct 2006 15:10:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcRfu-0004RC-2q; Tue, 24 Oct 2006 15:10:58 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcRfq-0005Y4-MJ; Tue, 24 Oct 2006 15:10:58 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k9OJAme7013116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 24 Oct 2006 12:10:49 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by neophyte.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k9OJ9kgC019407; Tue, 24 Oct 2006 12:10:44 -0700 (PDT) Received: from NAEX13.na.qualcomm.com ([129.46.51.248]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Oct 2006 12:10:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) Date: Tue, 24 Oct 2006 12:10:39 -0700 Message-ID: In-Reply-To: <20061024182917.9B86516CE0@mail.nitros9.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) Thread-Index: Acb3m/IHVFdbLy9WRsO3x1sLyhTtAAAAItgw From: "Narayanan, Vidya" To: "Alan DeKok" , "Keith Moore" X-OriginalArrivalTime: 24 Oct 2006 19:10:38.0522 (UTC) FILETIME=[1759B1A0:01C6F7A0] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: nea@ietf.org, iesg@ietf.org, ietf@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org =20 > -----Original Message----- > From: Alan DeKok [mailto:aland@deployingradius.com]=20 > Sent: Tuesday, October 24, 2006 11:29 AM > To: Keith Moore > Cc: nea@ietf.org; iesg@ietf.org; ietf@ietf.org > Subject: Re: [Nea] UPDATED: WG Review: Network Endpoint=20 > Assessment (nea)=20 >=20 > Keith Moore wrote: > > I don't think it's a good analogy because modem pools are very=20 > > special-purpose devices, whereas a host can potentially do anything=20 > > that needs to communicate with something else. For that matter,=20 > > RADIUS doesn't have the intent of preventing some kinds of=20 > modem pools=20 > > from connecting to the network. >=20 > No, but it has the explicit intent of preventing some kinds=20 > of hosts from connecting to the network. Current RADIUS=20 > deployments implement almost anything you can imagine to=20 > control network access for hosts and/or users, down to=20 > filtering the users network traffic. Current RADIUS=20 > deployments *already* do ad-hoc posture assessment, there are=20 > a number of startups implementing this today. >=20 > I don't see how NEA is such a big philosophical change from=20 > existing RADIUS practices. >=20 I can sort of buy the analogy to RADIUS, although the AAA protocols are intended to do a lot more (the third "A" for instance). However, RADIUS doesn't inherently claim any security properties, while NEA seems to. RADIUS (or Diameter, for that matter) cannot really guarantee any level of security for network access control - that is dependent on what is carried in RADIUS (sometimes, a couple of levels down - e.g., EAP Method over EAP over RADIUS, where the strength is really dependent on the EAP method). Also, the strength of the second "A" in AAA depends on the kind of authorization policies in place. AAA is just a framework facilitating these - not a protocol that has some security claims to it.=20 Vidya _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 24 15:38:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcS6m-0001vZ-KM; Tue, 24 Oct 2006 15:38:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcS6l-0001vS-36 for nea@ietf.org; Tue, 24 Oct 2006 15:38:43 -0400 Received: from wr-out-0506.google.com ([64.233.184.226]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcS6h-00019F-Rx for nea@ietf.org; Tue, 24 Oct 2006 15:38:43 -0400 Received: by wr-out-0506.google.com with SMTP id i20so522141wra for ; Tue, 24 Oct 2006 12:38:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=I8zlD/7UZTc7+C/TkzB68G5igX3xJ92fAJGFZ/1l9NA/ZFoNmjsI5pDrCc8VrypA0NP44gyXK96BGLBmtmi+nY9N4/UFQRA2dzST1A+JXErp6+vqmoSP8OkKOPzaIzf6/aJOdu2HuNPqkNkAWlwZWT0y5cuR0R1UiAchaPEVKbw= Received: by 10.65.251.1 with SMTP id d1mr8033082qbs; Tue, 24 Oct 2006 12:38:37 -0700 (PDT) Received: by 10.65.156.6 with HTTP; Tue, 24 Oct 2006 12:38:37 -0700 (PDT) Message-ID: Date: Tue, 24 Oct 2006 15:38:37 -0400 From: "Mike Fratto" To: "Narayanan, Vidya" Subject: Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061024182917.9B86516CE0@mail.nitros9.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: nea@ietf.org, 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 > I can sort of buy the analogy to RADIUS, although the AAA protocols are > intended to do a lot more (the third "A" for instance). Sorry, I didn't mean to sidetrack this. My RADIUS (or DHCP, or SNMP, etc) example demonstrates a case where a set of protocols and data formats are designed to have extensible attributes without having to define the meaning of those attributes apriori. For example, if an AV vendor called FOO wants to define an attribute BAR for it's product, the NEA specifications should allow for that without having to define a meaning for BAR or define an action based on the presence or absense of BAR (which is a matter of local policy). Nor are all products that implement NEA standards required to support extensions by vendor FOO (also, a matter of local policy). There seems to be confusion among some about supporting a set of protocols and formats and enforcing policy. The charter seems pretty clear that the outut of the NEA is *not* attempting to dictate local policy. Product support is a local policy issue. I'll shutup now. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 24 16:01:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcSSQ-0006zT-0T; Tue, 24 Oct 2006 16:01:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcRTJ-0003qy-Pe; Tue, 24 Oct 2006 14:57:57 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcRTH-0003Pd-Bv; Tue, 24 Oct 2006 14:57:57 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 550425645A; Tue, 24 Oct 2006 14:56:48 -0400 (EDT) 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 ryavLKv6gO51; Tue, 24 Oct 2006 14:56:43 -0400 (EDT) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 8FDD556452; Tue, 24 Oct 2006 14:56:42 -0400 (EDT) Message-ID: <453E622B.9020107@cs.utk.edu> Date: Tue, 24 Oct 2006 14:57:47 -0400 From: Keith Moore User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Alan DeKok Subject: Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) References: <20061024183543.E5EDD16CE0@mail.nitros9.org> In-Reply-To: <20061024183543.E5EDD16CE0@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: b19722fc8d3865b147c75ae2495625f2 X-Mailman-Approved-At: Tue, 24 Oct 2006 16:01:01 -0400 Cc: nea@ietf.org, iesg@ietf.org, ietf@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 >> do you have actual statistics to back that up? > > It's not meant to be an exact number, but it's pretty close to being > correct, in my experience. one of my axioms for dealing with the Internet is that people's experiences (and assumptions) about what is typical vary widely - no single person's assumptions holds true in general. the consequence for protocol standards is that they need to work in the face of a variety of assumptions/scenarios. >> there are better (more reliable, more secure, more effective, >> cheaper) ways of providing a set of functions at a user terminal >> than to give everyone user-programmable machines and then have the >> network insist that they all have a rigidly controlled >> configuration... > > Yes. And there are mistakes in IETF protocols that have been > deployed for decades, too. What are we supposed to tell the people > who have billions of dollars invested in their current systems? "You > got it wrong, we're not going to come up with a solution to your > problems." ? no, we say "we're going to try to give you an evolution path that doesn't break compatibility with the investment you've made in our technology". however realize that the half-life of a computer system is pretty short compared to the lifetime of a successful protocol standard. there's more investment in the protocols than in the hardware, and the protocols don't generally assume user-programmable machines on everyone's desks. (a few of them predate those days) Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 24 16:01:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcSSO-0006yA-3b; Tue, 24 Oct 2006 16:01:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcRGi-0002Fx-6M; Tue, 24 Oct 2006 14:44:56 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcRGd-00013G-UU; Tue, 24 Oct 2006 14:44:56 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id 525F556458; Tue, 24 Oct 2006 14:43:44 -0400 (EDT) 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 NBHatfFYn30b; Tue, 24 Oct 2006 14:43:37 -0400 (EDT) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by shu.cs.utk.edu (Postfix) with ESMTP id 2BAEE56436; Tue, 24 Oct 2006 14:43:36 -0400 (EDT) Message-ID: <453E5F19.2070804@cs.utk.edu> Date: Tue, 24 Oct 2006 14:44:41 -0400 From: Keith Moore User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Alan DeKok Subject: Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) References: <20061024182917.9B86516CE0@mail.nitros9.org> In-Reply-To: <20061024182917.9B86516CE0@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: 08e48e05374109708c00c6208b534009 X-Mailman-Approved-At: Tue, 24 Oct 2006 16:01:01 -0400 Cc: nea@ietf.org, iesg@ietf.org, ietf@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 see how NEA is such a big philosophical change from existing > RADIUS practices. perhaps not, but I don't see how past mistakes are a justification for future ones. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 24 17:08:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcTVI-0005lM-Ln; Tue, 24 Oct 2006 17:08:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcTVH-0005lD-Bf for nea@ietf.org; Tue, 24 Oct 2006 17:08:07 -0400 Received: from wx-out-0506.google.com ([66.249.82.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcTVB-00088H-T1 for nea@ietf.org; Tue, 24 Oct 2006 17:08:07 -0400 Received: by wx-out-0506.google.com with SMTP id t4so2079199wxc for ; Tue, 24 Oct 2006 14:08:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=pTfdS6wWqz6X0jowvxAXGOTZKi7YLqkmAuo2BA49SCW0JE3cKzIciYPytqk18CEWZaz+gkqW/2UQQmubHcdziifs81ywkSYdMHoQqLIBbOJUlXAUHJDdwO58ivmjGrMb6Q3KleHzopmHguplKjrtt9CHQO/eE4whue74Qe6sFXQ= Received: by 10.65.250.11 with SMTP id c11mr8207210qbs; Tue, 24 Oct 2006 14:08:01 -0700 (PDT) Received: by 10.65.156.6 with HTTP; Tue, 24 Oct 2006 14:08:01 -0700 (PDT) Message-ID: Date: Tue, 24 Oct 2006 17:08:01 -0400 From: "Mike Fratto" To: "Keith Moore" Subject: Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) In-Reply-To: <453E784A.4080106@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: <20061024182917.9B86516CE0@mail.nitros9.org> <453E784A.4080106@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 > yes, but it's clear that NEA is intended to be used, and will be used, > as a mechanism to allow local networks to implement policies based on > machine configuration. the question is whether if is a good thing for > the Internet for IETF to endorse such mechanisms. The question in this thread seems to be whether the charter is worded satisfactorily. I think the decision to move the BoF forward and attempt to form a working group has been made regardless of the utility of the proposed NEA output. :P _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 24 17:09:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcTWJ-0005vQ-0e; Tue, 24 Oct 2006 17:09:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcTWH-0005vD-8E for nea@ietf.org; Tue, 24 Oct 2006 17:09:09 -0400 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 1GcTWB-0008Ol-Fi for nea@ietf.org; Tue, 24 Oct 2006 17:09:09 -0400 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 1GcTW9-0000yY-JK for nea@ietf.org; Wed, 25 Oct 2006 07:09:02 +1000 Received: (qmail 10379 invoked by uid 453); 24 Oct 2006 21:08:34 -0000 Received: from speedy.dhs (HELO speedy) (192.168.0.8) by dhs (qpsmtpd/0.31-dev) with ESMTP; Wed, 25 Oct 2006 07:08:34 +1000 From: "Darryl \(Dassa\) Lynch" To: Subject: RE: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) Date: Wed, 25 Oct 2006 07:08:58 +1000 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: Acb3aQ0YoMUbj1yTSlqc60Nhkg+RnwARqZNA In-Reply-To: <453E0649.2000503@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: >> -------- Original Message -------- >> >>> All, >>> >>> This charter is definitely clearer on some of the points that were >>> discussed based on the last version, but a couple of things still >>> remain to be clarified. Based on several discussions that we've had >>> lately, I have two suggestions for further clarity: >>> >>> 1. Let's add the text suggested by Harald and Lakshminath (there >>> seemed to be agreement on this text on the list). Quoting the >>> change proposed: >>> >>> Replace: >>> >>> "NEA can be limited in its applicability when the endpoint and the >>> organization providing network access are owned by different >>> parties." >>> >>> with >>> >>> "NEA is applicable to computing environments of enterprises 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. >> >> That seems overbroad, in particular because a laptop that >> connects to multiple networks cannot in general be expected >> to adhere to conflicting policies of the networks to which it >> connects. [...] 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: 92df29fa99cf13e554b84c8374345c17 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: >> -------- Original Message -------- >> >>> All, >>> >>> This charter is definitely clearer on some of the points that were >>> discussed based on the last version, but a couple of things still >>> remain to be clarified. Based on several discussions that we've had >>> lately, I have two suggestions for further clarity: >>> >>> 1. Let's add the text suggested by Harald and Lakshminath (there >>> seemed to be agreement on this text on the list). Quoting the >>> change proposed: >>> >>> Replace: >>> >>> "NEA can be limited in its applicability when the endpoint and the >>> organization providing network access are owned by different >>> parties." >>> >>> with >>> >>> "NEA is applicable to computing environments of enterprises 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. >> >> That seems overbroad, in particular because a laptop that >> connects to multiple networks cannot in general be expected >> to adhere to conflicting policies of the networks to which it >> connects. Why not, laptops already have to conform to some policies such as the addressing scheme in use on various networks they may attach to. I consider it unreasonable to support the notion any endpoint can ignore local policies. >> As far as I can tell, this is the crux of the problem with >> NEA - that in general it's simply unreasonable for a network >> to demand that every host that connect to it conform to >> arbitrary policies for configuration of those hosts. IETF >> should not be standardizing unreasonable expectations. And >> even if the behavior is in some limited set of circumstances >> reasonable (which is debatable), IMHO IETF should hesitate >> to define standards for corner cases. You consider it unreasonable, I consider the alternative unreasonable. Enforcing local policies is already happening, just with clunky tools and in a non-standard manner. NEA is one tool to help standardise the processes. >> (I do sympathize with the notion that the biggest threats to >> an enterprise network are from the hosts that connect >> directly to it, and so it makes sense to concentrate efforts >> for protecting the network at the points where those hosts attach to >> the network) It is really about choices, to make a decision or choice, information is necessary, NEA assists by providing information in a standard format, or will. >> The other problem I have with this charter is one that I >> have with many charters these days - it presupposes a >> particular design or architecture >> before the working group has actually met, when this >> should be an engineering decision taken by the consensus of >> the working group AFTER analysis of the problem space. Understand what you are saying but can't see any solutions. Darryl (Dassa) Lynch _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 24 17:55:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcUF5-0002Tu-Cd; Tue, 24 Oct 2006 17:55:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcUF4-0002Tn-F4 for nea@ietf.org; Tue, 24 Oct 2006 17:55:26 -0400 Received: from a.mail.sonic.net ([64.142.16.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcUEx-00074C-CU for nea@ietf.org; Tue, 24 Oct 2006 17:55:26 -0400 Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG [168.61.10.151]) (authenticated bits=0) by a.mail.sonic.net (8.13.8.Beta0-Sonic/8.13.7) with ESMTP id k9OLtDtM007774 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 24 Oct 2006 14:55:14 -0700 In-Reply-To: References: <20061024182917.9B86516CE0@mail.nitros9.org> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2857CBF3-09B2-4429-9CED-F4880CB6E952@mail-abuse.org> Content-Transfer-Encoding: 7bit From: Douglas Otis Subject: Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) Date: Tue, 24 Oct 2006 14:55:40 -0700 To: Mike Fratto X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 Oct 24, 2006, at 12:38 PM, Mike Fratto wrote: > For example, if an AV vendor called FOO wants to define an > attribute BAR for it's product, the NEA specifications should allow > for that without having to define a meaning for BAR or define an > action based on the presence or absence of BAR (which is a matter > of local policy). Nor are all products that implement NEA standards > required to support extensions by vendor FOO (also, a matter of > local policy). Keith made a good point about a client not being trusted to retain private keys. BAR must be verifiable to have meaning. In the case of an OS updates or AV utilities, a service can retain private keys, exchange updates, monitors results, and present signed certificates carrying a relevant time-stamp. The NEA server only needs to track desired posture certificate expiry without understanding the service. The issuer, class, and time-stamp should provide adequate flexibility for existing schemes. Checking standardized generic fields within certificates should simplify NEA related APIs. The resources for remediation or client postures can be determined through the use of a non-expired issuer/class/user-host posture- certificates. These certificates are provided by a separate external service. The issuer/class name of the certificate would determine what is being checked. issuer / class / time / user-host Foobar-OS/OS:SVR:I/1161043200/somebody@example.com -Doug _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 24 18:39:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcUvA-0001ZW-02; Tue, 24 Oct 2006 18:38:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcSwi-0000ZK-7d for nea@ietf.org; Tue, 24 Oct 2006 16:32:24 -0400 Received: from bes.cs.utk.edu ([160.36.56.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcSwe-000221-Vo for nea@ietf.org; Tue, 24 Oct 2006 16:32:24 -0400 Received: from localhost (localhost [127.0.0.1]) by bes.cs.utk.edu (Postfix) with ESMTP id EC9F1FD1F; Tue, 24 Oct 2006 16:31:50 -0400 (EDT) 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 kINu5O-9W7fW; Tue, 24 Oct 2006 16:31:45 -0400 (EDT) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by bes.cs.utk.edu (Postfix) with ESMTP id DD7C9FCDF; Tue, 24 Oct 2006 16:31:44 -0400 (EDT) Message-ID: <453E784A.4080106@cs.utk.edu> Date: Tue, 24 Oct 2006 16:32:10 -0400 From: Keith Moore User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Mike Fratto Subject: Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) References: <20061024182917.9B86516CE0@mail.nitros9.org> 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: d17f825e43c9aed4fd65b7edddddec89 X-Mailman-Approved-At: Tue, 24 Oct 2006 18:38:54 -0400 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 > There seems to be confusion among some about supporting a set of > protocols and formats and enforcing policy. The charter seems pretty > clear that the outut of the NEA is *not* attempting to dictate local > policy. yes, but it's clear that NEA is intended to be used, and will be used, as a mechanism to allow local networks to implement policies based on machine configuration. the question is whether if is a good thing for the Internet for IETF to endorse such mechanisms. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 24 18:39:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcUvA-0001Zj-4O; Tue, 24 Oct 2006 18:38:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcTk4-00049S-1U for nea@ietf.org; Tue, 24 Oct 2006 17:23:24 -0400 Received: from bes.cs.utk.edu ([160.36.56.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcTjz-0002HI-Pf for nea@ietf.org; Tue, 24 Oct 2006 17:23:24 -0400 Received: from localhost (localhost [127.0.0.1]) by bes.cs.utk.edu (Postfix) with ESMTP id 98392FD44; Tue, 24 Oct 2006 17:22:52 -0400 (EDT) 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 9zYjoFU7nWHq; Tue, 24 Oct 2006 17:22:44 -0400 (EDT) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by bes.cs.utk.edu (Postfix) with ESMTP id A9AF9FD29; Tue, 24 Oct 2006 17:22:43 -0400 (EDT) Message-ID: <453E843D.4010601@cs.utk.edu> Date: Tue, 24 Oct 2006 17:23:09 -0400 From: Keith Moore User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Mike Fratto Subject: Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) References: <20061024182917.9B86516CE0@mail.nitros9.org> <453E784A.4080106@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: 08e48e05374109708c00c6208b534009 X-Mailman-Approved-At: Tue, 24 Oct 2006 18:38:54 -0400 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 question in this thread seems to be whether the charter is worded > satisfactorily. I think the decision to move the BoF forward and > attempt to form a working group has been made regardless of the > utility of the proposed NEA output. :P has IESG decided to charter the group even before review is complete? Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 24 18:39:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcUvB-0001bj-F8; Tue, 24 Oct 2006 18:38:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcUrM-0006x1-Pc; Tue, 24 Oct 2006 18:35:00 -0400 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcUrL-0002Hk-Dy; Tue, 24 Oct 2006 18:35:00 -0400 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M8QQLGKON400FHTY@mauve.mrochek.com>; Tue, 24 Oct 2006 15:34:55 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M8QHM5FCSW00W15M@mauve.mrochek.com>; Tue, 24 Oct 2006 15:34:53 -0700 (PDT) To: Keith Moore Message-id: <01M8QQLFT7PK00W15M@mauve.mrochek.com> Date: Tue, 24 Oct 2006 15:21:17 -0700 (PDT) From: Ned Freed Subject: Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) In-reply-to: "Your message dated Tue, 24 Oct 2006 12:51:42 -0400" <453E449E.7060204@cs.utk.edu> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed References: <453E0649.2000503@cs.utk.edu> <453E449E.7060204@cs.utk.edu> X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-Mailman-Approved-At: Tue, 24 Oct 2006 18:38:54 -0400 Cc: nea@ietf.org, iesg@ietf.org, ietf@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 > > Whether a company manageing a network demands that all hosts meet a > > specific policy is a local policy issue and the charter specifically > > addresses this concern: > > > > "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. " > what the WG charter says and how the WG output is used are different > things. IMHO we need to consider the potential unintended consequences > of our efforts in IETF, not just what we intend. Keith, I have two big problems with this position. First of all, I have grave doubts our crystal ball is up to the task of forseeing all unintended consequences of the protocol we develope. So while I think some consideration of consequences is OK, we also need to keep in mind that we collectively pretty much suck at predicting the future. Second, consequences don't just attach to the roads we take, they also attach to the roads not taken. When we say "no" to something it often ends up being done in an ad hoc way that can potentially be far more damaging to the network than had we created a standard with the proper security mechanisms, applicability statements, and so on. I also think NEA is a good example of something that will cause a lot less problems if we do it right than if it is done in a bad and proprietary way. I started hearing talk about implementating NEA-like mechanisms at several large sites long before I ever heard of NEA. I therefroe believe that mechanisms to do this are going to be developed and deployed no matter what the IETF does. The only question is whether or not we're going to have a say in what gets done. I really don't want to see a situation arise where I can't use, say, my Linux laptop somwhere because the necessary secret handshake is some proprietary glop that only Windoze boxes can do. Ned _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 24 18:39:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcUvA-0001Zj-4O; Tue, 24 Oct 2006 18:38:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcTk4-00049S-1U for nea@ietf.org; Tue, 24 Oct 2006 17:23:24 -0400 Received: from bes.cs.utk.edu ([160.36.56.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcTjz-0002HI-Pf for nea@ietf.org; Tue, 24 Oct 2006 17:23:24 -0400 Received: from localhost (localhost [127.0.0.1]) by bes.cs.utk.edu (Postfix) with ESMTP id 98392FD44; Tue, 24 Oct 2006 17:22:52 -0400 (EDT) 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 9zYjoFU7nWHq; Tue, 24 Oct 2006 17:22:44 -0400 (EDT) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by bes.cs.utk.edu (Postfix) with ESMTP id A9AF9FD29; Tue, 24 Oct 2006 17:22:43 -0400 (EDT) Message-ID: <453E843D.4010601@cs.utk.edu> Date: Tue, 24 Oct 2006 17:23:09 -0400 From: Keith Moore User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Mike Fratto Subject: Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) References: <20061024182917.9B86516CE0@mail.nitros9.org> <453E784A.4080106@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: 08e48e05374109708c00c6208b534009 X-Mailman-Approved-At: Tue, 24 Oct 2006 18:38:54 -0400 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 question in this thread seems to be whether the charter is worded > satisfactorily. I think the decision to move the BoF forward and > attempt to form a working group has been made regardless of the > utility of the proposed NEA output. :P has IESG decided to charter the group even before review is complete? Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 24 18:39:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcUvB-0001bj-F8; Tue, 24 Oct 2006 18:38:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcUrM-0006x1-Pc; Tue, 24 Oct 2006 18:35:00 -0400 Received: from [206.117.180.234] (helo=mauve.mrochek.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcUrL-0002Hk-Dy; Tue, 24 Oct 2006 18:35:00 -0400 Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M8QQLGKON400FHTY@mauve.mrochek.com>; Tue, 24 Oct 2006 15:34:55 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M8QHM5FCSW00W15M@mauve.mrochek.com>; Tue, 24 Oct 2006 15:34:53 -0700 (PDT) To: Keith Moore Message-id: <01M8QQLFT7PK00W15M@mauve.mrochek.com> Date: Tue, 24 Oct 2006 15:21:17 -0700 (PDT) From: Ned Freed Subject: Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) In-reply-to: "Your message dated Tue, 24 Oct 2006 12:51:42 -0400" <453E449E.7060204@cs.utk.edu> MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed References: <453E0649.2000503@cs.utk.edu> <453E449E.7060204@cs.utk.edu> X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-Mailman-Approved-At: Tue, 24 Oct 2006 18:38:54 -0400 Cc: nea@ietf.org, iesg@ietf.org, ietf@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 > > Whether a company manageing a network demands that all hosts meet a > > specific policy is a local policy issue and the charter specifically > > addresses this concern: > > > > "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. " > what the WG charter says and how the WG output is used are different > things. IMHO we need to consider the potential unintended consequences > of our efforts in IETF, not just what we intend. Keith, I have two big problems with this position. First of all, I have grave doubts our crystal ball is up to the task of forseeing all unintended consequences of the protocol we develope. So while I think some consideration of consequences is OK, we also need to keep in mind that we collectively pretty much suck at predicting the future. Second, consequences don't just attach to the roads we take, they also attach to the roads not taken. When we say "no" to something it often ends up being done in an ad hoc way that can potentially be far more damaging to the network than had we created a standard with the proper security mechanisms, applicability statements, and so on. I also think NEA is a good example of something that will cause a lot less problems if we do it right than if it is done in a bad and proprietary way. I started hearing talk about implementating NEA-like mechanisms at several large sites long before I ever heard of NEA. I therefroe believe that mechanisms to do this are going to be developed and deployed no matter what the IETF does. The only question is whether or not we're going to have a say in what gets done. I really don't want to see a situation arise where I can't use, say, my Linux laptop somwhere because the necessary secret handshake is some proprietary glop that only Windoze boxes can do. Ned _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Oct 25 02:04:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcbrl-0002IX-UK; Wed, 25 Oct 2006 02:03:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcZNq-0007JK-KT; Tue, 24 Oct 2006 23:24:50 -0400 Received: from ka.cs.utk.edu ([160.36.56.221]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcZNp-0001sw-8N; Tue, 24 Oct 2006 23:24:50 -0400 Received: from localhost (localhost [127.0.0.1]) by ka.cs.utk.edu (Postfix) with ESMTP id 823C42F242; Tue, 24 Oct 2006 23:25:42 -0400 (EDT) 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 u3P2KNcvIrzQ; Tue, 24 Oct 2006 23:25:37 -0400 (EDT) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by ka.cs.utk.edu (Postfix) with ESMTP id 0BED92F236; Tue, 24 Oct 2006 23:25:35 -0400 (EDT) Message-ID: <453ED8F6.60907@cs.utk.edu> Date: Tue, 24 Oct 2006 23:24:38 -0400 From: Keith Moore User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Ned Freed Subject: Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) References: <453E0649.2000503@cs.utk.edu> <453E449E.7060204@cs.utk.edu> <01M8QQLFT7PK00W15M@mauve.mrochek.com> In-Reply-To: <01M8QQLFT7PK00W15M@mauve.mrochek.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc X-Mailman-Approved-At: Wed, 25 Oct 2006 02:03:53 -0400 Cc: nea@ietf.org, iesg@ietf.org, ietf@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 >> what the WG charter says and how the WG output is used are >> different things. IMHO we need to consider the potential >> unintended consequences of our efforts in IETF, not just what we >> intend. > > Keith, I have two big problems with this position. > > First of all, I have grave doubts our crystal ball is up to the task > of forseeing all unintended consequences of the protocol we develope. > So while I think some consideration of consequences is OK, we also > need to keep in mind that we collectively pretty much suck at > predicting the future. I agree. But we don't usually have to actually predict the future in order to make ourselves aware of the potential pitfalls associated with something that we're thinking about doing, and to take those pitfalls into account in a design. In the case of NEA those pitfalls aren't too hard to figure out, but nothing has been proposed to address those pitfalls other than inconsequential wording suggestions about the scope of the WG. The WG scope isn't the problem so much as the protocol itself. Figure out a way to keep the protocol from doing harm, and I'll be much more interested. > Second, consequences don't just attach to the roads we take, they > also attach to the roads not taken. When we say "no" to something it > often ends up being done in an ad hoc way that can potentially be far > more damaging to the network than had we created a standard with the > proper security mechanisms, applicability statements, and so on. I agree also that this potential exists. One of the things that really bothers me about our WG creation process is that a lot of fundamental decisions about direction of a particular effort tend to be made with zero investigation of alternatives and little or no community input. Whatever gets written into the charter is essentially carved in stone, and sometimes the WGs don't even pay attention to whatever limitations are included in their charter - they just continue with whatever they started doing before the charter was approved. In the case of NEA (as in so many other cases) we (the wider community) are being presented with this as a done deal - either take this charter (modulo minor wording changes) or leave it. I sincerely believe that IETF can do something useful in this general space, but I also sincerely doubt that NEA is the right direction. And yet, we're already asking a yes or no question when it really should be a "how can we address these problems?" question. Is the wrong direction better than no contribution from IETF in this case? It's not entirely clear, but I suspect that in this case the answer is no. And yes, I'm also aware that historically when we charter a WG to study a problem and draft "requirements", they tend to wallow around and not produce much of any use. > I also think NEA is a good example of something that will cause a lot > less problems if we do it right than if it is done in a bad and > proprietary way. I started hearing talk about implementating NEA-like > mechanisms at several large sites long before I ever heard of NEA. I > therefroe believe that mechanisms to do this are going to be > developed and deployed no matter what the IETF does. I agree. But is that really so bad? To me it isn't axiomatic that the Internet is better off if every application type that is widely deployed has a standard protocol. DRM is a good example - until DRM can, at a minimum, preserve a balance of interests between the public and rightsholders, the Internet is better off without standards for DRM. A similar argument can be made for NEA - there needs to be a way to preserve a balance between the rights of host owners and the rights of network owners. (one particularly chilling scenario is for a network to use NEA to force every host that connects to it to implement a form of DRM that compromises the interests of the public) The only > question is whether or not we're going to have a say in what gets > done. I really don't want to see a situation arise where I can't use, > say, my Linux laptop somwhere because the necessary secret handshake > is some proprietary glop that only Windoze boxes can do. IMHO, that is _more_ likely to happen if NEA is standardized than if there are some number of proprietary solutions. Ketih _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Oct 25 08:02:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GchSe-0005SN-Nf; Wed, 25 Oct 2006 08:02:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GchSd-0005SH-6d for nea@ietf.org; Wed, 25 Oct 2006 08:02:19 -0400 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GchSZ-0000Lz-TU for nea@ietf.org; Wed, 25 Oct 2006 08:02:19 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=IBN0qhDttK0e0O/LukWPL4kO8HRqmdIXp8Z+aCP2j42RmA32S61LCQggxf3+7kGc; h=Received:Message-ID:From:To: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.102] (helo=gw) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1GchSE-0005tc-T7; Wed, 25 Oct 2006 08:02:11 -0400 Message-ID: <011801c6f82d$64d84670$010aa8c0@home.glassey.com> From: "todd glassey" To: "Harald Tveit Alvestrand" , , Date: Wed, 25 Oct 2006 05:01:22 -0700 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: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec798e63d9448113e4c373e0a8640756613d350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 4.246.45.102 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Cc: Subject: [Nea] The NEA conversation on the IETF list is on the wrong list. 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 FWIW - The NEA conversation needs to be moved to the NEA List from the IETF list. It is inappropriate there. Todd Glassey _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Oct 25 11:16:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GckUB-00042Y-SA; Wed, 25 Oct 2006 11:16:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GckUB-00042S-0q for nea@ietf.org; Wed, 25 Oct 2006 11:16:07 -0400 Received: from is1.enterasys.com ([63.160.138.52]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GckU2-0006Uq-OH for nea@ietf.org; Wed, 25 Oct 2006 11:16:06 -0400 Received: from MABOSEVS2.ets.enterasys.com ([134.141.77.30]) by nhrocefe2.ets.enterasys.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 11:15:57 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) Date: Wed, 25 Oct 2006 11:15:57 -0400 Message-ID: <3CFB564E055A594B82C4FE89D21565605A493C@MABOSEVS2.ets.enterasys.com> In-Reply-To: <453E784A.4080106@cs.utk.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) Thread-Index: Acb3vURIygDDlUrKQIKzNr0Eod5ytwAiF59g From: "Nelson, David" To: X-OriginalArrivalTime: 25 Oct 2006 15:15:57.0528 (UTC) FILETIME=[78D64580:01C6F848] X-imss-version: 2.043 X-imss-result: Passed X-imss-approveListMatch: *@enterasys.com X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Keith Moore writes... > yes, but it's clear that NEA is intended to be used, and > will be used, as a mechanism to allow local networks to=20 > implement policies based on machine configuration. Yes, that is the crux of the matter. > the question is whether if is a good thing for > the Internet for IETF to endorse such mechanisms. Good thing for the Internet? Eh? I don't understand. One may very well posit a question about the tradeoffs between "safe computing" and "personal freedom". This is clearly a Layer 9 discussion, however. :-) _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Oct 25 12:00:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GclBN-00014W-39; Wed, 25 Oct 2006 12:00:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GclBL-00014M-Ma for nea@ietf.org; Wed, 25 Oct 2006 12:00:43 -0400 Received: from nz-out-0102.google.com ([64.233.162.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GclBG-0006Ay-VM for nea@ietf.org; Wed, 25 Oct 2006 12:00:43 -0400 Received: by nz-out-0102.google.com with SMTP id 13so131900nzn for ; Wed, 25 Oct 2006 09:00:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=KxjymLhCxwA8Bj7d2iEFOyb+BEgbgaWKysMUVa8iu5iSmlhFOwlO8gpoXuXghktgvBxwcjUEHLW1S/LwfzA8H2pEnHNMQOuTUdYmryh0FeS8T7wo7N7FcPCZ+U2p1q+5PsvHrY1iYoPZcFNVZnvRPXTzTrMowOw6FVPDtQRD+UU= Received: by 10.64.199.8 with SMTP id w8mr1082088qbf; Wed, 25 Oct 2006 09:00:38 -0700 (PDT) Received: by 10.65.156.6 with HTTP; Wed, 25 Oct 2006 09:00:38 -0700 (PDT) Message-ID: Date: Wed, 25 Oct 2006 12:00:38 -0400 From: "Mike Fratto" To: "Keith Moore" Subject: Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) In-Reply-To: <453ED8F6.60907@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: <453E0649.2000503@cs.utk.edu> <453E449E.7060204@cs.utk.edu> <01M8QQLFT7PK00W15M@mauve.mrochek.com> <453ED8F6.60907@cs.utk.edu> X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: nea@ietf.org, Ned Freed 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 only > > question is whether or not we're going to have a say in what gets > > done. I really don't want to see a situation arise where I can't use, > > say, my Linux laptop somwhere because the necessary secret handshake > > is some proprietary glop that only Windoze boxes can do. > > IMHO, that is _more_ likely to happen if NEA is standardized than if > there are some number of proprietary solutions. Keith, your argument is that closed solutions are more likely to support more OS's and platforms than an open systems? Do I have that right? Let me blather on about OS support. Microsoft NAP will support Windows XP, Longhorn, and Vista. That's it for now. Cisco's NAC (not the NAC Appliance, formerly Clean Access) support Windows, Linux, and they claim MacOSX is coming with CSA. The vendors supporting the TCG TNC break out heavily on the Windows side. Of the 21 NAC vendors I have talked to in the last few months (It's what I do in my day job), all of the products support Windows from W2K onward. 5 support Linux OS's either using a Java applet or rpc. 10 suport MacOSX. Support for devices other than workstations and servers is even worse, dare I say it, virtually non-existent. You should check for yourself, but I think you will find that the reality doesn't jibe with your opinion. What vendors tell me is they will support those other OS's when they see demand. In other words, when someone is willing to pay for it. What customers will often do is either not demand support and do without, or go elsewhere. Few vendors actually add support for other OS's after a product ships unless it is roadmapped early on. Hopefully the work of a group like the NEA, if it is formed, will allow agents from one vendor talk to server from another. Standardizing communications, either using existing protocols or developing new protocols, that any developer can use and should in theory, allow endpoints talk to other components is going to hinder multi-os support? :) That is a good thing (tm). _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Oct 25 17:05:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcpwe-0004RX-2o; Wed, 25 Oct 2006 17:05:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcmYc-0002ED-Sz for nea@ietf.org; Wed, 25 Oct 2006 13:28:50 -0400 Received: from shu.cs.utk.edu ([160.36.56.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcmYb-0007DZ-LA for nea@ietf.org; Wed, 25 Oct 2006 13:28:50 -0400 Received: from localhost (localhost [127.0.0.1]) by shu.cs.utk.edu (Postfix) with ESMTP id E287D56448; Wed, 25 Oct 2006 13:27:41 -0400 (EDT) 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 Jbhf1IJksHY6; Wed, 25 Oct 2006 13:27:38 -0400 (EDT) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by shu.cs.utk.edu (Postfix) with ESMTP id 6F6D856443; Wed, 25 Oct 2006 13:27:38 -0400 (EDT) Date: Wed, 25 Oct 2006 13:30:14 -0400 From: Keith Moore To: "Mike Fratto" Subject: Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) Message-Id: <20061025133014.9748436b.moore@cs.utk.edu> In-Reply-To: References: <453E0649.2000503@cs.utk.edu> <453E449E.7060204@cs.utk.edu> <01M8QQLFT7PK00W15M@mauve.mrochek.com> <453ED8F6.60907@cs.utk.edu> 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: 93238566e09e6e262849b4f805833007 X-Mailman-Approved-At: Wed, 25 Oct 2006 17:05:50 -0400 Cc: nea@ietf.org, ned.freed@mrochek.com 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 only > > > question is whether or not we're going to have a say in what gets > > > done. I really don't want to see a situation arise where I can't use, > > > say, my Linux laptop somwhere because the necessary secret handshake > > > is some proprietary glop that only Windoze boxes can do. > > > > IMHO, that is _more_ likely to happen if NEA is standardized than if > > there are some number of proprietary solutions. > > Keith, your argument is that closed solutions are more likely to > support more OS's and platforms than an open systems? Do I have that > right? no, my argument is that networks are less likely to impose draconian policies on hosts if there is no standard interface by which they can implement those draconian policies. I'm not saying that no networks will do this (as some are already doing this), but I do think it's less likely that networks in will do this - particularly access networks as opposed to enterprise networks. (most enterprise networks are a lost cause already, IMHO, as too many enterprises have standardized on windows and accepted the crippling of their networks that inevitably follows.) Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Oct 26 14:51:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdAKF-0000aA-Jw; Thu, 26 Oct 2006 14:51:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdAKE-0000Zs-6t for nea@ietf.org; Thu, 26 Oct 2006 14:51:34 -0400 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 1GdAK8-0000mz-Sy for nea@ietf.org; Thu, 26 Oct 2006 14:51:34 -0400 Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 954E916DDE; Thu, 26 Oct 2006 14:40:57 -0400 (EDT) From: "Alan DeKok" To: Keith Moore Subject: Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) In-Reply-To: Your message of "Wed, 25 Oct 2006 13:30:14 EDT." <20061025133014.9748436b.moore@cs.utk.edu> Date: Thu, 26 Oct 2006 14:40:57 -0400 Message-Id: <20061026184057.954E916DDE@mail.nitros9.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ned.freed@mrochek.com, 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: > no, my argument is that networks are less likely to impose draconian > policies on hosts if there is no standard interface by which they can > implement those draconian policies. The flies in the face of 20 years of computing history. Customers want a solution, and vendors will supply one to them. If there is no standards-based solution, vendors will supply proprietary solutions. This goes for both desktop applications and networking protocols. The only way to guarantee a free and open network is to build it on free and open standards. The alternative is that vendors build solutions for the majority OS, and tell everyone else "too bad". There are any number of examples of this happening over the past 3 decades. The solution to the proprietary problem is *always* open standards. Make no mistake, people *will* be deploying access controls for their network. The only choice in front of us now is whether those controls are proprietary, or standards-based. > I'm not saying that no networks > will do this (as some are already doing this), but I do think it's less > likely that networks in will do this - particularly access networks as > opposed to enterprise networks. I'm not sure any NEA variant will be applied to access networks. 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 Thu Oct 26 16:44:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdC5a-00088s-S3; Thu, 26 Oct 2006 16:44:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdBMu-00021s-V6 for nea@ietf.org; Thu, 26 Oct 2006 15:58:24 -0400 Received: from woodstock.binhost.com ([66.150.120.2]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GdBEd-0007D5-7W for nea@ietf.org; Thu, 26 Oct 2006 15:49:52 -0400 Received: (qmail 6482 invoked by uid 0); 26 Oct 2006 19:49:45 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.126.161.75) by woodstock.binhost.com with SMTP; 26 Oct 2006 19:49:45 -0000 Message-Id: <7.0.0.16.2.20061026154034.07afebd8@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Thu, 26 Oct 2006 15:49:45 -0400 To: nea@ietf.org From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Subject: [Nea] NEA WG Chartered by the IESG 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 today's IESG Telechat, the NEA WG Charter was approved. There were two changes made to the proposed charter text that was posted two weeks ago. First, the text that was discussed on this list about the enterprise environment was inserted. I made a very minor edit that I hope that improves the flow, without altering the meaning in any way. Second, only the milestones related to the requirements document are approved. The idea is to get going with the architecture, requirements, and security analysis. These are all included in one document. The other milestones will be approved by me (not a re-charter action) once the IETF Last Call demonstrates that the NEA WG is moving in an direction that the community can support. The approved charter is below. Russ = = = = = = = = = = Chair(s): Steve Hanna Susan Thomson Security Area Director(s): Russ Housley Sam Hartman Security Area Advisor: Russ Housley Mailing List: nea@ietf.org Description of Working Group: Network Endpoint Assessment (NEA) architectures have been implemented in the industry 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. An endpoint that does not comply with posture policy may be vulnerable to a number of known threats that may exist on the network. The intent of NEA is to facilitate corrective actions to address these known vulnerabilities before a host is exposed to potential attack. 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. Posture refers to the hardware or software configuration of an endpoint as it pertains to an organization's security 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. 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. 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 From nea-bounces@ietf.org Thu Oct 26 18:11:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdDLL-00036u-FH; Thu, 26 Oct 2006 18:04:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdDKp-00015e-5b for nea@ietf.org; Thu, 26 Oct 2006 18:04:23 -0400 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 1GdDKh-0007JN-K8 for nea@ietf.org; Thu, 26 Oct 2006 18:04:18 -0400 Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id 7CD5516DDE; Thu, 26 Oct 2006 17:53:48 -0400 (EDT) From: "Alan DeKok" To: Keith Moore Subject: Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) In-Reply-To: Your message of "Thu, 26 Oct 2006 17:29:01 EDT." <4541289D.1090204@cs.utk.edu> Date: Thu, 26 Oct 2006 17:53:48 -0400 Message-Id: <20061026215348.7CD5516DDE@mail.nitros9.org> X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ned.freed@mrochek.com, 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: > my argument is that standardization of NEA as it is currently understood > (whether through IETF or as a vendor de facto standard) would be a bad > thing for the Internet community because it would enable more networks > to impose draconian policies that were harmful to users. Again, what about the owners of the networks involved? Or the people who own the machines the users are using? It is perfectly reasonable for an enterprise to control access to its network. Doing so across heterogeneous platforms requires standards-based solutions. Forcing people to authenticate themselves through PPP before they access an ISP's services can be viewed as a draconian limitation on their freedoms. So? There's a gray area... where do we draw the line? > for instance, if NEA were defined in such a way that the protocol was > incapable of asking any questions of a host that were not themselves > standardized, or were defined in such a way that there was no way for a > host to sign its answers to questions (so that any host would be capable > of lying). but I have a hard time seeing IETF defining NEA in that way. Hmm... those requirements would effectively define NEA to be useless. > > I'm not sure any NEA variant will be applied to access networks. > > yup. pretend it's not a problem, and maybe the problem will go away. Let's turn of all network access controls, then. No relationship with an ISP? No problem! The IETF says authenticating yourself is a bad idea, go ahead, surf the net without paying! Asking via DHCP to be allocated the IP of the local DNS server? No problem! Allowing the network admin to control the network he owns is a bad idea, allocate away! There has to be a happy medium in between completely open and completely locked down. Likewise, there has to be a happy medium between fact-based discussion and ridicule. 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 Thu Oct 26 20:42:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdFnL-0004YE-TH; Thu, 26 Oct 2006 20:41:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdFhZ-0002p3-Tv for nea@ietf.org; Thu, 26 Oct 2006 20:36:01 -0400 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 1GdFbq-00017C-EW for nea@ietf.org; Thu, 26 Oct 2006 20:30:08 -0400 Received: from newgiles.nitros9.org (localhost [127.0.0.1]) by mail.nitros9.org (Postfix) with ESMTP id E1A5E16DDE; Thu, 26 Oct 2006 20:19:39 -0400 (EDT) From: "Alan DeKok" To: Keith Moore Subject: Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) In-Reply-To: Your message of "Thu, 26 Oct 2006 19:47:00 EDT." <454148F4.6090101@cs.utk.edu> Date: Thu, 26 Oct 2006 20:19:39 -0400 Message-Id: <20061027001939.E1A5E16DDE@mail.nitros9.org> X-Spam-Score: 0.1 (/) 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 Keith Moore wrote: > I don't accept as an axiom that it's perfectly reasonable for an > enterprise to control access to its network based on whether the hosts > that attach to the network are willing to run spyware. Giving it a negative label isn't the same as asserting it has negative value. Companies already require certain virus scanners to be installed, or VPN software, etc. I'm not saying you're wrong, I'm playing a bit of Devil's advocate based on conversations with people who plan on deploying it, for the reasons I've been discussing. > there's a broad consensus that access controls at their current level of > precision are useful and generally beneficial. there's not (afaik) a > broad consensus that access controls at the level of precision > facilitated by NEA are a good thing. Agreed. Many of the benefits of NEA can be achieved by simple MAC address filtering, guest portals, 802.1x, VLAN assignment, etc. That's NETWORK access control, as opposed to controlling network access based on the contents of the hosts hard drive. > maybe NEA is going down a completely wrong path. a major premise behind > NEA seems to be that networks can be made more secure if host operating > systems and applications are kept at a current patch level. I would phrase that as "kept at a KNOWN configuration". And that's not altogther wrong, or unreasonable. I would be happy if I could get notified when my core router's configuration changed unexpectedly... > now you're proposing that other kinds of hosts be crippled > and essentially taxed to make up for the market's lack of foresight and > the gross negligence of that vendor. That is one take on it. Another is that a legal issue is being solved with a technical solution. i.e. prove the software you're running in a publicly traded company is all legal. Solution? Instrument every machine on the network to tell an inventory-control system what it's running. That looks a whole lot like NEA, albeit with a completely different justification. and it has nothing to do with security, or OS, either. :) > However, I also see numerous potential problems associated with a > mechanism that tries to establish that trustworthiness by examining > the configurations of those hosts. Yup. The choices I've seen are to either have *zero* information about what's on the network, or to implement a hokey mechanism to maybe get some potentially untrustworthy information. That's a bad set of alternatives... > And there's a very real potential for NEA doing more harm than > good unless those problems are understood and addressed. I think we can characterize the problem a little more quantitatively. Listing problems and solutions would be good, if I can find the time... 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 Thu Oct 26 20:43:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdFoM-0005Y0-Qg; Thu, 26 Oct 2006 20:43:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdFoL-0005Xl-RG for nea@ietf.org; Thu, 26 Oct 2006 20:43:01 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdFoJ-00042R-E1 for nea@ietf.org; Thu, 26 Oct 2006 20:43:01 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7R008XQRI3T7@szxga01-in.huawei.com> for nea@ietf.org; Fri, 27 Oct 2006 08:46:52 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J7R008IRRI3VT@szxga01-in.huawei.com> for nea@ietf.org; Fri, 27 Oct 2006 08:46:51 +0800 (CST) Received: from lenovo6424df74 ([10.78.36.131]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J7R00BPPRKW4Z@szxml03-in.huawei.com> for nea@ietf.org; Fri, 27 Oct 2006 08:48:32 +0800 (CST) Date: Fri, 27 Oct 2006 08:42:03 +0800 From: yinhan Subject: Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) To: Alan DeKok , Keith Moore Message-id: <008201c6f960$b8f37f20$83244e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20061026215348.7CD5516DDE@mail.nitros9.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: nea@ietf.org, ned.freed@mrochek.com 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: "Alan DeKok" To: "Keith Moore" Cc: ; Sent: Friday, October 27, 2006 5:53 AM Subject: Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) > Keith Moore wrote: >> my argument is that standardization of NEA as it is currently understood >> (whether through IETF or as a vendor de facto standard) would be a bad >> thing for the Internet community because it would enable more networks >> to impose draconian policies that were harmful to users. > > Again, what about the owners of the networks involved? Or the > people who own the machines the users are using? It is perfectly > reasonable for an enterprise to control access to its network. Doing > so across heterogeneous platforms requires standards-based solutions. > > Forcing people to authenticate themselves through PPP before they > access an ISP's services can be viewed as a draconian limitation on > their freedoms. So? There's a gray area... where do we draw the line? > >> for instance, if NEA were defined in such a way that the protocol was >> incapable of asking any questions of a host that were not themselves >> standardized, or were defined in such a way that there was no way for a >> host to sign its answers to questions (so that any host would be capable >> of lying). but I have a hard time seeing IETF defining NEA in that way. > > Hmm... those requirements would effectively define NEA to be useless. > >> > I'm not sure any NEA variant will be applied to access networks. >> >> yup. pretend it's not a problem, and maybe the problem will go away. > > Let's turn of all network access controls, then. No relationship > with an ISP? No problem! The IETF says authenticating yourself is a > bad idea, go ahead, surf the net without paying! Asking via DHCP to > be allocated the IP of the local DNS server? No problem! Allowing > the network admin to control the network he owns is a bad idea, > allocate away! Ok, a user can get access to network through a and only one ISP access network. But, NEA should allow a host access to more than one enterprise network at the same time. > > There has to be a happy medium in between completely open and > completely locked down. Likewise, there has to be a happy medium > between fact-based discussion and ridicule. > > 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 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Oct 27 08:35:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdQvQ-0006gk-9S; Fri, 27 Oct 2006 08:35:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdCzO-0005lZ-2e for nea@ietf.org; Thu, 26 Oct 2006 17:42:14 -0400 Received: from bes.cs.utk.edu ([160.36.56.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdCmh-0001Kw-SW for nea@ietf.org; Thu, 26 Oct 2006 17:29:11 -0400 Received: from localhost (localhost [127.0.0.1]) by bes.cs.utk.edu (Postfix) with ESMTP id DCEBDFD01; Thu, 26 Oct 2006 17:28:39 -0400 (EDT) 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 L4ToHCxKtlmi; Thu, 26 Oct 2006 17:28:36 -0400 (EDT) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by bes.cs.utk.edu (Postfix) with ESMTP id 84C58FCE8; Thu, 26 Oct 2006 17:28:35 -0400 (EDT) Message-ID: <4541289D.1090204@cs.utk.edu> Date: Thu, 26 Oct 2006 17:29:01 -0400 From: Keith Moore User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Alan DeKok Subject: Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) References: <20061026184057.954E916DDE@mail.nitros9.org> In-Reply-To: <20061026184057.954E916DDE@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: c0bedb65cce30976f0bf60a0a39edea4 X-Mailman-Approved-At: Fri, 27 Oct 2006 08:35:03 -0400 Cc: ned.freed@mrochek.com, 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 >> no, my argument is that networks are less likely to impose draconian >> policies on hosts if there is no standard interface by which they can >> implement those draconian policies. > > The flies in the face of 20 years of computing history. Customers > want a solution, and vendors will supply one to them. If there is no > standards-based solution, vendors will supply proprietary solutions. > This goes for both desktop applications and networking protocols. I've been involved in IETF for not quite 20 years now, and I've seen this argument a lot during that time. Some vendors want to standardize something that is demonstrably harmful, so as to increase the available market for such products - and the argument is made that IETF should help them do so because it's better if users have the choice of which vendor's products they can buy to hurt themselves. I don't buy it. my argument is that standardization of NEA as it is currently understood (whether through IETF or as a vendor de facto standard) would be a bad thing for the Internet community because it would enable more networks to impose draconian policies that were harmful to users. IETF cannot really influence whether a particular vendor will be able to impose a proprietary standard on the market, but by choosing not to standardize NEA it could reduce the probability of having such a standard. since my belief is that any standard (whether an IETF standard or a de facto vendor standard) for NEA brings with it significant potential for harm, I argue that IETF should not encourage such standardization by chartering an NEA working group - at least until we understand how to construct a solution that has minimal potential to do such harm. in short, standardization of a protocol is not a good thing if the protocol being standardized does more harm to users than good. standardization of NEA would allow an access network to impose proprietary solutions on users for other protocols or applications, and would thereby _reduce_ the ability of users to choose the protocols or applications that best suited their needs. > The only way to guarantee a free and open network is to build it on > free and open standards. yes. and an NEA standard would the ability of users to choose free and open standards for everything except NEA. > Make no mistake, people *will* be deploying access controls for > their network. The only choice in front of us now is whether those > controls are proprietary, or standards-based. even if something like NEA is inevitable, it does not follow that IETF should encourage it. IETF should only encourage it if by encouraging it IETF can significantly reduce the potential for harm. merely having NEA be an IETF standard does not significantly reduce the potential for harm - concrete limitations in the NEA protocol are required to do that. for instance, if NEA were defined in such a way that the protocol was incapable of asking any questions of a host that were not themselves standardized, or were defined in such a way that there was no way for a host to sign its answers to questions (so that any host would be capable of lying). but I have a hard time seeing IETF defining NEA in that way. >> I'm not saying that no networks >> will do this (as some are already doing this), but I do think it's less >> likely that networks in will do this - particularly access networks as >> opposed to enterprise networks. > > I'm not sure any NEA variant will be applied to access networks. yup. pretend it's not a problem, and maybe the problem will go away. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Oct 27 08:35:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdQvQ-0006gp-D5; Fri, 27 Oct 2006 08:35:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdEwM-0006G1-OQ for nea@ietf.org; Thu, 26 Oct 2006 19:47:14 -0400 Received: from bes.cs.utk.edu ([160.36.56.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdEwL-00017v-As for nea@ietf.org; Thu, 26 Oct 2006 19:47:14 -0400 Received: from localhost (localhost [127.0.0.1]) by bes.cs.utk.edu (Postfix) with ESMTP id F1B4AFD04; Thu, 26 Oct 2006 19:46:44 -0400 (EDT) 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 7PMav3BFHUMJ; Thu, 26 Oct 2006 19:46:36 -0400 (EDT) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by bes.cs.utk.edu (Postfix) with ESMTP id 8B568FD01; Thu, 26 Oct 2006 19:46:34 -0400 (EDT) Message-ID: <454148F4.6090101@cs.utk.edu> Date: Thu, 26 Oct 2006 19:47:00 -0400 From: Keith Moore User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: Alan DeKok Subject: Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) References: <20061026215348.7CD5516DDE@mail.nitros9.org> In-Reply-To: <20061026215348.7CD5516DDE@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: e1b0e72ff1bbd457ceef31828f216a86 X-Mailman-Approved-At: Fri, 27 Oct 2006 08:35:03 -0400 Cc: ned.freed@mrochek.com, 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 argument is that standardization of NEA as it is currently understood >> (whether through IETF or as a vendor de facto standard) would be a bad >> thing for the Internet community because it would enable more networks >> to impose draconian policies that were harmful to users. > > Again, what about the owners of the networks involved? Or the > people who own the machines the users are using? It is perfectly > reasonable for an enterprise to control access to its network. Doing > so across heterogeneous platforms requires standards-based solutions. I don't accept as an axiom that it's perfectly reasonable for an enterprise to control access to its network based on whether the hosts that attach to the network are willing to run spyware. The reason we have standards for networking is so that a wide variety of hosts can attach to those networks and a wide variety of applications can run on those hosts. NEA defeats the very purpose of network standardization. > Forcing people to authenticate themselves through PPP before they > access an ISP's services can be viewed as a draconian limitation on > their freedoms. So? There's a gray area... where do we draw the line? like any other decision we make in IETF - we each choose what in our best personal judgment is best for the Internet as a whole. whatever consensus results from that set of individual choices is what we end up with. I'm arguing against standardizing spyware. I don't think it's hard to understand why standardized spyware is a bad idea. >> for instance, if NEA were defined in such a way that the protocol was >> incapable of asking any questions of a host that were not themselves >> standardized, or were defined in such a way that there was no way for a >> host to sign its answers to questions (so that any host would be capable >> of lying). but I have a hard time seeing IETF defining NEA in that way. > > Hmm... those requirements would effectively define NEA to be useless. indeed. but if we are left to choose between expending effort to produce something useless, expending effort to produce something harmful, and not expending any effort, the last option seems like the best one. >>> I'm not sure any NEA variant will be applied to access networks. >> yup. pretend it's not a problem, and maybe the problem will go away. > > Let's turn of all network access controls, then. there's a broad consensus that access controls at their current level of precision are useful and generally beneficial. there's not (afaik) a broad consensus that access controls at the level of precision facilitated by NEA are a good thing. > There has to be a happy medium in between completely open and > completely locked down. maybe we've already reached it, or something close to it. maybe NEA is going down a completely wrong path. a major premise behind NEA seems to be that networks can be made more secure if host operating systems and applications are kept at a current patch level. however we know from empirical evidence that the number of bugs in software tends (after an initial decrease) to increase over time (especially if new features are added, as is almost inevitable for any product that continues to be supported). maybe investing in an NEA solution is like a cat trying to chase its tail - an investment of effort that is not only wasted but results in additional burdens that persist long after the investment is made. we got ourselves into this mess because (a) the market chose a woefully insecure operating system as a de facto standard, (b) the vendor of that woefully insecure operating system failed to implement even the most basic of the security recommendations in MIME and other standards, and (c) that same vendor waited approximately 15 years after the rest of the industry (i.e. after the Morris worm) to start taking security seriously. now you're proposing that other kinds of hosts be crippled and essentially taxed to make up for the market's lack of foresight and the gross negligence of that vendor. yes, it's true that security holes exist on virtually all platforms, but no other platform has the combination of gross negligence and a monoculture that makes windoze such a fertile ground for malware. (and maybe vista will be better, but that remains to be seen...we've heard that before) -- let's back up a bit. I would be the first to say that the biggest threat to an enterprise network is from the hosts that attach to it. I'm very sympathetic to the idea that a network can to a useful degree protect itself, and other hosts on that network, from attack if it has better mechanisms to establish the trustworthiness of those hosts and the software that runs on those hosts. However, I also see numerous potential problems associated with a mechanism that tries to establish that trustworthiness by examining the configurations of those hosts. What I'm saying is, it's not acceptable to dismiss or overlook those problems. They're real. And there's a very real potential for NEA doing more harm than good unless those problems are understood and addressed. We in IETF have accepted a responsibility to do what we believe is best for the Internet as a whole, and it's hard to understand how we can be doing that if we're deliberately overlooking problems that have this much potential for harm. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Oct 27 12:23:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUUj-0005hJ-5e; Fri, 27 Oct 2006 12:23:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdUUh-0005hB-Ik for nea@ietf.org; Fri, 27 Oct 2006 12:23:43 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdUUf-0007iQ-9N for nea@ietf.org; Fri, 27 Oct 2006 12:23:43 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 27 Oct 2006 09:21:01 -0700 X-IronPort-AV: i="4.09,366,1157353200"; d="scan'208"; a="600149897:sNHT36680384" X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Oct 2006 12:23:39 -0400 Message-ID: In-Reply-To: <7.0.0.16.2.20061026154034.07afebd8@vigilsec.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Next steps for NEA WG Thread-index: Acb5P88kHZUUsEotQyqu8g1v5cJSgwAouGdg From: "Stephen Hanna" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Nea] Next steps for NEA WG 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 Congratulations and thanks to all on the approval of the NEA WG charter. It has not been easy and we have a lot more work to do but I think it will prove worthwhile in the end. Susan and I are working on an agenda for the first NEA WG meeting. We'll send email about that early next week. Certainly, the meeting will focus on the NEA Requirements I-D. For now, please make your travel arrangements. The NEA WG meeting is scheduled for Tuesday, November 7, 1520-1720 PST. Last-minute schedule changes are possible but fairly unlikely at this late date. If you're really into NEA, you may want to stay a while after the WG meeting. We'll probably have dinner after the WG and some people may get together on Wednesday to work on the Requirements I-D. Just a guess for now. We'll firm that up next week. See you in San Diego! Take care, Steve _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 31 16:55:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf1Zc-0000Lx-Ba; Tue, 31 Oct 2006 16:55:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf1ZZ-0000Hb-1W for nea@ietf.org; Tue, 31 Oct 2006 16:55:05 -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 1Gf1ZW-0005UC-Ns for nea@ietf.org; Tue, 31 Oct 2006 16:55:05 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-3.cisco.com with ESMTP; 31 Oct 2006 13:55:02 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9VLt2CX017445 for ; Tue, 31 Oct 2006 13:55:02 -0800 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k9VLsGbl013234 for ; Tue, 31 Oct 2006 13:55:02 -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); Tue, 31 Oct 2006 16:54:51 -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: Tue, 31 Oct 2006 16:54:50 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft agenda for NEA WG meeting at IETF67 Thread-Index: Acb9NzB3v+34RK7oR6ybyMwhu9OefA== From: "Susan Thomson \(sethomso\)" To: X-OriginalArrivalTime: 31 Oct 2006 21:54:51.0674 (UTC) FILETIME=[312D9FA0:01C6FD37] DKIM-Signature: a=rsa-sha1; q=dns; l=851; t=1162331702; x=1163195702; c=relaxed/simple; s=sjdkim5002; 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:Draft=20agenda=20for=20NEA=20WG=20meeting=20at=20IETF67; X=v=3Dcisco.com=3B=20h=3Dd6cOEP/N+faAyeey6W5SnEH5OyY=3D; b=HsP/WZttYpp00BHHI0wnTurHpvlNrA/78uoWPU3kay7vY/mJYKf0e7N/afDu/EiyVJjrFU6G /9R5nhVLDH9geCMbIhgPuXkKKLej/YUrujzG0OkoPBsTxYYVjYyhY2fE; Authentication-Results: sj-dkim-5.cisco.com; header.From=sethomso@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Nea] Draft agenda for NEA WG meeting at IETF67 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 NEA WG meeting will be held Tues Nov 7 at 15h20-17h20. The draft agenda is:=20 * Preliminaries (Minute-takers/Blue sheets) (5 mins) * Agenda bashing (5 mins) * Discussion of requirements I-D (90 mins) --- draft-khosravi-nea-requirements-01.txt=20 * Process for revising requirements I-D (20 mins) Please note that, because NEA WG has just recently been chartered, the requirements I-D has not been updated since before the last IETF and therefore does not reflect charter discussions since that time. The presentation on requirements will take into account the current charter, and the process for revising the requirements I-D is a topic for discussion at the meeting. Please contact the chairs with any other topics that you would like to see added to the agenda (shanna@juniper.net, sethomso@cisco.com). Thanks Susan _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 31 17:00:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf1f1-0004nM-Sg; Tue, 31 Oct 2006 17:00:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf1f0-0004nH-A8 for nea@ietf.org; Tue, 31 Oct 2006 17:00:42 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf1ey-0005z8-0j for nea@ietf.org; Tue, 31 Oct 2006 17:00:42 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 31 Oct 2006 14:00:39 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id k9VM0dV3030042 for ; Tue, 31 Oct 2006 14:00:39 -0800 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id k9VM0cOZ023695 for ; Tue, 31 Oct 2006 14:00:39 -0800 (PST) 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); Tue, 31 Oct 2006 17:00:38 -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: Tue, 31 Oct 2006 17:00:38 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NEA WG Dinner planning Thread-Index: Acb9N/+bgy/zbYJHSQuoNEaqZ7B/uQ== From: "Susan Thomson \(sethomso\)" To: X-OriginalArrivalTime: 31 Oct 2006 22:00:38.0895 (UTC) FILETIME=[002357F0:01C6FD38] DKIM-Signature: a=rsa-sha1; q=dns; l=360; t=1162332039; x=1163196039; c=relaxed/simple; s=sjdkim6002; 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:NEA=20WG=20Dinner=20planning; X=v=3Dcisco.com=3B=20h=3Dd3PP3Ly1ULYZZ+TJSB++ZIJN+aY=3D; b=r5Haw5jKhKy91efnq22yiijG7TzykPjS0rYOqgD1qkkGPYakxdu6B/gFYdRL0AzDZYKkFeU5 rqTMhpri5RiCzhz2uNcrxMvFBFFATSezmnavHSRyzA3fQm97nvt5CceT; Authentication-Results: sj-dkim-6.cisco.com; header.From=sethomso@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Nea] NEA WG Dinner planning X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Folks We are planning on organizing a dinner after the WG sessions on Tues Nov 7.=20 Please RSVP to me by Thursday Nov 2 if you would like to attend. Also, indicate dietary preferences/restrictions where necessary and I will try to accommodate. Thanks Susan PS. This is at the same time as the IETF social event, so you will need to choose. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 31 17:54:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf2V6-0005TQ-II; Tue, 31 Oct 2006 17:54:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf2V5-0005TF-9T for nea@ietf.org; Tue, 31 Oct 2006 17:54:31 -0500 Received: from ka.cs.utk.edu ([160.36.56.221]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf2V3-00031v-2s for nea@ietf.org; Tue, 31 Oct 2006 17:54:31 -0500 Received: from localhost (localhost [127.0.0.1]) by ka.cs.utk.edu (Postfix) with ESMTP id 6AF3A2F1FC; Tue, 31 Oct 2006 17:55: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 UqnwR1FUaR6X; Tue, 31 Oct 2006 17:55:21 -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 D7C5D2F1F5; Tue, 31 Oct 2006 17:55:16 -0500 (EST) Message-ID: <4547D419.8040402@cs.utk.edu> Date: Tue, 31 Oct 2006 17:54:17 -0500 From: Keith Moore User-Agent: Thunderbird 1.5.0.7 (Macintosh/20060909) MIME-Version: 1.0 To: "Susan Thomson (sethomso)" Subject: Re: [Nea] Draft agenda for NEA WG meeting at IETF67 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 > Please note that, because NEA WG has just recently been chartered, _has_ nea been chartered? I don't see any mention of it on the ietf working group web pages, haven't seen any announcement sent to ietf-announce, and can't find any mention of it in the minutes that have been posted. Keith _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Oct 31 18:16:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf2qg-0008VG-9r; Tue, 31 Oct 2006 18:16:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf2qe-0008T4-Fc for nea@ietf.org; Tue, 31 Oct 2006 18:16:48 -0500 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf2qc-0005Gi-Vn for nea@ietf.org; Tue, 31 Oct 2006 18:16:48 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 31 Oct 2006 15:16:47 -0800 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.20060308/8.12.11) with ESMTP id k9VNGkvF028495; Tue, 31 Oct 2006 18:16:46 -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 k9VNGkYJ012817; Tue, 31 Oct 2006 18:16:46 -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); Tue, 31 Oct 2006 18:16:46 -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] Draft agenda for NEA WG meeting at IETF67 Date: Tue, 31 Oct 2006 18:16:45 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Draft agenda for NEA WG meeting at IETF67 Thread-Index: Acb9P47AAe9sjERPQaGEhOicvFssRwAAM8SQ From: "Susan Thomson \(sethomso\)" To: "Keith Moore" X-OriginalArrivalTime: 31 Oct 2006 23:16:46.0627 (UTC) FILETIME=[A2B7EF30:01C6FD42] DKIM-Signature: a=rsa-sha1; q=dns; l=8616; t=1162336606; x=1163200606; 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:RE=3A=20[Nea]=20Draft=20agenda=20for=20NEA=20WG=20meeting=20at=20IETF67 |To:=22Keith=20Moore=22=20; X=v=3Dcisco.com=3B=20h=3DxEGR+y/jGoXuKF+MTRImXMJ6wb8=3D; b=tjfnInjf4kPf4YWyQYt0zgteT2SbPhLFEAUgdJ3Ntu1sPCzmPyvnJytNxApsGlVjl82vGCDn S1BfsAfgk+KGw2xiF7dKcZ067CyLo23rdTkhGFcVAu8+ZZqLsXm7geWk; Authentication-Results: rtp-dkim-2.cisco.com; header.From=sethomso@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 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 Yes, according to Russ Housley's email sent to the NEA list on Thurs Oct 26 (forwarded below). I believe it will take a little while to wend its way through the process which would explain why the official web pages/lists have not been updated. Susan > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu]=20 > Sent: Tuesday, October 31, 2006 5:54 PM > To: Susan Thomson (sethomso) > Cc: nea@ietf.org > Subject: Re: [Nea] Draft agenda for NEA WG meeting at IETF67 >=20 > > Please note that, because NEA WG has just recently been chartered,=20 >=20 > _has_ nea been chartered? I don't see any mention of it on the ietf=20 > working group web pages, haven't seen any announcement sent to=20 > ietf-announce, and can't find any mention of it in the=20 > minutes that have=20 > been posted. >=20 > Keith >=20 -----Original Message----- From: Russ Housley [mailto:housley@vigilsec.com]=20 Sent: Thursday, October 26, 2006 3:50 PM To: nea@ietf.org Subject: [Nea] NEA WG Chartered by the IESG On today's IESG Telechat, the NEA WG Charter was approved. There=20 were two changes made to the proposed charter text that was posted=20 two weeks ago. First, the text that was discussed on this list about=20 the enterprise environment was inserted. I made a very minor edit=20 that I hope that improves the flow, without altering the meaning in=20 any way. Second, only the milestones related to the requirements=20 document are approved. The idea is to get going with the=20 architecture, requirements, and security analysis. These are all=20 included in one document. The other milestones will be approved by=20 me (not a re-charter action) once the IETF Last Call demonstrates=20 that the NEA WG is moving in an direction that the community can support. The approved charter is below. Russ =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D Chair(s): Steve Hanna Susan Thomson Security Area Director(s): Russ Housley Sam Hartman Security Area Advisor: Russ Housley Mailing List: nea@ietf.org Description of Working Group: Network Endpoint Assessment (NEA) architectures have been implemented in the industry 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. An endpoint that does not comply with posture policy may be vulnerable to a number of known threats that may exist on the network. The intent of NEA is to facilitate corrective actions to address these known vulnerabilities before a host is exposed to potential attack. 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. Posture refers to the hardware or software configuration of an endpoint as it pertains to an organization's security 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. 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. 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 Oct 31 21:51:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf6Cf-0006QP-Qr; Tue, 31 Oct 2006 21:51:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gf6CZ-0006Oo-Cp; Tue, 31 Oct 2006 21:51:39 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gf3am-0003xd-QR; Tue, 31 Oct 2006 19:04:28 -0500 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gf3NH-0007iT-Lt; Tue, 31 Oct 2006 18:50:31 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 8DD1E2AC6B; Tue, 31 Oct 2006 23:50:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gf3Mn-0006NC-Ah; Tue, 31 Oct 2006 18:50:01 -0500 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: ietf-announce@ietf.org From: IESG Secretary Message-Id: Date: Tue, 31 Oct 2006 18:50:01 -0500 X-Spam-Score: -2.8 (--) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Cc: nea@ietf.org Subject: [Nea] WG Action: Network Endpoint Assessment (nea) X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org 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 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. An endpoint that does not comply with posture policy may be vulnerable to a number of known threats that may exist on the network. The intent of NEA is to facilitate corrective actions to address these known vulnerabilities before a host is exposed to potential attack. 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. Posture refers to the hardware or software configuration of an endpoint as it pertains to an organization's security 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. 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. 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