From nea-bounces@ietf.org Wed Jul 11 09:19:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8c5y-0008DH-C2; Wed, 11 Jul 2007 09:19:06 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1I8c5x-0008D5-7X for nea-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 09:19:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8c5w-0008Cx-TA for nea@ietf.org; Wed, 11 Jul 2007 09:19:04 -0400 Received: from smtpa.juniper.net ([207.17.137.120]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8c5w-0008UV-Ks for nea@ietf.org; Wed, 11 Jul 2007 09:19:04 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpa.juniper.net with ESMTP; 11 Jul 2007 06:18:48 -0700 X-IronPort-AV: i="4.16,526,1175497200"; d="scan'208"; a="34873851:sNHT40787204" X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Jul 2007 09:18:56 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft agenda for NEA meeting at IETF 69 Thread-Index: AcfDvgkISYzXHrfqQOq9Lh3Iw9OU0g== From: "Stephen Hanna" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Nea] Draft agenda for NEA meeting at IETF 69 X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Here's a draft agenda for the NEA meeting at IETF 69. Please let me know if you have any comments, change requests, or whatever. Note that the date, time, and place for the NEA meeting are subject to change, as are all aspects of the IETF agenda. However, I will do my best to avoid changing the date or time at this late date. Thanks, Steve ----------- Agenda for IETF 69 NEA WG Meeting =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 Date: Monday, July 23, 2007 Time: 1300-1500 CDT (GMT-0500) Place: State Ballroom, Palmer House Hilton, Chicago, IL, USA WG Charter: http://www.ietf.org/html.charters/nea-charter.html WG Tools: http://tools.ietf.org/wg/nea WG email: nea@ietf.org WG Chairs: Steve Hanna , Susan Thomson Agenda Version: 1 1300 Administrivia Blue Sheets Jabber & Minutes Scribes Agenda Bashing 1305 WG Status 1310 Discuss NEA Requirements Draft & Comments Received =20 http://www.ietf.org/internet-drafts/draft-ietf-nea-requirements-03.txt 1455 Review of Next Steps 1500 Adjourn _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Jul 11 11:15:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8duD-0005LG-WC; Wed, 11 Jul 2007 11:15:06 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1I8duA-0005K5-Sa for nea-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 11:15:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8duA-0005Gp-7O; Wed, 11 Jul 2007 11:15:02 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8du9-0002oX-T9; Wed, 11 Jul 2007 11:15:02 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id C3F9226EAB; Wed, 11 Jul 2007 15:15:01 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I8du9-0001PD-Ll; Wed, 11 Jul 2007 11:15:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 11 Jul 2007 11:15:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Cc: nea@ietf.org Subject: [Nea] I-D ACTION:draft-ietf-nea-requirements-03.txt X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Endpoint Assessment Working Group of the IETF. Title : Network Endpoint Assessment (NEA): Overview and Requirements Author(s) : P. Sangster, et al. Filename : draft-ietf-nea-requirements-03.txt Pages : 51 Date : 2007-7-11 This document defines the problem statement, scope and interface (protocol) requirements between the components of the NEA (Network Endpoint Assessment) reference model. NEA provides owners of networks (e.g. an enterprise offering remote access) a mechanism to evaluate the posture of a system. This may take place during the request for network access and/or subsequently at any time while connected to the network. The learned posture information can then be applied to a variety of compliance oriented decisions. The posture information is frequently useful for detecting systems that are lacking (or have out of date) security protective mechanisms (e.g. anti-virus, firewall). In order to provide context for the requirements, a reference model and terminology are introduced. This model is provided for informational purposes but is based on the models used by NAC [CNAC], NAP[NAP] and TNC[TNC]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nea-requirements-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-nea-requirements-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-nea-requirements-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-11105142.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nea-requirements-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nea-requirements-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-11105142.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea --NextPart-- From nea-bounces@ietf.org Wed Jul 11 12:05:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8egW-0005kQ-SK; Wed, 11 Jul 2007 12:05:00 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1I8egV-0005jy-GV for nea-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 12:04:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8egV-0005jq-6N for nea@ietf.org; Wed, 11 Jul 2007 12:04:59 -0400 Received: from mga03.intel.com ([143.182.124.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8egR-0004Ur-RY for nea@ietf.org; Wed, 11 Jul 2007 12:04:59 -0400 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 11 Jul 2007 09:04:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.16,527,1175497200"; d="scan'208";a="249140890" Received: from orsmsx335.jf.intel.com ([10.22.226.40]) by azsmga001.ch.intel.com with ESMTP; 11 Jul 2007 09:04:54 -0700 Received: from orsmsx411.amr.corp.intel.com ([10.22.226.47]) by orsmsx335.jf.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 09:04:50 -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] Draft agenda for NEA meeting at IETF 69 Date: Wed, 11 Jul 2007 09:04:50 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Draft agenda for NEA meeting at IETF 69 thread-index: AcfDvgkISYzXHrfqQOq9Lh3Iw9OU0gAFyBAg From: "Khosravi, Hormuzd M" To: "Stephen Hanna" , X-OriginalArrivalTime: 11 Jul 2007 16:04:50.0729 (UTC) FILETIME=[36267990:01C7C3D5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 Any re-charter discussions planned in this IETF? Thanks Hormuzd -----Original Message----- From: Stephen Hanna [mailto:shanna@juniper.net]=20 Sent: Wednesday, July 11, 2007 6:19 AM To: nea@ietf.org Subject: [Nea] Draft agenda for NEA meeting at IETF 69 Here's a draft agenda for the NEA meeting at IETF 69. Please let me know if you have any comments, change requests, or whatever. Note that the date, time, and place for the NEA meeting are subject to change, as are all aspects of the IETF agenda. However, I will do my best to avoid changing the date or time at this late date. Thanks, Steve ----------- Agenda for IETF 69 NEA WG Meeting =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 Date: Monday, July 23, 2007 Time: 1300-1500 CDT (GMT-0500) Place: State Ballroom, Palmer House Hilton, Chicago, IL, USA WG Charter: http://www.ietf.org/html.charters/nea-charter.html WG Tools: http://tools.ietf.org/wg/nea WG email: nea@ietf.org WG Chairs: Steve Hanna , Susan Thomson Agenda Version: 1 1300 Administrivia Blue Sheets Jabber & Minutes Scribes Agenda Bashing 1305 WG Status 1310 Discuss NEA Requirements Draft & Comments Received =20 http://www.ietf.org/internet-drafts/draft-ietf-nea-requirements-03.txt 1455 Review of Next Steps 1500 Adjourn _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Jul 11 20:15:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8mL3-0003l7-95; Wed, 11 Jul 2007 20:15:21 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1I8mL2-0003l2-Ry for nea-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 20:15:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8mL2-0003ku-H8 for nea@ietf.org; Wed, 11 Jul 2007 20:15:20 -0400 Received: from smtpb.juniper.net ([207.17.137.119]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8mL2-0005H8-7p for nea@ietf.org; Wed, 11 Jul 2007 20:15:20 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpb.juniper.net with ESMTP; 11 Jul 2007 17:15:19 -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] Draft agenda for NEA meeting at IETF 69 Date: Wed, 11 Jul 2007 20:15:28 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Draft agenda for NEA meeting at IETF 69 Thread-Index: AcfDvgkISYzXHrfqQOq9Lh3Iw9OU0gAFyBAgAAyHOGA= References: From: "Stephen Hanna" To: "Khosravi, Hormuzd M" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 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 Nope. We need to finish our current milestones first (up through sending the NEA requirements document to the IESG). Thanks, Steve -----Original Message----- From: Khosravi, Hormuzd M [mailto:hormuzd.m.khosravi@intel.com]=20 Sent: Wednesday, July 11, 2007 12:05 PM To: Stephen Hanna; nea@ietf.org Subject: RE: [Nea] Draft agenda for NEA meeting at IETF 69 Any re-charter discussions planned in this IETF? Thanks Hormuzd -----Original Message----- From: Stephen Hanna [mailto:shanna@juniper.net]=20 Sent: Wednesday, July 11, 2007 6:19 AM To: nea@ietf.org Subject: [Nea] Draft agenda for NEA meeting at IETF 69 Here's a draft agenda for the NEA meeting at IETF 69. Please let me know if you have any comments, change requests, or whatever. Note that the date, time, and place for the NEA meeting are subject to change, as are all aspects of the IETF agenda. However, I will do my best to avoid changing the date or time at this late date. Thanks, Steve ----------- Agenda for IETF 69 NEA WG Meeting =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 Date: Monday, July 23, 2007 Time: 1300-1500 CDT (GMT-0500) Place: State Ballroom, Palmer House Hilton, Chicago, IL, USA WG Charter: http://www.ietf.org/html.charters/nea-charter.html WG Tools: http://tools.ietf.org/wg/nea WG email: nea@ietf.org WG Chairs: Steve Hanna , Susan Thomson Agenda Version: 1 1300 Administrivia Blue Sheets Jabber & Minutes Scribes Agenda Bashing 1305 WG Status 1310 Discuss NEA Requirements Draft & Comments Received =20 http://www.ietf.org/internet-drafts/draft-ietf-nea-requirements-03.txt 1455 Review of Next Steps 1500 Adjourn _______________________________________________ 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 Jul 13 10:12:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Lsy-0002cF-BO; Fri, 13 Jul 2007 10:12:44 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1I9Lsx-0002c9-FW for nea-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 10:12:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Lsx-0002c1-3t for nea@ietf.org; Fri, 13 Jul 2007 10:12:43 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9Lst-0000G3-Ps for nea@ietf.org; Fri, 13 Jul 2007 10:12:43 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 13 Jul 2007 10:12:32 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAIcll0ZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.16,537,1175486400"; d="scan'208"; a="125978989:sNHT5327269838" 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/8.12.11) with ESMTP id l6DECWmw016803; Fri, 13 Jul 2007 10:12:32 -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 l6DECV6a014482; Fri, 13 Jul 2007 14:12:31 GMT 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); Fri, 13 Jul 2007 10:12:30 -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: Fri, 13 Jul 2007 10:12:26 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NEA WG Last Call for comments on draft-ietf-nea-requirements-03.txt Thread-Index: AcfFV9ciT62KTbdtRUWiyMdbQAQskA== From: "Susan Thomson \(sethomso\)" To: X-OriginalArrivalTime: 13 Jul 2007 14:12:30.0325 (UTC) FILETIME=[D961F250:01C7C557] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=806; t=1184335952; x=1185199952; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sethomso@cisco.com; z=From:=20=22Susan=20Thomson=20\(sethomso\)=22=20 |Subject:=20NEA=20WG=20Last=20Call=20for=20comments=20on=20draft-ietf-nea -requirements-03.txt |Sender:=20 |To:=20; bh=SFgO9/z88wXq19rbYCJOYhZkCBADomoSmlniTeezt7Y=; b=PWdKARkKquoGB+9g29MQlYCunueBixIpNRcG5ZNvnmCPXG3D7RAsaMWd/Hn0pzTTpC44ytYR brnlFgS4QFk8+mPVsfT8AAlqSGChCHsoO5f7RaMO3/85wx0rie/FkhRc; Authentication-Results: rtp-dkim-1; header.From=sethomso@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Tim Polk Subject: [Nea] NEA WG Last Call for comments on draft-ietf-nea-requirements-03.txt X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org As discussed as part of the milestone review at the last IETF meeting and on the mailing list, we are now issuing a WG Last Call for comments on the -03 version of the NEA requirements draft. Because of the upcoming IETF meeting and the associated workload, the last call period will last for at least 4 weeks starting from today, July 13 until August 10. The draft is at: http://www.ietf.org/internet-drafts/draft-ietf-nea-requirements-03.txt All NEA WG participants are requested to review this document and provide their comments within this period to the NEA WG mailing list. If there are many comments, please use multiple email messages structured in a way that helps facilitate discussion e.g. section by section, or substantive versus editorial comments. Thanks Steve & Susan. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Jul 23 01:07:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICq9C-00048K-SU; Mon, 23 Jul 2007 01:07:54 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1ICq9B-00048E-K1 for nea-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 01:07:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICq9B-000485-AT for nea@ietf.org; Mon, 23 Jul 2007 01:07:53 -0400 Received: from ccerelbas04.cce.hp.com ([161.114.21.107]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ICq99-0004EQ-Vq for nea@ietf.org; Mon, 23 Jul 2007 01:07:53 -0400 Received: from G3W0060.americas.hpqcorp.net (g3w0060.americas.hpqcorp.net [16.232.1.19]) by ccerelbas04.cce.hp.com (Postfix) with ESMTP id AE858345E1 for ; Mon, 23 Jul 2007 00:07:51 -0500 (CDT) Received: from G3W0072.americas.hpqcorp.net ([16.232.1.11]) by G3W0060.americas.hpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 05:07:28 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Jul 2007 05:07:05 -0000 Message-ID: <2F2D38A4B8346F48A683750A46BAB21101D2D600@G3W0072.americas.hpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: REQ (-03) my comments Thread-Index: AcfM5WxB47JxwshYRLad+1GXPWH3bQAAdTkA From: "Sanchez, Mauricio (ProCurve)" To: X-OriginalArrivalTime: 23 Jul 2007 05:07:28.0618 (UTC) FILETIME=[5DC6F4A0:01C7CCE7] X-Spam-Score: -4.0 (----) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Subject: [Nea] REQ (-03) my comments X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 comments of draft -03 of NEA requirements document: Meta-comments * NIT: From the last version I reviewed (-01), I see most of the document has moved away from using capitalization of nomenclature. Section 5 is a notable exception. However, there are still instances of capitalization and even then the same keyword isn't capitalized uniformly throughout the document. For example, reference model is capitalized in some sections, but not others. I still personally dislike capitalization of nomenclature. * Why are remediation attributes defined as a class of attributes, yet there is no intention of the WG to define any standard set? The fact that remediation attributes are described in various places of the document somewhat sets the stage as if we are going to define some standard set. Abstract * NIT: There's too many things in parenthesis. IMO, should be used more sparingly. Something clear could be: "This document defines the problem statement, scope and protocol interface requirements between the components of the NEA (Network Endpoint Assessment) reference model. NEA provides owners of networks, such as an enterprise offering remote access, a mechanism to evaluate the posture of a system. This may take place during the request for network access and/or subsequently at any time while connected to the network. The learned posture information can then be applied to a variety of compliance oriented decisions. The posture information is useful for detecting systems that are lacking or have out of date security protective mechanisms, such as Anti-Virus and host firewall applications." Section 1 - Introduction * First sentence "...can leverage existing standards-based technologies" Would be nice if document had references to some of the standards-based technologies the NEA team had in mind when saying the statement. * Second paragraph, first sentence: "...indicate appropriate remediation actions to be taken" Since the WG is not defining any remediation attributes, how can this claim be made? =20 * Second paragraph "Such a mechanism could offer a useful tool..." What mechanism is this sentence referring to? The previous sentence is about the fact that the endpoint may still be vulnerable to threats that exist on the network. * Third paragraph "NEA typically involves the use of special client software..." I don't see any reason why this claim needs to be made. This is a requirements document, not one about NEA implementation - there are none in existence.=20 * NIT: Fourth paragraph, first sentence ("In many cases, the admission decision...") The first paragraph talks about "access decisions" while this paragraph talks about "admission decisions". Is there a difference between both. I don't believe so. Document needs to be scrubbed to use a common set of terms. Section 3.1 scope * NIT: Second paragraph, bulleted-list: First and second bullet should have periods instead of commas. Section 3.2 scope=20 * Why make assertion of "special software". I don't see it as special. It's just additional software functionality required in the endpoint. * NIT: second paragraph, first sentence: Word "Network" should not be capitalized. Section 4 (Problem statement) * NIT: Paragraph 3: "out of scope" is usually not hyphenated. Consider removing hyphens.=20 * Paragraph 3 ("The decision of how to handle...") I question why the document suggests any method (e.g. authentication) to deal with non-compliant or non-participating endpoints. We should point out the problem, but not try to solve it here in this section.=20 * Paragraph 6 ("NEA technology...") Why not add a reference to 802.1X? Section 5 (Reference model) * Why in the discussion of the reference model is there already discussion about protocol design ("PA is likely a thin message wrapper around a set of attributes..."). We've yet to evaluate any protocol, why bias the reader now? * NIT: second paragraph, second sentence ("PB is primarily is"): Spurious "is" in sentence. Need to delete.=20 * NIT: second paragraph, third sentence ("The vertical lines in the model represent APIs...") I always like to spell out completely the first usage of any acronym. The acronym "API" is used here for the first time and isn't spelled out completely. =20 Section 5.1 * NIT: I spoke too early about the reduction in use of capitalization. Section 5 has it everywhere. Consider reducing usage. Section 5.1.1 (NEA Client) * "An NEA Client is not responsible for reporting on posture of entities that might exist on the endpoint or over the network that are outside the scope/visibility of the NEA Client." I don't understand this statement. What is it trying to say? Section 5.1.1.1 (Posture Collector) * Last paragraph ("The above list describe the model's view of the possible responsibilities...") - Why was this disclaimer added. I don't see it as being useful. Moreover, the subsequent sections on other NEA components don't include the same disclaimer. Consider removing.=20 Section 5.2.1 (Posture Attribute Protocol) * Second sentence ("The PA protocol is a message oriented lightweight wrapper..."): Again, I don't see why we need to start specifying the protocol in a requirements document. Consider removing all such discussion. Seciton 5.2.3 (Posture Transport Protocol) * Last sentence ("The PT protocol provides reliable message delivery, mutual authentication and cryptographic protection..." "...as specified by local policy.") How is this statement to be interpreted, in particular the "...as specified by local policy." Would we always want mutual authentication and reliable message delivery? =20 Section 6.1 * NIT: Would help readability if Figure 2 was all on the same page. When printing out the document, the figure is across two pages.=20 * NIT: Second sentence ("Endpoints that have been...") Extremely wordy sentence. Took a couple passes to understand. Consider: "Endpoints that have been recently assessed and for which the NEA Client or Server has maintained state or proof that the endpoint is compliant need not have their posture evaluated again. Therefore, this use case does not apply." Section 6.1.2.3 (Impact on requirements * NIT: Inconsistent usage of periods for bulleted items. Consider removal of period of bullet with one to be uniform across all bulleted items in section. Section 7 (Requirements) * Second paragraph: Why is there the huge security loophole to allow implementers to arbitrarily choose whether to implement security measures we specify to be part of the protocol. Seems counter-intuitive to the desire to have secure protocols by default. Section 7.1 (Common Protocol Requirements) * C-2: What is "normal" network access? What if an endpoint is only given "limited" network access, which presumably is not "normal"? Does this requirement not apply? * C-5: Add references to EAP, PANA, IKE standards in references section. * C-7, C-8, C-9: All these requirements refer to a qualitative "large" for scalability needs. Just how large is "large"? Tens? Hundreds? Thousands? Millions large? * C-10: For which assessments modes will we require that proposed protocols have the ability to exchange just a little information? Section 7.2=20 * PA-8: Isn't there already an IETF spec'ed encoding standard that most protocols refer to? If so, maybe add reference here explicitly. Section 7.3 * PB-4: What's the rationale behind having put this as a MAY instead of SHOULD or even MUST? Section 7.4 * First paragraph: I believe this is the first reference to RADIUS. Consider adding reference to RADIUS RFC in reference section and using here. * PT-1; NIT: Missing period. * PT-4: Why no authentication as a requirement to integrity and confidentiality. Section 8.1.1 * NIT: Add reference to Trusted Computing Group to reference section and add here. =20 Section 9.1 (Implementer Considerations) * Second paragraph ("The opt-in mechanism...") Why would the opt-in mechanism not also be available on a per-network access basis? =20 Cheers, MS --------------------------------------------=20 Mauricio Sanchez, CISSP=20 Chief Security Architect=20 ProCurve Networking by HP=20 Hewlett Packard=20 8000 Foothills Boulevard, ms 5541 Roseville CA, 95747-5557=20 916.785.1910 Tel=20 916.785.1815 Fax=20 mauricio.sanchez@hp.com=20 -------------------------------------------- _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Jul 23 11:50:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID0Ao-0000Bm-Hy; Mon, 23 Jul 2007 11:50:14 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1ID0Am-0000Bh-OQ for nea-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 11:50:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID0Am-0000BZ-7p for nea@ietf.org; Mon, 23 Jul 2007 11:50:12 -0400 Received: from www.deployingradius.com ([216.240.42.17] helo=deployingradius.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID0Al-0000Kc-De for nea@ietf.org; Mon, 23 Jul 2007 11:50:12 -0400 Received: from [130.129.17.247] (dhcp-11f7.ietf69.org [130.129.17.247]) by deployingradius.com (Postfix) with ESMTP id B874CA7161 for ; Mon, 23 Jul 2007 08:50:07 -0700 (PDT) Message-ID: <46A4CE2D.7050101@deployingradius.com> Date: Mon, 23 Jul 2007 11:50:05 -0400 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: nea@ietf.org X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Subject: [Nea] REQ -03 comments X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Overall, much more comprehensible than earlier versions. General comments: * Section 1 is still complex. Sentences are long, and seem to be marketing-speak: Today, most network providers can leverage existing standards- based technologies to restrict access to their network based upon criteria such as the requesting system's user or host-based identity, source IP address or physical access point. Simplicity would be good. * The goal seems to be: 1) inventory of software on the device 2) informing the device what software *should* be running 3) informing the device where to obtain the software 4) informing the switch how to treat / block the devices traffic * I'm not sure what some sentences mean: Posture Attributes - Attributes describing a quality or characteristic of a component. The following text clarifies it a little, but it still sounds complex. Versus: Posture Attributes - Attributes describing the status of a component. This may include information such as manufacturer, product name, version number, last update time, install time, last modification time, etc. * Section 5 seems to have "posture" as every other word. Most instances can probably be deleted. Section 6.1 appears to be doing this already, btw. e.g. The NEA Client is resident on an endpoint device and comprises of the following components for assessing posture: o Collector(s) o Broker Client o Transport Client ... The NEA Server will typically comprise of the following logical components for assessing posture: o Validator(s) o Broker Server o Transport Server * Terminology is still inconsistent and confusing: PA is a protocol that carries attribute messages between a Posture Collector and its associated Posture Validator. What's an "attribute message"? The terminology section talks about Messages and Request/Posture/* Attributes. * Does the NEA server cache anything? The enterprise administrators make available the patches and change the network policy to require it to be installed by 5PM. This policy change causes the NEA Server to request a re- assessment to determine what endpoints are impacted and lacking the patches. The marketing employee's laptop is re-assessed and determined to need the patches. If the NEA server caches the results of posture assessment, it *knows* that the device is not compliant. To first order, the server doesn't have to cache anything other than "compliant at time X". When the policy changes at time "X + t", the device is trivially determined to be noncompliant. The NEA server may not know *what* is noncompliant, but a full reassessment can address that. The NEA server can also cache the results of the last posture assessment, and tell the device "download patch X from here..." i.e. an unsolicited posture requirement update, or remediation instruction. I will have more comments on Section 6 and following in a later message. Alan DeKok. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Jul 23 13:46:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID1zR-0004yD-TF; Mon, 23 Jul 2007 13:46:37 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1ID1zQ-0004y8-B5 for nea-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 13:46:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID1zQ-0004y0-1D for nea@ietf.org; Mon, 23 Jul 2007 13:46:36 -0400 Received: from dsp2xmail.bestbuy.com ([198.22.123.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ID1zP-0005HC-5S for nea@ietf.org; Mon, 23 Jul 2007 13:46:36 -0400 Received: from unknown (HELO rs03vms.na.bestbuy.com) ([167.209.1.221]) by dsp2xmail.bestbuy.com with SMTP; 23 Jul 2007 12:41:40 -0500 Received: from rs41mail.bestbuy.com (HELO rs41mail.na.bestbuy.com) ([167.209.1.173]) by dsp2xmail.bestbuy.com with ESMTP; 23 Jul 2007 12:41:40 -0500 Content-Type: multipart/mixed; boundary="L6Y+T.4DV7A3d6y.1H4Ok/.9nphmNS" Received: from CPREXN062-EVS.ca.bestbuy.com ([168.94.171.105]) by CPREXN040.ca.bestbuy.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 10:46:32 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 Subject: RE: [Nea] REQ -03 comments Date: Mon, 23 Jul 2007 10:46:32 -0700 Message-ID: <111AE4F08352594D93F7C78647D2BA4CD6C462@CPREXN062-EVS.ca.bestbuy.com> In-Reply-To: <46A4CE2D.7050101@deployingradius.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] REQ -03 comments Thread-Index: AcfNQS8cgq7DNIkqRwemCNf8nNST0QADSS7g From: "Royer, David \(Best Buy Canada\)" To: "Alan DeKok" , X-OriginalArrivalTime: 23 Jul 2007 17:46:32.0897 (UTC) FILETIME=[68486B10:01C7CD51] X-Vontu: Pass X-Spam-Score: -4.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: , Errors-To: nea-bounces@ietf.org --L6Y+T.4DV7A3d6y.1H4Ok/.9nphmNS MIME-Version: 1.0 Content-class: urn:content-classes:message Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm quite new to this distribution list, but I have extensive experience with NEA solutions, eventough the technology is quite young at this point. To give you a quick background, I have evaluated multiple solutions with the goal of implementing to a 10 000+ employee environment, and also participated in the development of a product. I went through the specification and I really like it. I believe too much simplicity would not make sense on this case, as the NEA market is not a simple one, and there is no simple ways to develop and install a NEA solution. I feel more like this RFC could be separated into multiple smaller ones to make things easier. Although, as Alan mentioned, I also think more definitions / precision should be added to the specification. I'm more interested into the Attribute Message and the protocol itself: =20 - Should the need of encryption be specified? =20 - Same with authentication: should client <-> server authentication need should be described in the RFC as well? >From a security perspective, protecting the Posture Messages is usually a best practice, as it might contain enough information for a hacker to take advantage of it. As for authentication, some products might want to work in a close environment, where the clients are easily identifiable and pre-configured. Some might use PKCS certs to authentication, some other might use private/public key pairs. But anyhow, I was wondering if such definitions should be included in the draft. -David -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com]=20 Sent: Monday, July 23, 2007 8:50 AM To: nea@ietf.org Subject: [Nea] REQ -03 comments Overall, much more comprehensible than earlier versions. General comments: * Section 1 is still complex. Sentences are long, and seem to be marketing-speak: Today, most network providers can leverage existing standards- based technologies to restrict access to their network based upon criteria such as the requesting system's user or host-based identity, source IP address or physical access point. Simplicity would be good. * The goal seems to be: 1) inventory of software on the device 2) informing the device what software *should* be running 3) informing the device where to obtain the software 4) informing the switch how to treat / block the devices traffic * I'm not sure what some sentences mean: Posture Attributes - Attributes describing a quality or characteristic of a component. The following text clarifies it a little, but it still sounds complex. Versus: Posture Attributes - Attributes describing the status of a component. This may include information such as manufacturer, product name, version number, last update time, install time, last modification time, etc. * Section 5 seems to have "posture" as every other word. Most instances can probably be deleted. Section 6.1 appears to be doing this already, btw. e.g. The NEA Client is resident on an endpoint device and comprises of the following components for assessing posture: o Collector(s) o Broker Client o Transport Client ... The NEA Server will typically comprise of the following logical components for assessing posture: o Validator(s) o Broker Server o Transport Server * Terminology is still inconsistent and confusing: PA is a protocol that carries attribute messages between a Posture Collector and its associated Posture Validator. What's an "attribute message"? The terminology section talks about Messages and Request/Posture/* Attributes. * Does the NEA server cache anything? The enterprise administrators make available the patches and change the network policy to require it to be installed by 5PM. This policy change causes the NEA Server to request a re- assessment to determine what endpoints are impacted and lacking the patches. The marketing employee's laptop is re-assessed and determined to need the patches. If the NEA server caches the results of posture assessment, it *knows* that the device is not compliant. To first order, the server doesn't have to cache anything other than "compliant at time X". When the policy changes at time "X + t", the device is trivially determined to be noncompliant. The NEA server may not know *what* is noncompliant, but a full reassessment can address that. The NEA server can also cache the results of the last posture assessment, and tell the device "download patch X from here..." i.e. an unsolicited posture requirement update, or remediation instruction. I will have more comments on Section 6 and following in a later message. Alan DeKok. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea --L6Y+T.4DV7A3d6y.1H4Ok/.9nphmNS Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline The information in this e-mail message including any attachments is intende= d only for the named recipients above and may contain confidential or privi= leged information. If you have received this message in error, or are not t= he named recipient(s), please immediately notify the sender by replying to = the message and deleting all copies of it from your computer. Ce courriel de m=C3=AAme que toute pi=C3=A8ce jointe s'adresse seulement au= (x) destinataire(s) d=C3=A9sign=C3=A9(s) et peut contenir des renseignement= s confidentiels ou privil=C3=A9gi=C3=A9s. Si vous avez re=C3=A7u ce message= par erreur ou que vous n'=C3=AAtes pas un destinataire d=C3=A9sign=C3=A9, = veuillez avertir imm=C3=A9diatement l'exp=C3=A9diteur en r=C3=A9pondant au = message et effacez-en toutes les copies dans votre ordinateur. --L6Y+T.4DV7A3d6y.1H4Ok/.9nphmNS 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 --L6Y+T.4DV7A3d6y.1H4Ok/.9nphmNS-- From nea-bounces@ietf.org Mon Jul 23 13:49:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID22R-0007r7-Qq; Mon, 23 Jul 2007 13:49:43 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1ID22R-0007r2-5G for nea-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 13:49:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID22Q-0007qu-RH for nea@ietf.org; Mon, 23 Jul 2007 13:49:42 -0400 Received: from smtpa.juniper.net ([207.17.137.120]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID22Q-0004FT-Hm for nea@ietf.org; Mon, 23 Jul 2007 13:49:42 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpa.juniper.net with ESMTP; 23 Jul 2007 10:49:38 -0700 X-IronPort-AV: i="4.16,571,1175497200"; d="scan'208"; a="42213163:sNHT10446009744" X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Jul 2007 13:49:43 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Posted slides for today's NEA meeting Thread-Index: AcfNUdoTVoLtpqdhRYaRdLSyYx5ILQ== From: "Stephen Hanna" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Nea] Posted slides for today's NEA meeting X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 posted the slides for today's NEA WG meeting on the IETF Meeting Materials web site at https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=3D6= 9 These may be useful to anyone who's trying to follow along using the streaming audio or Jabber. Thanks, Steve _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Jul 23 15:14:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID3Mi-0000V7-9k; Mon, 23 Jul 2007 15:14:44 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1ID3Mg-0000V0-NY for nea-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 15:14:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID3Mg-0000Us-Cf for nea@ietf.org; Mon, 23 Jul 2007 15:14:42 -0400 Received: from smtp3.su.se ([130.237.93.228]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID3Mf-00073E-VB for nea@ietf.org; Mon, 23 Jul 2007 15:14:42 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id A9E5A3BE70 for ; Mon, 23 Jul 2007 21:14:40 +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 10815-02-9 for ; Mon, 23 Jul 2007 21:14:40 +0200 (CEST) Received: from [130.129.19.150] (dhcp-1396.ietf69.org [130.129.19.150]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 10FAF3BE5A for ; Mon, 23 Jul 2007 21:14:39 +0200 (CEST) Message-ID: <46A4FE22.8020808@it.su.se> Date: Mon, 23 Jul 2007 21:14:42 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: nea@ietf.org X-Enigmail-Version: 0.94.2.0 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.885 tagged_above=-99 required=7 tests=[AWL=0.427, BAYES_00=-2.312] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [Nea] 03 comments - IDS as Posture Collecotr X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org >From section 5.1.1.1: 5.1.1.1 Posture Collector The Posture Collector is the component that is responsible for responding to requests for posture information in Request Attributes from the NEA Server. The Posture Collector is also responsible for handling assessment decisions in Result Attributes and remediation instructions in Remediation Attributes. A single NEA Client can have several Posture Collectors capable of collecting standard and/or vendor-specific Posture Attributes for particular endpoint components. Typical examples include Posture Collectors that provide information about Operating System (OS) patch levels, anti-virus software, and security mechanisms on the endpoint such as host firewall or an Intrusion Detection System (IDS). Typically IDSen are _not_ part of the endpoint but rather systems which are part of the overall network infrastructure, eg active scanners such as "nessus" or passive scanners such as "snort". I am convinced that information from IDSen will be an important part of the data collected and processed by a NEA deployment. I think the text in this section needs clarification wrt Posture Collectors which report on endpoints which are different from the one the NEA Client (which the PC is part of) is running on. Section 5.1.1 has text which uses the NAT-box as an example of a case when a network entity is _not_ responsible for reporting on the entities behind it. I think the section needs text exemplifying the reverse - eg an IDS reporting on the posture of endpoints within its scope. Cheers Leif _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Jul 23 15:49:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID3uk-0002kV-GF; Mon, 23 Jul 2007 15:49:54 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1ID3uf-0002iB-Mv for nea-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 15:49:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID3uf-0002hz-Ce for nea@ietf.org; Mon, 23 Jul 2007 15:49:49 -0400 Received: from smtpa.juniper.net ([207.17.137.120]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID3uf-0000Bt-3c for nea@ietf.org; Mon, 23 Jul 2007 15:49:49 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpa.juniper.net with ESMTP; 23 Jul 2007 12:49:48 -0700 X-IronPort-AV: i="4.16,572,1175497200"; d="scan'208"; a="42269348:sNHT27941568" X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Jul 2007 15:49:53 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RSVP for NEA dinner tonight Thread-Index: AcfNYqNSYa4QWhmjS0mObHI8U1w8TQ== From: "Stephen Hanna" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [Nea] RSVP for NEA dinner tonight X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org If you want to have dinner with NEA folks tonight, please RSVP to me. We'll meet at the IETF registration desk in the Palmer Hilton at 8 PM and go to Giordano's for Chicago-style deep dish pizza. Thanks, Steve _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Jul 23 16:29:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID4XJ-0004Bz-TD; Mon, 23 Jul 2007 16:29:45 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1ID4XI-0004Bu-NS for nea-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 16:29:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID4XI-0004Bm-DX for nea@ietf.org; Mon, 23 Jul 2007 16:29:44 -0400 Received: from extu-mxob-1.symantec.com ([216.10.194.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ID4XG-0002rl-US for nea@ietf.org; Mon, 23 Jul 2007 16:29:44 -0400 Received: from tus1opsmtapin01.ges.symantec.com ([192.168.214.43]) by extu-mxob-1.symantec.com with esmtp (Exim 4.66) (envelope-from ) id 1ID4XG-0001WL-11; Mon, 23 Jul 2007 13:29:42 -0700 Received: from reserved-155-64-230-20.ges.symantec.com ([155.64.230.20] helo=TUS1XCHECNPIN03.enterprise.veritas.com) by tus1opsmtapin01.ges.symantec.com with esmtp (Exim 4.67) (envelope-from ) id 1ID4XF-0006SW-HQ; Mon, 23 Jul 2007 13:29:41 -0700 Received: from TUS1XCHEVSPIN05.enterprise.veritas.com ([155.64.231.28]) by TUS1XCHECNPIN03.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 13:29:39 -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] 03 comments - IDS as Posture Collecotr Date: Mon, 23 Jul 2007 13:29:38 -0700 Message-ID: In-Reply-To: <46A4FE22.8020808@it.su.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] 03 comments - IDS as Posture Collecotr thread-index: AcfNXb88CpdXMt6eSbiaeBiH5Pk7KwACOqjw References: <46A4FE22.8020808@it.su.se> From: "Paul Sangster" To: "Leif Johansson" , X-OriginalArrivalTime: 23 Jul 2007 20:29:39.0195 (UTC) FILETIME=[315EFCB0:01C7CD68] X-Brightmail-Verdict: VlJEQwAAAAIAAAABAAAAAAAAAAEAAAAAAAAAAmluYm94AG5lYUBpZXRmLm9yZwBsZWlmakBpdC5zdS5zZQA= X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -4.0 (----) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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 Comments below...=20 > -----Original Message----- > From: Leif Johansson [mailto:leifj@it.su.se]=20 > Sent: Monday, July 23, 2007 12:15 PM > To: nea@ietf.org > Subject: [Nea] 03 comments - IDS as Posture Collecotr Curious about the topic, I presume your referring to IDS being used as a NEA Client for other systems? In Prague we discussed whether the NEA Client could exist on non-endpoints such as an IDS reporting posture for other endpoints. The consensus (as we reported today) was this was likely out of scope for NEA's current charter and that using the planned protocols might not make sense when talking to an IDS. I presume this is the thread your highlighting (since the Posture Collector co-exists with the NEA Client components). >=20 >=20 > >From section 5.1.1.1: >=20 > 5.1.1.1 Posture Collector > =20 > The Posture Collector is the component that is responsible for > responding to requests for posture information in Request > Attributes from the NEA Server. The Posture Collector is also > responsible for handling assessment decisions in Result > Attributes and remediation instructions in Remediation > Attributes. A single NEA Client can have several Posture > Collectors capable of collecting standard and/or vendor-specific > Posture Attributes for particular endpoint components. Typical > examples include Posture Collectors that provide information > about Operating System (OS) patch levels, anti-virus software, > and security mechanisms on the endpoint such as host firewall or > an Intrusion Detection System (IDS). >=20 > Typically IDSen are _not_ part of the endpoint but rather=20 > systems which are part of the overall network infrastructure,=20 > eg active scanners such as "nessus" or passive scanners such=20 > as "snort". >=20 > I am convinced that information from IDSen will be an=20 > important part of the data collected and processed by a NEA=20 > deployment. I agree that the IDS will play an important role for detecting potential mis-behaviour on the network and potentially interacting with the NEA Server or enforcement devices on the network (or endpoint). However the posture the IDS can learn by observing traffic is likely a subset of the posture a local Posture Collector can learn (e.g. version of RPMs installed). Its also not clear the PA, PB and PT are the right protocols for the NEA Server to detect the existance, redirect NEA Client requests and communicate with an IDS. We probably need a protocol more specific to this environment and this protocol could be something for later specification by the WG once we re-charter after successful definition of PA and PB. >=20 > I think the text in this section needs clarification wrt=20 > Posture Collectors which report on endpoints which are=20 > different from the one the NEA Client (which the PC is part=20 > of) is running on. Section 5.1.1 has text which uses the=20 > NAT-box as an example of a case when a network entity is=20 > _not_ responsible for reporting on the entities behind it. I=20 > think the section needs text exemplifying the reverse - eg an=20 > IDS reporting on the posture of endpoints within its scope. The NAT box analogy worked because it was the endpoint of assessment where the IDS is not if I understand your comment. Also as you noted the NAT box only reports on its own internal posture, not other devices. The IDS box could report its own posture using NEA, but believe this isn't what your requesting. Did I miss your point? Paul >=20 > Cheers Leif >=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 Mon Jul 23 16:37:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID4f1-0003Uu-UB; Mon, 23 Jul 2007 16:37:43 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1ID4f0-0003RK-KH for nea-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 16:37:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID4f0-0003RC-6u for nea@ietf.org; Mon, 23 Jul 2007 16:37:42 -0400 Received: from cocalus.redlambda.com ([66.103.132.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ID4ew-00033o-OI for nea@ietf.org; Mon, 23 Jul 2007 16:37:42 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by cocalus.redlambda.com (Postfix) with ESMTP id C21221D0822E for ; Mon, 23 Jul 2007 16:42:01 -0400 (EDT) X-DSPAM-Result: Innocent X-DSPAM-Processed: Mon Jul 23 16:42:01 2007 X-DSPAM-Confidence: 0.9997 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 46a51299225301012214846 X-DSPAM-Factors: 27, X-Virus-Scanned: amavisd-new at X-Spam-Score: -3.33 X-Spam-Level: X-Spam-Status: No, score=-3.33 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, AWL=-0.183, BAYES_00=-2.599, DSPAM_HAM=-0.1, HTML_10_20=1.351, HTML_MESSAGE=0.001] Received: from cocalus.redlambda.com ([127.0.0.1]) by localhost (cocalus.redlambda.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzdd2kY4uKUN for ; Mon, 23 Jul 2007 16:42:00 -0400 (EDT) Received: from cocalus.redlambda.com (cocalus.redlambda.com [172.20.64.11]) by cocalus.redlambda.com (Postfix) with ESMTP id A72031D0822A for ; Mon, 23 Jul 2007 16:42:00 -0400 (EDT) Message-ID: <20637714.8571185223320555.JavaMail.root@cocalus.redlambda.com> Date: Mon, 23 Jul 2007 16:42:00 -0400 (EDT) From: Robert Bird To: nea@ietf.org Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr In-Reply-To: MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1 X-BeenThere: nea@ietf.org X-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="===============0579135134==" Errors-To: nea-bounces@ietf.org --===============0579135134== Content-Type: multipart/alternative; boundary="----=_Part_186_13643447.1185223320555" ------=_Part_186_13643447.1185223320555 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit My instinct is that if an IDS provides NEA client functionality, then it should not be considered part of the IDS itself. If an IDS is acting as a collector/validator, that functionality should also be considered separate from its functionality as an IDS. I believe we're risking running afoul of complications if we blur these lines. ----- Original Message ----- From: Paul Sangster To: Leif Johansson , nea@ietf.org Sent: Monday, July 23, 2007 4:29:38 PM GMT-0500 US/Eastern Subject: RE: [Nea] 03 comments - IDS as Posture Collecotr Comments below... > -----Original Message----- > From: Leif Johansson [mailto:leifj@it.su.se] > Sent: Monday, July 23, 2007 12:15 PM > To: nea@ietf.org > Subject: [Nea] 03 comments - IDS as Posture Collecotr Curious about the topic, I presume your referring to IDS being used as a NEA Client for other systems? In Prague we discussed whether the NEA Client could exist on non-endpoints such as an IDS reporting posture for other endpoints. The consensus (as we reported today) was this was likely out of scope for NEA's current charter and that using the planned protocols might not make sense when talking to an IDS. I presume this is the thread your highlighting (since the Posture Collector co-exists with the NEA Client components). > > > >From section 5.1.1.1: > > 5.1.1.1 Posture Collector > > The Posture Collector is the component that is responsible for > responding to requests for posture information in Request > Attributes from the NEA Server. The Posture Collector is also > responsible for handling assessment decisions in Result > Attributes and remediation instructions in Remediation > Attributes. A single NEA Client can have several Posture > Collectors capable of collecting standard and/or vendor-specific > Posture Attributes for particular endpoint components. Typical > examples include Posture Collectors that provide information > about Operating System (OS) patch levels, anti-virus software, > and security mechanisms on the endpoint such as host firewall or > an Intrusion Detection System (IDS). > > Typically IDSen are _not_ part of the endpoint but rather > systems which are part of the overall network infrastructure, > eg active scanners such as "nessus" or passive scanners such > as "snort". > > I am convinced that information from IDSen will be an > important part of the data collected and processed by a NEA > deployment. I agree that the IDS will play an important role for detecting potential mis-behaviour on the network and potentially interacting with the NEA Server or enforcement devices on the network (or endpoint). However the posture the IDS can learn by observing traffic is likely a subset of the posture a local Posture Collector can learn (e.g. version of RPMs installed). Its also not clear the PA, PB and PT are the right protocols for the NEA Server to detect the existance, redirect NEA Client requests and communicate with an IDS. We probably need a protocol more specific to this environment and this protocol could be something for later specification by the WG once we re-charter after successful definition of PA and PB. > > I think the text in this section needs clarification wrt > Posture Collectors which report on endpoints which are > different from the one the NEA Client (which the PC is part > of) is running on. Section 5.1.1 has text which uses the > NAT-box as an example of a case when a network entity is > _not_ responsible for reporting on the entities behind it. I > think the section needs text exemplifying the reverse - eg an > IDS reporting on the posture of endpoints within its scope. The NAT box analogy worked because it was the endpoint of assessment where the IDS is not if I understand your comment. Also as you noted the NAT box only reports on its own internal posture, not other devices. The IDS box could report its own posture using NEA, but believe this isn't what your requesting. Did I miss your point? Paul > > Cheers Leif > > > _______________________________________________ > 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 ------=_Part_186_13643447.1185223320555 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable My instinct is that if an IDS provides NEA client functionality= , then it should not be considered part of the IDS itself. If an IDS is act= ing as a collector/validator, that functionality should also be considered = separate from its functionality as an IDS. I believe we're risking running = afoul of complications if we blur these lines.

----- Original Messag= e -----
From: Paul Sangster <Paul_Sangster@symantec.com>
To: Le= if Johansson <leifj@it.su.se>, nea@ietf.org
Sent: Monday, July 23,= 2007 4:29:38 PM GMT-0500 US/Eastern
Subject: RE: [Nea] 03 comments - ID= S as Posture Collecotr

Comments below...

> -----Original = Message-----
> From: Leif Johansson [mailto:leifj@it.su.se]
> = Sent: Monday, July 23, 2007 12:15 PM
> To: nea@ietf.org
> Subje= ct: [Nea] 03 comments - IDS as Posture Collecotr

Curious about the t= opic, I presume your referring to IDS being used as a
NEA Client for oth= er systems?  In Prague we discussed whether the NEA
Client could ex= ist on non-endpoints such as an IDS reporting posture for
other endpoint= s.  The consensus (as we reported today) was this was
likely out of= scope for NEA's current charter and that using the planned
protocols mi= ght not make sense when talking to an IDS.

I presume this is the thr= ead your highlighting (since the Posture
Collector co-exists with the NE= A Client components).

>
>
> >From section 5.1.1.= 1:
>
>  5.1.1.1 Posture Collector
>     <= br>>     The Posture Collector is the component that is respon= sible for
>     responding to requests for posture informat= ion in Request
>     Attributes from the NEA Server.  = The Posture Collector is also
>     responsible for handlin= g assessment decisions in Result
>     Attributes and remed= iation instructions in Remediation
>     Attributes.  = A single NEA Client can have several Posture
>     Collecto= rs capable of collecting standard and/or vendor-specific
>   &nb= sp; Posture Attributes for particular endpoint components.  Typical>     examples include Posture Collectors that provide inform= ation
>     about Operating System (OS) patch levels, anti-= virus software,
>     and security mechanisms on the endpoi= nt such as host firewall or
>     an Intrusion Detection Sy= stem (IDS).
>
> Typically IDSen are _not_ part of the endpoint= but rather
> systems which are part of the overall network infrastr= ucture,
> eg active scanners such as "nessus" or passive scanners su= ch
> as "snort".
>
> I am convinced that information fr= om IDSen will be an
> important part of the data collected and proce= ssed by a NEA
> deployment.

I agree that the IDS will play an= important role for detecting potential
mis-behaviour on the network and= potentially interacting with the NEA
Server or enforcement devices on t= he network (or endpoint).  However the
posture the IDS can learn by= observing traffic is likely a subset of the
posture a local Posture Col= lector can learn (e.g. version of RPMs
installed).  Its also not cl= ear the PA, PB and PT are the right
protocols for the NEA Server to dete= ct the existance, redirect NEA
Client requests and communicate with an I= DS.  We probably need a
protocol more specific to this environment = and this protocol could be
something for later specification by the WG o= nce we re-charter after
successful definition of PA and PB.

> =
> I think the text in this section needs clarification wrt
> = Posture Collectors which report on endpoints which are
> different f= rom the one the NEA Client (which the PC is part
> of) is running on= . Section 5.1.1 has text which uses the
> NAT-box as an example of a= case when a network entity is
> _not_ responsible for reporting on = the entities behind it. I
> think the section needs text exemplifyin= g the reverse - eg an
> IDS reporting on the posture of endpoints wi= thin its scope.

The NAT box analogy worked because it was the endpoi= nt of assessment
where the IDS is not if I understand your comment. &nbs= p;Also as you noted
the NAT box only reports on its own internal posture= , not other devices.
The IDS box could report its own posture using NEA,= but believe this
isn't what your requesting.

Did I miss your poi= nt?

Paul

>
>     Cheers Leif
>
= >
> _______________________________________________
> Nea m= ailing list
> Nea@ietf.org
> https://www1.ietf.org/mailman/list= info/nea
>


______________________________________________= _
Nea mailing list
Nea@ietf.org
https://www1.ietf.org/mailman/list= info/nea
------=_Part_186_13643447.1185223320555-- --===============0579135134== 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 --===============0579135134==-- From nea-bounces@ietf.org Mon Jul 23 19:07:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID705-0004ui-8p; Mon, 23 Jul 2007 19:07:37 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1ID703-0004q9-Gh for nea-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 19:07:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID703-0004oH-5e for nea@ietf.org; Mon, 23 Jul 2007 19:07:35 -0400 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ID701-0006Kt-IL for nea@ietf.org; Mon, 23 Jul 2007 19:07:35 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id B169F3BE70; Tue, 24 Jul 2007 01:07:32 +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 24306-02-29; Tue, 24 Jul 2007 01:07:32 +0200 (CEST) Received: from [130.129.19.150] (dhcp-1396.ietf69.org [130.129.19.150]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id E553C3BE44; Tue, 24 Jul 2007 01:07:24 +0200 (CEST) Message-ID: <46A534B2.9060404@it.su.se> Date: Tue, 24 Jul 2007 01:07:30 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Paul Sangster Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr References: <46A4FE22.8020808@it.su.se> In-Reply-To: X-Enigmail-Version: 0.94.2.0 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.895 tagged_above=-99 required=7 tests=[AWL=0.417, BAYES_00=-2.312] X-Spam-Level: X-Spam-Score: -4.0 (----) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Paul Sangster wrote: > Comments below... > > >> -----Original Message----- >> From: Leif Johansson [mailto:leifj@it.su.se] >> Sent: Monday, July 23, 2007 12:15 PM >> To: nea@ietf.org >> Subject: [Nea] 03 comments - IDS as Posture Collecotr >> > > Curious about the topic, I presume your referring to IDS being used as a > NEA Client for other systems? In Prague we discussed whether the NEA > Client could exist on non-endpoints such as an IDS reporting posture for > other endpoints. The consensus (as we reported today) was this was > likely out of scope for NEA's current charter and that using the planned > protocols might not make sense when talking to an IDS. > That is partially why I bring this up again. Either the reference to IDS should go and be replaced with a very strong statement to the fact that the external posture collector is explicitly out of scope (or even forbidden) or the text should accurately reflect how IDSen actually work. Currently the text is confusing. I remember the discussion in Prague but don't remember that there was a strong consensus for keeping external PC out of scope. Having read the requirements draft I don't really see how this would really make the model that much more complex and I think there are very good reasons for keeping that use-case in the model. > I presume this is the thread your highlighting (since the Posture > Collector co-exists with the NEA Client components). > > >> >From section 5.1.1.1: >> >> 5.1.1.1 Posture Collector >> >> The Posture Collector is the component that is responsible for >> responding to requests for posture information in Request >> Attributes from the NEA Server. The Posture Collector is also >> responsible for handling assessment decisions in Result >> Attributes and remediation instructions in Remediation >> Attributes. A single NEA Client can have several Posture >> Collectors capable of collecting standard and/or vendor-specific >> Posture Attributes for particular endpoint components. Typical >> examples include Posture Collectors that provide information >> about Operating System (OS) patch levels, anti-virus software, >> and security mechanisms on the endpoint such as host firewall or >> an Intrusion Detection System (IDS). >> >> Typically IDSen are _not_ part of the endpoint but rather >> systems which are part of the overall network infrastructure, >> eg active scanners such as "nessus" or passive scanners such >> as "snort". >> >> I am convinced that information from IDSen will be an >> important part of the data collected and processed by a NEA >> deployment. >> > > I agree that the IDS will play an important role for detecting potential > mis-behaviour on the network and potentially interacting with the NEA > Server or enforcement devices on the network (or endpoint). However the > posture the IDS can learn by observing traffic is likely a subset of the > Absolutely not. An active scanner can detect actual vulnerabilities while listing installed software detects what vulnerabilities *should* exist on the endpoint. Both are interesting. > posture a local Posture Collector can learn (e.g. version of RPMs > installed). Its also not clear the PA, PB and PT are the right > protocols for the NEA Server to detect the existance, redirect NEA > Client requests and communicate with an IDS. We probably need a > protocol more specific to this environment and this protocol could be > something for later specification by the WG once we re-charter after > successful definition of PA and PB. > > >> I think the text in this section needs clarification wrt >> Posture Collectors which report on endpoints which are >> different from the one the NEA Client (which the PC is part >> of) is running on. Section 5.1.1 has text which uses the >> NAT-box as an example of a case when a network entity is >> _not_ responsible for reporting on the entities behind it. I >> think the section needs text exemplifying the reverse - eg an >> IDS reporting on the posture of endpoints within its scope. >> > > The NAT box analogy worked because it was the endpoint of assessment > where the IDS is not if I understand your comment. Also as you noted > Yes that is part of it. > the NAT box only reports on its own internal posture, not other devices. > The IDS box could report its own posture using NEA, but believe this > isn't what your requesting. > No, I'm interested in the case when a posture broker can request postures from entities not necessarily on the client (eg an IDS). Cheers Leif _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Jul 23 19:10:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID72g-00087x-EF; Mon, 23 Jul 2007 19:10:18 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1ID72f-00087q-65 for nea-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 19:10:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID72e-00087h-Re for nea@ietf.org; Mon, 23 Jul 2007 19:10:16 -0400 Received: from smtp3.su.se ([130.237.93.228]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID72e-0005CH-DZ for nea@ietf.org; Mon, 23 Jul 2007 19:10:16 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 313673BEC2; Tue, 24 Jul 2007 01:10:15 +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 24306-02-39; Tue, 24 Jul 2007 01:10:14 +0200 (CEST) Received: from [130.129.19.150] (dhcp-1396.ietf69.org [130.129.19.150]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 73D4B3BE70; Tue, 24 Jul 2007 01:10:10 +0200 (CEST) Message-ID: <46A53558.2080307@it.su.se> Date: Tue, 24 Jul 2007 01:10:16 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Robert Bird Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr References: <20637714.8571185223320555.JavaMail.root@cocalus.redlambda.com> In-Reply-To: <20637714.8571185223320555.JavaMail.root@cocalus.redlambda.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.896 tagged_above=-99 required=7 tests=[AWL=0.416, BAYES_00=-2.312] X-Spam-Level: X-Spam-Score: -4.0 (----) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 Robert Bird wrote: > My instinct is that if an IDS provides NEA client functionality, then > it should not be considered part of the IDS itself. If an IDS is > acting as a collector/validator, that functionality should also be > considered separate from its functionality as an IDS. I believe we're > risking running afoul of complications if we blur these lines. > I still don't understand. Here is the question: An active vulnerability scanner (eg nessus) running on an IDS server knows things about the client (from doing a scan). How is this information folded into the process of evaluating the posture of the client? Cheers Leif _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Jul 23 19:24:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID7GT-0000Wg-WC; Mon, 23 Jul 2007 19:24:34 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1ID7GS-0000P5-Lw for nea-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 19:24:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID7GQ-0000MJ-5c for nea@ietf.org; Mon, 23 Jul 2007 19:24:31 -0400 Received: from www.deployingradius.com ([216.240.42.17] helo=deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ID7GO-0006ig-F5 for nea@ietf.org; Mon, 23 Jul 2007 19:24:30 -0400 Received: from [130.129.17.247] (dhcp-11f7.ietf69.org [130.129.17.247]) by deployingradius.com (Postfix) with ESMTP id CC752A7161; Mon, 23 Jul 2007 16:24:22 -0700 (PDT) Message-ID: <46A538A6.7060705@deployingradius.com> Date: Mon, 23 Jul 2007 19:24:22 -0400 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Leif Johansson Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr References: <46A4FE22.8020808@it.su.se> <46A534B2.9060404@it.su.se> In-Reply-To: <46A534B2.9060404@it.su.se> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: nea@ietf.org, Paul Sangster X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Leif Johansson wrote: > No, I'm interested in the case when a posture broker can request > postures from entities not necessarily on the client (eg an IDS). i.e. The client says it's at update level X. You then ask the update manager if the client has downloaded update X. If not, the client *may* be lying to you. Alan DeKok. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Jul 23 20:00:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID7ov-0000X9-0a; Mon, 23 Jul 2007 20:00:09 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1ID7ot-0000R3-D6 for nea-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 20:00:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID7ot-0000Qv-1G for nea@ietf.org; Mon, 23 Jul 2007 20:00:07 -0400 Received: from cocalus.redlambda.com ([66.103.132.214]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID7os-0006De-EC for nea@ietf.org; Mon, 23 Jul 2007 20:00:06 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by cocalus.redlambda.com (Postfix) with ESMTP id 250F01D0822E; Mon, 23 Jul 2007 20:04:29 -0400 (EDT) X-DSPAM-Result: Innocent X-DSPAM-Processed: Mon Jul 23 20:04:27 2007 X-DSPAM-Confidence: 0.9997 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 46a5420b306272063786400 X-DSPAM-Factors: 27, X-Virus-Scanned: amavisd-new at X-Spam-Score: -3.669 X-Spam-Level: X-Spam-Status: No, score=-3.669 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, AWL=0.034, BAYES_00=-2.599, DSPAM_HAM=-0.1, HTML_00_10=0.795, HTML_MESSAGE=0.001] Received: from cocalus.redlambda.com ([127.0.0.1]) by localhost (cocalus.redlambda.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXxqAmp4TTOJ; Mon, 23 Jul 2007 20:04:27 -0400 (EDT) Received: from cocalus.redlambda.com (cocalus.redlambda.com [172.20.64.11]) by cocalus.redlambda.com (Postfix) with ESMTP id A80E21D0822A; Mon, 23 Jul 2007 20:04:27 -0400 (EDT) Message-ID: <8286628.8931185235467588.JavaMail.root@cocalus.redlambda.com> Date: Mon, 23 Jul 2007 20:04:27 -0400 (EDT) From: Robert Bird To: Leif Johansson Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr In-Reply-To: <46A53558.2080307@it.su.se> MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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="===============1889374052==" Errors-To: nea-bounces@ietf.org --===============1889374052== Content-Type: multipart/alternative; boundary="----=_Part_192_24147033.1185235467588" ------=_Part_192_24147033.1185235467588 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit You raise an interesting point. In that situation, where you have combined an IDS with vulnerability assessment, we would love to have that information correlated with the information collected from the endpoint. Why? Because we cannot safely assume that the endpoint can be trusted. I'm a big fan of doublechecking assumptions when it comes to security, and a whole lot of historical work ignores this issue. That problem, however, is not what I envision the NEA protocols solving. I agree with you 100% that this information is important, but I believe it is outside the charter for NEA. Intervendor security interoperability is the elephant in the room. But it's still not why we're in the room :) Take care, Rob ----- Original Message ----- From: Leif Johansson To: Robert Bird Cc: nea@ietf.org Sent: Monday, July 23, 2007 7:10:16 PM GMT-0500 US/Eastern Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr Robert Bird wrote: > My instinct is that if an IDS provides NEA client functionality, then > it should not be considered part of the IDS itself. If an IDS is > acting as a collector/validator, that functionality should also be > considered separate from its functionality as an IDS. I believe we're > risking running afoul of complications if we blur these lines. > I still don't understand. Here is the question: An active vulnerability scanner (eg nessus) running on an IDS server knows things about the client (from doing a scan). How is this information folded into the process of evaluating the posture of the client? Cheers Leif ------=_Part_192_24147033.1185235467588 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable You raise an interesting point. In that situation, where you ha= ve combined an IDS with vulnerability assessment, we would love to have tha= t information correlated with the information collected from the endpoint. = Why? Because we cannot safely assume that the endpoint can be trusted. I'm = a big fan of doublechecking assumptions when it comes to security, and a wh= ole lot of historical work ignores this issue.

That problem, however= , is not what I envision the NEA protocols solving. I agree with you 100% t= hat this information is important, but I believe it is outside the charter = for NEA.

Intervendor security interoperability is the elephant in th= e room. But it's still not why we're in the room :)
Take care,
Rob
----- Original Message -----
From: Leif Johansson <leifj@it.su.s= e>
To: Robert Bird <rbird@redlambda.com>
Cc: nea@ietf.orgSent: Monday, July 23, 2007 7:10:16 PM GMT-0500 US/Eastern
Subject: Re:= [Nea] 03 comments - IDS as Posture Collecotr

Robert Bird wrote:
= > My instinct is that if an IDS provides NEA client functionality, then<= br>> it should not be considered part of the IDS itself. If an IDS is> acting as a collector/validator, that functionality should also be> considered separate from its functionality as an IDS. I believe we're=
> risking running afoul of complications if we blur these lines.
= >
I still don't understand. Here is the question: An active vulnerabi= lity
scanner (eg nessus)
running on an IDS server knows things about = the client (from doing a
scan). How is this
information folded into t= he process of evaluating the posture of the client?

   &nb= sp;Cheers Leif

------=_Part_192_24147033.1185235467588-- --===============1889374052== 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 --===============1889374052==-- From nea-bounces@ietf.org Mon Jul 23 20:01:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID7q4-0001Jg-Q3; Mon, 23 Jul 2007 20:01:20 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1ID7q4-0001Jb-2h for nea-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 20:01:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID7q3-0001JT-P8 for nea@ietf.org; Mon, 23 Jul 2007 20:01:19 -0400 Received: from cocalus.redlambda.com ([66.103.132.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ID7q0-0007Mw-FC for nea@ietf.org; Mon, 23 Jul 2007 20:01:19 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by cocalus.redlambda.com (Postfix) with ESMTP id 9F3411D0822F for ; Mon, 23 Jul 2007 20:05:39 -0400 (EDT) X-DSPAM-Result: Innocent X-DSPAM-Processed: Mon Jul 23 20:05:39 2007 X-DSPAM-Confidence: 0.9997 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 46a54253309031542430122 X-DSPAM-Factors: 27, X-Virus-Scanned: amavisd-new at X-Spam-Score: -3.403 X-Spam-Level: X-Spam-Status: No, score=-3.403 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, AWL=-0.256, BAYES_00=-2.599, DSPAM_HAM=-0.1, HTML_10_20=1.351, HTML_MESSAGE=0.001] Received: from cocalus.redlambda.com ([127.0.0.1]) by localhost (cocalus.redlambda.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-fgWwDo38aN for ; Mon, 23 Jul 2007 20:05:39 -0400 (EDT) Received: from cocalus.redlambda.com (cocalus.redlambda.com [172.20.64.11]) by cocalus.redlambda.com (Postfix) with ESMTP id 2D5931D0822A for ; Mon, 23 Jul 2007 20:05:39 -0400 (EDT) Message-ID: <29716279.8961185235539108.JavaMail.root@cocalus.redlambda.com> Date: Mon, 23 Jul 2007 20:05:39 -0400 (EDT) From: Robert Bird To: nea Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr In-Reply-To: <46A538A6.7060705@deployingradius.com> MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f X-BeenThere: nea@ietf.org X-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="===============0096825637==" Errors-To: nea-bounces@ietf.org --===============0096825637== Content-Type: multipart/alternative; boundary="----=_Part_193_24077320.1185235539108" ------=_Part_193_24077320.1185235539108 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit But can we trust the update manager? :) ----- Original Message ----- From: Alan DeKok To: Leif Johansson Cc: nea@ietf.org, Paul Sangster Sent: Monday, July 23, 2007 7:24:22 PM GMT-0500 US/Eastern Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr Leif Johansson wrote: > No, I'm interested in the case when a posture broker can request > postures from entities not necessarily on the client (eg an IDS). i.e. The client says it's at update level X. You then ask the update manager if the client has downloaded update X. If not, the client *may* be lying to you. Alan DeKok. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea ------=_Part_193_24077320.1185235539108 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit But can we trust the update manager? :)

----- Original Message -----
From: Alan DeKok <aland@deployingradius.com>
To: Leif Johansson <leifj@it.su.se>
Cc: nea@ietf.org, Paul Sangster <Paul_Sangster@symantec.com>
Sent: Monday, July 23, 2007 7:24:22 PM GMT-0500 US/Eastern
Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr

Leif Johansson wrote:
> No, I'm interested in the case when a posture broker can request
> postures from entities not necessarily on the client (eg an IDS).

  i.e. The client says it's at update level X.  You then ask the update
manager if the client has downloaded update X.  If not, the client *may*
be lying to you.

  Alan DeKok.



_______________________________________________
Nea mailing list
Nea@ietf.org
https://www1.ietf.org/mailman/listinfo/nea
------=_Part_193_24077320.1185235539108-- --===============0096825637== 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 --===============0096825637==-- From nea-bounces@ietf.org Mon Jul 23 20:25:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID8Ds-0000MJ-Rz; Mon, 23 Jul 2007 20:25:56 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1ID8Dr-0000Hx-Uf for nea-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 20:25:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID8Dr-0000Ez-I6 for nea@ietf.org; Mon, 23 Jul 2007 20:25:55 -0400 Received: from smtp3.su.se ([130.237.93.228]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID8Dq-0006g8-Qk for nea@ietf.org; Mon, 23 Jul 2007 20:25:55 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id E847E3BED7; Tue, 24 Jul 2007 02:25:53 +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 28222-03-3; Tue, 24 Jul 2007 02:25:53 +0200 (CEST) Received: from [130.129.19.150] (dhcp-1396.ietf69.org [130.129.19.150]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id DCCFA3BEC8; Tue, 24 Jul 2007 02:25:52 +0200 (CEST) Message-ID: <46A54716.7080005@it.su.se> Date: Tue, 24 Jul 2007 02:25:58 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Robert Bird Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr References: <8286628.8931185235467588.JavaMail.root@cocalus.redlambda.com> In-Reply-To: <8286628.8931185235467588.JavaMail.root@cocalus.redlambda.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.899 tagged_above=-99 required=7 tests=[AWL=0.413, BAYES_00=-2.312] X-Spam-Level: X-Spam-Score: -4.0 (----) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 Robert Bird wrote: > You raise an interesting point. In that situation, where you have > combined an IDS with vulnerability assessment, we would love to have > that information correlated with the information collected from the > endpoint. Why? Because we cannot safely assume that the endpoint can > be trusted. I'm a big fan of doublechecking assumptions when it comes > to security, and a whole lot of historical work ignores this issue. > > That problem, however, is not what I envision the NEA protocols > solving. I agree with you 100% that this information is important, but > I believe it is outside the charter for NEA. > I agree. My question is this: How does adding this seriously affect the model? Cheers Leif _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Jul 23 20:30:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID8IB-0003eo-DD; Mon, 23 Jul 2007 20:30:23 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1ID8I9-0003ee-O9 for nea-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 20:30:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID8I9-0003eV-D5 for nea@ietf.org; Mon, 23 Jul 2007 20:30:21 -0400 Received: from smtp1.su.se ([130.237.162.112]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID8I8-0006jF-N2 for nea@ietf.org; Mon, 23 Jul 2007 20:30:20 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp1.su.se (Postfix) with ESMTP id C68D17407D; Tue, 24 Jul 2007 02:30:19 +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 16849-02-16; Tue, 24 Jul 2007 02:30:19 +0200 (CEST) Received: from [130.129.19.150] (dhcp-1396.ietf69.org [130.129.19.150]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp1.su.se (Postfix) with ESMTP id A554D74018; Tue, 24 Jul 2007 02:30:18 +0200 (CEST) Message-ID: <46A54820.6090307@it.su.se> Date: Tue, 24 Jul 2007 02:30:24 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Alan DeKok Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr References: <46A4FE22.8020808@it.su.se> <46A534B2.9060404@it.su.se> <46A538A6.7060705@deployingradius.com> In-Reply-To: <46A538A6.7060705@deployingradius.com> X-Enigmail-Version: 0.94.2.0 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.534 tagged_above=-99 required=7 tests=[AWL=0.778, BAYES_00=-2.312] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: nea@ietf.org, Paul Sangster X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 wrote: > Leif Johansson wrote: > >> No, I'm interested in the case when a posture broker can request >> postures from entities not necessarily on the client (eg an IDS). >> > > i.e. The client says it's at update level X. You then ask the update > manager if the client has downloaded update X. If not, the client *may* > be lying to you. > > Alan DeKok. > > That is yet another example. Good! I don't want to make this about lying or not. That is a big rat- hole. Its about different sources of information providing a better view of the client together than separately. I really don't see how taking the requirement that "the client is at the endpoint" out of the specification makes things that much more complex. Cheers Leif _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Jul 23 20:49:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID8b0-0007zR-4J; Mon, 23 Jul 2007 20:49:50 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1ID8az-0007zM-Mi for nea-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 20:49:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID8az-0007zE-D0 for nea@ietf.org; Mon, 23 Jul 2007 20:49:49 -0400 Received: from extu-mxob-1.symantec.com ([216.10.194.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ID8ax-0008AS-U0 for nea@ietf.org; Mon, 23 Jul 2007 20:49:49 -0400 Received: from tus1opsmtapin01.ges.symantec.com ([192.168.214.43]) by extu-mxob-1.symantec.com with esmtp (Exim 4.66) (envelope-from ) id 1ID8ax-0003Vo-6R; Mon, 23 Jul 2007 17:49:47 -0700 Received: from reserved-155-64-230-18.ges.symantec.com ([155.64.230.18] helo=TUS1XCHECNPIN01.enterprise.veritas.com) by tus1opsmtapin01.ges.symantec.com with esmtp (Exim 4.67) (envelope-from ) id 1ID8aw-0000JK-Qr; Mon, 23 Jul 2007 17:49:46 -0700 Received: from TUS1XCHEVSPIN05.enterprise.veritas.com ([155.64.231.28]) by TUS1XCHECNPIN01.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 17:49:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] 03 comments - IDS as Posture Collecotr Date: Mon, 23 Jul 2007 17:49:45 -0700 Message-ID: In-Reply-To: <46A54820.6090307@it.su.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] 03 comments - IDS as Posture Collecotr thread-index: AcfNidbihVYEwj70ScCqoyOzf3C9AQAAOuyQ References: <46A4FE22.8020808@it.su.se> <46A534B2.9060404@it.su.se> <46A538A6.7060705@deployingradius.com> <46A54820.6090307@it.su.se> From: "Paul Sangster" To: "Leif Johansson" , "Alan DeKok" X-OriginalArrivalTime: 24 Jul 2007 00:49:46.0929 (UTC) FILETIME=[884E3210:01C7CD8C] X-Brightmail-Verdict: VlJEQwAAAAIAAAABAAAAAAAAAAEAAAAAAAAAA2luYm94AGFsYW5kQGRlcGxveWluZ3JhZGl1cy5jb20AbmVhQGlldGYub3JnAGxlaWZqQGl0LnN1LnNlAA== X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -4.0 (----) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Comments below...=20 > -----Original Message----- > From: Leif Johansson [mailto:leifj@it.su.se]=20 > Sent: Monday, July 23, 2007 5:30 PM > To: Alan DeKok > Cc: Paul Sangster; nea@ietf.org > Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr >=20 > Alan DeKok wrote: > > Leif Johansson wrote: > > =20 > >> No, I'm interested in the case when a posture broker can request=20 > >> postures from entities not necessarily on the client (eg an IDS). > >> =20 > > > > i.e. The client says it's at update level X. You then ask the=20 > > update manager if the client has downloaded update X. If not, the=20 > > client *may* be lying to you. > > > > Alan DeKok. > > > > =20 > That is yet another example. Good! >=20 > I don't want to make this about lying or not. That is a big=20 > rat- hole. Its about different sources of information=20 > providing a better view of the client together than separately. >=20 > I really don't see how taking the requirement that "the=20 > client is at the endpoint" out of the specification makes=20 > things that much more complex. Are you proposing that the entire NEA Client would exist on the non-endpoint (IDS system)? I suspect not, but you might be thinking of the Posture Broker Client and Posture Collectors. If the Posture Transport Client is separate from the Posture Broker Client this changes some assumptions including the security requirements for PB (which we lowered since it was stated these co-exist and PT has manditory to implement security features). This also means the PB layer wouldn't sit on the endpoints PT so some other assumptions/text would need to be revised. Some of the other requirements are also impacted as the IDS would need to have a way to support an assessment as the endpoint in joining the network so we would need to talk about how this would work since the IDS might not be involved in that process or know in real-time that its occurring. I also believe that an IDS can not provide the same level of detailed posture information that an endpoint collector so this might impact our standard attributes. There is also a lot of text in the spec that would need to change including in the security and privacy considerations sections. So there are a lot of changes needed but its feasible. I believe we heard that a new protocol to support properly interacting with an IDS is outside our currently approved charter. If we think this is very important, we could try to address this after we meet at least our initial chartered milestone (reqs spec) and start the future milestone discussion. =20 Do we believe that PA and PB could be used to talk to the IDS? What transport protocol would sit below them and that may also be outside of charter. All interesting questions, but I do think adding this causes lots of changes of varying sizes throughout the spec. *If* this is deemed within our charter, we should see what that WG wishes to do here. >=20 > Cheers Leif >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Jul 23 21:05:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID8q2-0001lf-E4; Mon, 23 Jul 2007 21:05:22 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1ID8q1-0001gY-EE for nea-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 21:05:21 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID8q0-0001eQ-Co for nea@ietf.org; Mon, 23 Jul 2007 21:05:20 -0400 Received: from e34.co.us.ibm.com ([32.97.110.152]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID8py-0007Gc-TV for nea@ietf.org; Mon, 23 Jul 2007 21:05:19 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e34.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l6O15I5L032320 for ; Mon, 23 Jul 2007 21:05:18 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.4) with ESMTP id l6O15Ig9199152 for ; Mon, 23 Jul 2007 19:05:18 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l6O15Hw4015179 for ; Mon, 23 Jul 2007 19:05:17 -0600 Received: from d03nm129.boulder.ibm.com (d03nm129.boulder.ibm.com [9.17.195.155]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l6O15Hoh015176; Mon, 23 Jul 2007 19:05:17 -0600 In-Reply-To: <46A54820.6090307@it.su.se> Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr To: Leif Johansson X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Frank Yeh Jr Date: Mon, 23 Jul 2007 18:04:54 -0700 X-MIMETrack: Serialize by Router on D03NM129/03/M/IBM(Release 7.0.2HF32 | October 17, 2006) at 07/23/2007 19:05:17 MIME-Version: 1.0 X-Spam-Score: -4.0 (----) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 Cc: Paul Sangster , 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="===============1453173889==" Errors-To: nea-bounces@ietf.org --===============1453173889== Content-type: multipart/alternative; Boundary="0__=07BBF9B1DF9038558f9e8a93df938690918c07BBF9B1DF903855" Content-Disposition: inline --0__=07BBF9B1DF9038558f9e8a93df938690918c07BBF9B1DF903855 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Greetings, I've been lurking on this thread because I don't really get the p= oint of asking a third party for a state of the client as part of the protoc= ol. I was hoping to learn something from watching the conversation but so f= ar I still do not see the value of doing this and I also believe that theadditional complexity of the client not being at the endpoint might = be a little more than trivial. So right now the protocol essentially instantiates a tunnel betwe= en the endpoint and the validator, and also gives the validator a way to direct the network how to treat the client. Building more than these ba= sic interfaces does complicate the issue... Right now there is a single supplicant on the tunnel and this client is the one that is either gran= ted or denied network access. If you add in third party (EG IDS) into the m= ix, now you have to have a protocol and an interface to talk to an IDS or a= ny other conceivable 3rd party and the 3rd patry has to be able to associa= te the client with the right network port so that its access can be controlled. This would then have to be built into the protocol. Why is this better than just having the validator check with the = IDS for whatever it is you want checked? The client can simply submit a uni= que client id and the validator can then do whatever is desired on the othe= r end of the tunnel, including checking with IDS systems or registration systems or update managers. This can all be done on the validator side AFTER the client data has been passed down the tunnel. An alternative is to make the IDS a validator and then have the client send it's state and have the IDS validate that it is not spoofin= g. Doesn't this support the desired scenario without having to change the protocol? Add that in as a separate validator and let the client and servers do the brokering. IMHO this is how the protocol was designed to= work. My basic concern is that if we try to build too many external interfaces into the protocol it will become a never-ending battle. We w= ant levels of abstraction so that things can change external to the protoco= l. My preference is to make it a secure tunnel for passing state data over= the network with specific functions between the client/server and the netwo= rk to control requesting/granting/denying access. As to the decision makin= g process, this should be left outside the protocol per se, and handled = by the validators outside of the tunnel. PLEASE NOTE nothing I say here precludes any of the scenarios tha= t have been discussed being supported outside of the protocol by the validators. My fundamental argument is that we need to limit the scope = of what the protocol is and does. People will always find uses for a technology that is outside of its intended function. trying to anticipa= te everything people will try to do and building it in is a fool's errand.= The best thing we can do is to make the standard as generic and flexible as= possible. A good analogy would be RISC VS CISC processors. I like the protocol to be lean and mean like RISC_ adding in separate interfaces f= or an IDS to report on the state of the client is a huge complicator. Frank Yeh Sr. Security & Privacy Integration Architect IBM Global Technology Services Security & Privacy Technology Integration Team Second Life: Yehoo Newall Leif Johansson wrote on 07/23/2007 05:30:24 PM: > Alan DeKok wrote: > > Leif Johansson wrote: > > > >> No, I'm interested in the case when a posture broker can request > >> postures from entities not necessarily on the client (eg an IDS). > >> > > > > i.e. The client says it's at update level X. You then ask the up= date > > manager if the client has downloaded update X. If not, the client *may* > > be lying to you. > > > > Alan DeKok. > > > > > That is yet another example. Good! > > I don't want to make this about lying or not. That is a big rat- > hole. Its about different sources of information providing a > better view of the client together than separately. > > I really don't see how taking the requirement that "the > client is at the endpoint" out of the specification makes > things that much more complex. > > Cheers Leif = --0__=07BBF9B1DF9038558f9e8a93df938690918c07BBF9B1DF903855 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Greetings,

I've been lurking on this thread because I don't really get the point = of asking a third party for a state of the client as part of the pro= tocol. I was hoping to learn something from watching the conversati= on but so far I still do not see the value of doing this and I also bel= ieve that theadditional complexity of the client not being at the endpo= int might be a little more than trivial.

So right now the protocol essentially instantiates a tunnel between th= e endpoint and the validator, and also gives the validator a way to dir= ect the network how to treat the client. Building more than these basic= interfaces does complicate the issue... Right now there is a single su= pplicant on the tunnel and this client is the one that is either grante= d or denied network access. If you add in third party (EG IDS) into the= mix, now you have to have a protocol and an interface to talk to an ID= S or any other conceivable 3rd party and the 3rd patry has to be able t= o associate the client with the right network port so that its access c= an be controlled. This would then have to be built into the protocol. Why is this better than just having the validator check with the IDS f= or whatever it is you want checked? The client can simply submit a uniq= ue client id and the validator can then do whatever is desired on the o= ther end of the tunnel, including checking with IDS systems or registra= tion systems or update managers. This can all be done on the validator = side AFTER the client data has been passed down the tunnel.

An alternative is to make the IDS a validator and then have the client= send it's state and have the IDS validate that it is not spoofing. Doe= sn't this support the desired scenario without having to change the pro= tocol? Add that in as a separate validator and let the client and serve= rs do the brokering. IMHO this is how the protocol was designed to work= .

My basic concern is that if we try to build too many external interfac= es into the protocol it will become a never-ending battle. We want leve= ls of abstraction so that things can change external to the protocol. M= y preference is to make it a secure tunnel for passing state data over = the network with specific functions between the client/server and the n= etwork to control requesting/granting/denying access. As to the decisio= n making process, this should be left outside the protocol per se, and = handled by the validators outside of the tunnel.

PLEASE NOTE nothing I say here precludes any of the scenarios that hav= e been discussed being supported outside of the protocol by the validat= ors. My fundamental argument is that we need to limit the scope of what= the protocol is and does. People will always find uses for a technolog= y that is outside of its intended function. trying to anticipate everyt= hing people will try to do and building it in is a fool's errand. The b= est thing we can do is to make the standard as generic and flexible as = possible. A good analogy would be RISC VS CISC processors. I like the = protocol to be lean and mean like RISC_ adding in separate interfaces f= or an IDS to report on the state of the client is a huge complicator.

Frank Yeh
Sr. Security & Privacy Integration Architect
IBM Global Technology Services
Security & Privacy Technology Integration Team

Second Life: Yehoo Newall

Leif Johansson <leifj@it.su.se> wrote on 07/23/2007 05:30:24 = PM:

> Alan DeKok wrote:
> > Leif Johansson wrote:
> >  
> >> No, I'm interested in the case when a posture broker can = request
> >> postures from entities not necessarily on the client (eg = an IDS).
> >>    
> >
> >   i.e. The client says it's at update level X.  You= then ask the update
> > manager if the client has downloaded update X.  If not, = the client *may*
> > be lying to you.
> >
> >   Alan DeKok.
> >
> >  
> That is yet another example. Good!
>
> I don't want to make this about lying or not. That is a big rat- > hole. Its about different sources of information providing a
> better view of the client together than separately.
>
> I really don't see how taking the requirement that "the
> client is at the endpoint" out of the specification makes
= > things that much more complex.
>
>     Cheers Leif

= --0__=07BBF9B1DF9038558f9e8a93df938690918c07BBF9B1DF903855-- --===============1453173889== 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 --===============1453173889==-- From nea-bounces@ietf.org Tue Jul 24 09:13:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDKCT-0004KW-FO; Tue, 24 Jul 2007 09:13:17 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IDKCQ-0004EJ-6F for nea-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 09:13:14 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDKCM-0004Dm-Bb for nea@ietf.org; Tue, 24 Jul 2007 09:13:10 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDKCK-0001YR-SH for nea@ietf.org; Tue, 24 Jul 2007 09:13:10 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 24 Jul 2007 06:13:08 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0KAEOXpUarR7PE/2dsb2JhbACCLTc X-IronPort-AV: i="4.16,574,1175497200"; d="scan'208,217"; a="387700927:sNHT150695338" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l6ODD71D019161; Tue, 24 Jul 2007 06:13:07 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l6ODD4Sb008295; Tue, 24 Jul 2007 13:13:05 GMT Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 06:13:04 -0700 Received: from 10.21.86.139 ([10.21.86.139]) by xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) with Microsoft Exchange Server HTTP-DAV ; Tue, 24 Jul 2007 13:13:04 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Tue, 24 Jul 2007 06:13:02 -0700 Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr From: Kaushik Narayan To: Frank Yeh Jr , Leif Johansson Message-ID: Thread-Topic: [Nea] 03 comments - IDS as Posture Collecotr Thread-Index: AcfN9F0Km5EpFDnnEdyWpAAX8tamGQ== In-Reply-To: Mime-version: 1.0 X-OriginalArrivalTime: 24 Jul 2007 13:13:04.0880 (UTC) FILETIME=[5EC17700:01C7CDF4] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=11656; t=1185282787; x=1186146787; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kaushik@cisco.com; z=From:=20Kaushik=20Narayan=20 |Subject:=20Re=3A=20[Nea]=2003=20comments=20-=20IDS=20as=20Posture=20Coll ecotr |Sender:=20; bh=q1+KGuMKVQiyxgM4/WcUcFXsV8BNPHsctp4e6SGUBjc=; b=Np/0n+EBXKoxj6lISYhf8/wePMMl//IjtNS7cFhvOk9cjofxkCg3h1RibgchKoL+6JWmDK1w tXppQllzdBitt4QeD2IrgUJOyRxyIuDys34tdiE5RM+unhaPuWs3/60A; Authentication-Results: sj-dkim-4; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 1.8 (+) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d Cc: nea@ietf.org, Paul Sangster X-BeenThere: nea@ietf.org X-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="===============1219367815==" Errors-To: nea-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1219367815== Content-type: multipart/alternative; boundary="B_3268102382_19023393" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3268102382_19023393 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I agree with Frank. The scenario being discussed can addressed by treating an IDS system (and scanners) as validators or in many cases the IDS system might be a component that validators can acquire attributes from since the IDS system natively might not evaluate an endpoint compliance policy. The interaction between NEA and the IDS system would be part of the vertical protocol stack on the NEA server which is currently out-of-scope. On 7/23/07 6:04 PM, "Frank Yeh Jr" wrote: > Greetings, > > I've been lurking on this thread because I don't really get the point of > asking a third party for a state of the client as part of the protocol. I was > hoping to learn something from watching the conversation but so far I still do > not see the value of doing this and I also believe that theadditional > complexity of the client not being at the endpoint might be a little more than > trivial. > > So right now the protocol essentially instantiates a tunnel between the > endpoint and the validator, and also gives the validator a way to direct the > network how to treat the client. Building more than these basic interfaces > does complicate the issue... Right now there is a single supplicant on the > tunnel and this client is the one that is either granted or denied network > access. If you add in third party (EG IDS) into the mix, now you have to have > a protocol and an interface to talk to an IDS or any other conceivable 3rd > party and the 3rd patry has to be able to associate the client with the right > network port so that its access can be controlled. This would then have to be > built into the protocol. > Why is this better than just having the validator check with the IDS for > whatever it is you want checked? The client can simply submit a unique client > id and the validator can then do whatever is desired on the other end of the > tunnel, including checking with IDS systems or registration systems or update > managers. This can all be done on the validator side AFTER the client data has > been passed down the tunnel. > > An alternative is to make the IDS a validator and then have the client send > it's state and have the IDS validate that it is not spoofing. Doesn't this > support the desired scenario without having to change the protocol? Add that > in as a separate validator and let the client and servers do the brokering. > IMHO this is how the protocol was designed to work. > > My basic concern is that if we try to build too many external interfaces into > the protocol it will become a never-ending battle. We want levels of > abstraction so that things can change external to the protocol. My preference > is to make it a secure tunnel for passing state data over the network with > specific functions between the client/server and the network to control > requesting/granting/denying access. As to the decision making process, this > should be left outside the protocol per se, and handled by the validators > outside of the tunnel. > > PLEASE NOTE nothing I say here precludes any of the scenarios that have been > discussed being supported outside of the protocol by the validators. My > fundamental argument is that we need to limit the scope of what the protocol > is and does. People will always find uses for a technology that is outside of > its intended function. trying to anticipate everything people will try to do > and building it in is a fool's errand. The best thing we can do is to make the > standard as generic and flexible as possible. A good analogy would be RISC VS > CISC processors. I like the protocol to be lean and mean like RISC_ adding in > separate interfaces for an IDS to report on the state of the client is a huge > complicator. > > > Frank Yeh > Sr. Security & Privacy Integration Architect > IBM Global Technology Services > Security & Privacy Technology Integration Team > > Second Life: Yehoo Newall > > Leif Johansson wrote on 07/23/2007 05:30:24 PM: > >> > Alan DeKok wrote: >>> > > Leif Johansson wrote: >>> > > >>>> > >> No, I'm interested in the case when a posture broker can request >>>> > >> postures from entities not necessarily on the client (eg an IDS). >>>> > >> >>> > > >>> > > i.e. The client says it's at update level X. You then ask the update >>> > > manager if the client has downloaded update X. If not, the client *may* >>> > > be lying to you. >>> > > >>> > > Alan DeKok. >>> > > >>> > > >> > That is yet another example. Good! >> > >> > I don't want to make this about lying or not. That is a big rat- >> > hole. Its about different sources of information providing a >> > better view of the client together than separately. >> > >> > I really don't see how taking the requirement that "the >> > client is at the endpoint" out of the specification makes >> > things that much more complex. >> > >> > Cheers Leif > > > > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea --B_3268102382_19023393 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [Nea] 03 comments - IDS as Posture Collecotr
I agree with Frank. The scenario being discussed can addressed by treating = an IDS system (and scanners) as validators or in many cases the IDS system m= ight be a component that validators can acquire attributes from since the ID= S system natively might not evaluate an endpoint compliance policy. The inte= raction between NEA and the IDS system would be part of the vertical protoco= l stack on the NEA server which is currently out-of-scope.


On 7/23/07 6:04 PM, "Frank Yeh Jr" <fyeh@us.ibm.com> wrote:=

Greetings,

I've been lurking on this thread because I don't really get the point of as= king a third party for a state of the client as part of the protocol.= I was hoping to learn something from watching the conversation but so far I= still do not see the value of doing this and I also believe that theadditio= nal complexity of the client not being at the endpoint might be a little mor= e than trivial.

So right now the protocol essentially instantiates a tunnel between the end= point and the validator, and also gives the validator a way to direct the ne= twork how to treat the client. Building more than these basic interfaces doe= s complicate the issue... Right now there is a single supplicant on the tunn= el and this client is the one that is either granted or denied network acces= s. If you add in third party (EG IDS) into the mix, now you have to have a p= rotocol and an interface to talk to an IDS or any other conceivable 3rd part= y and the 3rd patry has to be able to associate the client with the right ne= twork port so that its access can be controlled. This would then have to be = built into the protocol.
Why is this better than just having the validator check with the IDS for wh= atever it is you want checked? The client can simply submit a unique client = id and the validator can then do whatever is desired on the other end of the= tunnel, including checking with IDS systems or registration systems or upda= te managers. This can all be done on the validator side AFTER the client dat= a has been passed down the tunnel.

An alternative is to make the IDS a validator and then have the client send= it's state and have the IDS validate that it is not spoofing. Doesn't this = support the desired scenario without having to change the protocol? Add that= in as a separate validator and let the client and servers do the brokering.= IMHO this is how the protocol was designed to work.

My basic concern is that if we try to build too many external interfaces in= to the protocol it will become a never-ending battle. We want levels of abst= raction so that things can change external to the protocol. My preference is= to make it a secure tunnel for passing state data over the network with spe= cific functions between the client/server and the network to control request= ing/granting/denying access. As to the decision making process, this should = be left outside the protocol per se, and handled  by the validators out= side of the tunnel.

PLEASE NOTE nothing I say here precludes any of the scenarios that have bee= n discussed being supported outside of the protocol by the validators. My fu= ndamental argument is that we need to limit the scope of what the protocol i= s and does. People will always find uses for a technology that is outside of= its intended function. trying to anticipate everything people will try to d= o and building it in is a fool's errand. The best thing we can do is to make= the standard as generic and flexible as possible.  A good analogy woul= d be RISC VS CISC processors. I like the protocol to be lean and mean like R= ISC_ adding in separate interfaces for an IDS to report on the state of the = client is a huge complicator.


Frank Yeh
Sr. Security & Privacy Integration Architect
IBM Global Technology Services
Security & Privacy Technology Integration Team

Second Life: Yehoo Newall

Leif Johansson <leifj@it.su.se> wrote on 07/23/2007 05:30:24 PM:
> Alan DeKok wrote:
> > Leif Johansson wrote:
> >   
> >> No, I'm interested in the case when a posture broker can requ= est
> >> postures from entities not necessarily on the client (eg an I= DS).
> >>     
> >
> >   i.e. The client says it's at update level X.  Yo= u then ask the update
> > manager if the client has downloaded update X.  If not, the = client *may*
> > be lying to you.
> >
> >   Alan DeKok.
> >
> >   
> That is yet another example. Good!
>
> I don't want to make this about lying or not. That is a big rat-
> hole. Its about different sources of information providing a
> better view of the client together than separately.
>
> I really don't see how taking the requirement that "the
> client is at the endpoint" out of the specification makes
> things that much more complex.
>
>     Cheers Leif


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

 --B_3268102382_19023393-- --===============1219367815== 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 --===============1219367815==-- From nea-bounces@ietf.org Tue Jul 24 10:33:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDLSG-0006Td-25; Tue, 24 Jul 2007 10:33:40 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IDLSF-0006TY-9U for nea-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 10:33:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDLSE-0006TO-Tv for nea@ietf.org; Tue, 24 Jul 2007 10:33:38 -0400 Received: from www.deployingradius.com ([216.240.42.17] helo=deployingradius.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDLSE-0003Ui-2C for nea@ietf.org; Tue, 24 Jul 2007 10:33:38 -0400 Received: from [130.129.16.75] (dhcp-104b.ietf69.org [130.129.16.75]) by deployingradius.com (Postfix) with ESMTP id 1AE49A7161; Tue, 24 Jul 2007 07:33:34 -0700 (PDT) Message-ID: <46A60DAC.7020202@deployingradius.com> Date: Tue, 24 Jul 2007 10:33:16 -0400 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Frank Yeh Jr Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr References: In-Reply-To: X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: nea@ietf.org, Paul Sangster X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 Yeh Jr wrote: > I've been lurking on this thread because I don't really get the point of > asking a third party for a state of the client /as part of the > protocol/. I was hoping to learn something from watching the > conversation but so far I still do not see the value of doing this and I > also believe that theadditional complexity of the client not being at > the endpoint might be a little more than trivial. I discussed this with Paul last night. My view is that it may be useful to obtain posture assessment from multiple devices. Generally, devices will be endpoints. However, other devices can act as "taps" on the network, and can give additional information about endpoint posture. NEA should be focussed on endpoint assessment. However, it should permit NEA servers to obtain posture assessments from other devices. > ... If you add in third party (EG IDS) > into the mix, now you have to have a protocol and an interface to talk > to an IDS PA protocol + other transport. > or any other conceivable 3rd party and the 3rd patry has to be > able to associate the client with the right network port so that its > access can be controlled. This would then have to be built into the > protocol. No. This exact same issue has come up in RADEXT recently. IDS devices can not associate the client with the "right" network port. They should not be expected to do that. Instead, they can inform another server (NEA or AAA) of the devices posture. That other server can use that information to instruct the switch how to deal with the endpoint. In RADIUS, the AAA server can send a request to the switch, instructing it to disconnect the non-compliant device. People have deployed this today. It's a model that is useful, and it works. NEA should permit the same behavior. > Why is this better than just having the validator check with the IDS for > whatever it is you want checked? The client may not engage in non-compliant behavior until after it has obtained network access. The client may claim it's compliant, but later analysis may show that it is not, in fact, compliant. The IDS determines this, and informs the NEA server. The NEA server has a relationship with the switch, and informs the switch to modify it's treatment of the endpoint. > An alternative is to make the IDS a validator and then have the client > send it's state and have the IDS validate that it is not spoofing. That is possible. We do not want to *require* such behavior, though. This means requiring an NEA server, and optionally permitting an IDS. > PLEASE NOTE nothing I say here precludes any of the scenarios that have > been discussed being supported outside of the protocol by the > validators. My fundamental argument is that we need to limit the scope > of what the protocol is and does. Yes. We should also permit behavior that people find useful. Alan DeKok. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Jul 24 11:06:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDLxp-0007PW-MG; Tue, 24 Jul 2007 11:06:17 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IDLxo-0007KP-JZ for nea-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 11:06:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDLxo-0007KG-9j for nea@ietf.org; Tue, 24 Jul 2007 11:06:16 -0400 Received: from elasmtp-curtail.atl.sa.earthlink.net ([209.86.89.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDLxm-0000wH-UV for nea@ietf.org; Tue, 24 Jul 2007 11:06:16 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=jAyhkcLJKKFGde0M8cacQtBLSVgTd7xj0qVrGBLg25qYubJhSILqojKXitvHAajK; 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 [64.125.79.23] (helo=gw) by elasmtp-curtail.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IDLxk-00036P-8d; Tue, 24 Jul 2007 11:06:12 -0400 Message-ID: <006101c7ce04$3ab91e70$174f7d40@home.glassey.com> From: "todd glassey" To: "Alan DeKok" , "Frank Yeh Jr" References: <46A60DAC.7020202@deployingradius.com> Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr Date: Tue, 24 Jul 2007 07:53:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79209e62c8e4e3c7f25307116c05338f07350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.125.79.23 X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: nea@ietf.org, Paul Sangster X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 - and Frank - the key issue is in creating a USE MODEL for the actual NEA package and its components which performs the collection and dissemination processes. Without these end-user guidance models we wont know what functions are critical and what are not. I propose that NEA actually put forth the effort to build these rather than spending thousands of the collectives hours designing 'yet another solution in search of a problem' which most other IETF initiatives are shackled down by. Just my two cents Todd Glassey ----- Original Message ----- From: "Alan DeKok" To: "Frank Yeh Jr" Cc: ; "Paul Sangster" Sent: Tuesday, July 24, 2007 7:33 AM Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr > Frank Yeh Jr wrote: >> I've been lurking on this thread because I don't really get the point of >> asking a third party for a state of the client /as part of the >> protocol/. I was hoping to learn something from watching the >> conversation but so far I still do not see the value of doing this and I >> also believe that theadditional complexity of the client not being at >> the endpoint might be a little more than trivial. > > I discussed this with Paul last night. My view is that it may be > useful to obtain posture assessment from multiple devices. Generally, > devices will be endpoints. However, other devices can act as "taps" on > the network, and can give additional information about endpoint posture. > > NEA should be focussed on endpoint assessment. However, it should > permit NEA servers to obtain posture assessments from other devices. > >> ... If you add in third party (EG IDS) >> into the mix, now you have to have a protocol and an interface to talk >> to an IDS > > PA protocol + other transport. > >> or any other conceivable 3rd party and the 3rd patry has to be >> able to associate the client with the right network port so that its >> access can be controlled. This would then have to be built into the >> protocol. > > No. This exact same issue has come up in RADEXT recently. IDS > devices can not associate the client with the "right" network port. > They should not be expected to do that. Instead, they can inform > another server (NEA or AAA) of the devices posture. That other server > can use that information to instruct the switch how to deal with the > endpoint. > > In RADIUS, the AAA server can send a request to the switch, > instructing it to disconnect the non-compliant device. People have > deployed this today. It's a model that is useful, and it works. > > NEA should permit the same behavior. > >> Why is this better than just having the validator check with the IDS for >> whatever it is you want checked? > > The client may not engage in non-compliant behavior until after it has > obtained network access. The client may claim it's compliant, but later > analysis may show that it is not, in fact, compliant. The IDS > determines this, and informs the NEA server. The NEA server has a > relationship with the switch, and informs the switch to modify it's > treatment of the endpoint. > >> An alternative is to make the IDS a validator and then have the client >> send it's state and have the IDS validate that it is not spoofing. > > That is possible. We do not want to *require* such behavior, though. > This means requiring an NEA server, and optionally permitting an IDS. > >> PLEASE NOTE nothing I say here precludes any of the scenarios that have >> been discussed being supported outside of the protocol by the >> validators. My fundamental argument is that we need to limit the scope >> of what the protocol is and does. > > Yes. We should also permit behavior that people find useful. > > Alan DeKok. > > > _______________________________________________ > 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 Jul 24 11:12:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDM3y-0002iU-0r; Tue, 24 Jul 2007 11:12:38 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IDM3x-0002iN-2p for nea-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 11:12:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDM3w-0002iD-PI for nea@ietf.org; Tue, 24 Jul 2007 11:12:36 -0400 Received: from elasmtp-banded.atl.sa.earthlink.net ([209.86.89.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDM3v-00014Z-AA for nea@ietf.org; Tue, 24 Jul 2007 11:12:36 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=rzIod2lzCPiXj7fJc/f65Orp36zr4oV69QgCPRxlLuJG/saFzLHP8dAtALoheg9r; 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 [64.125.79.23] (helo=gw) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IDM3r-0005rz-TX; Tue, 24 Jul 2007 11:12:32 -0400 Message-ID: <007b01c7ce05$1d0406f0$174f7d40@home.glassey.com> From: "todd glassey" To: "Robert Bird" , "Leif Johansson" References: <8286628.8931185235467588.JavaMail.root@cocalus.redlambda.com> Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr Date: Tue, 24 Jul 2007 08:12:53 -0700 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec794c702dce6aa60ee9b80cc7d4db0a22c6350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.125.79.23 X-Spam-Score: 0.0 (/) X-Scan-Signature: a1f9797ba297220533cb8c3f4bc709a8 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="===============1970193322==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============1970193322== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0078_01C7CDCA.6F5E7E20" This is a multi-part message in MIME format. ------=_NextPart_000_0078_01C7CDCA.6F5E7E20 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Robert - I agree with you about most of your posting - but for the = purpose of this mailing let me play the Devil's Advocate here... ----- Original Message -----=20 From: Robert Bird=20 To: Leif Johansson=20 Cc: nea@ietf.org=20 Sent: Monday, July 23, 2007 5:04 PM Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr You raise an interesting point. In that situation,=20 Robert - you mean "in that specific use model"... right?=20 where you have combined an IDS with vulnerability assessment, we would = love to have that information correlated with the information collected = from the endpoint. Why? Because we cannot safely assume that the = endpoint can be trusted.=20 Why not? I'm a big fan of doublechecking assumptions when it comes to security, = and a whole lot of historical work ignores this issue. I am too but in some use scenario's it wont be necessary so the use = model and its assurance levels will be what constrains and provides this = info. That problem, however, is not what I envision the NEA protocols = solving. I agree with you 100% that this information is important, but I = believe it is outside the charter for NEA. Again - "I envision solving" is a statement that "your vision is = different from others" and the reason for that is that there is NO = COMMON USE MODEL that has been agreed upon... Intervendor security interoperability is the elephant in the room.=20 No actually the issue is in defining Intervendor Functionality across a = common use model... again its the USE MODEL which is missing here still. But it's still not why we're in the room :) Take care, Rob ----- Original Message ----- From: Leif Johansson To: Robert Bird Cc: nea@ietf.org Sent: Monday, July 23, 2007 7:10:16 PM GMT-0500 US/Eastern Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr Robert Bird wrote: > My instinct is that if an IDS provides NEA client functionality, = then > it should not be considered part of the IDS itself. If an IDS is > acting as a collector/validator, that functionality should also be > considered separate from its functionality as an IDS. I believe = we're > risking running afoul of complications if we blur these lines. > I still don't understand. Here is the question: An active = vulnerability scanner (eg nessus) running on an IDS server knows things about the client (from doing a scan). How is this information folded into the process of evaluating the posture of the = client? Cheers Leif -------------------------------------------------------------------------= ----- _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea ------=_NextPart_000_0078_01C7CDCA.6F5E7E20 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Robert - I agree with = you  about=20 most of your posting - but for the purpose of this mailing let me play = the=20 Devil's Advocate here...
----- Original Message -----
From:=20 Robert Bird=20
Sent: Monday, July 23, 2007 = 5:04 PM
Subject: Re: [Nea] 03 comments = - IDS as=20 Posture Collecotr

You raise an interesting point. In that situation,
 
Robert - you mean "in that = specific use=20 model"... right?
 
where you have combined an IDS with vulnerability assessment, we = would=20 love to have that information correlated with the information = collected from=20 the endpoint. Why? Because we cannot safely assume that the endpoint = can be=20 trusted.
 
Why not?
 
 
I'm a big fan of doublechecking assumptions when it comes to = security,=20 and a whole lot of historical work ignores this issue.
 
I am too but in some use = scenario's it=20 wont be necessary so the use model and its assurance levels will be what = constrains and provides this info.


That problem, however, is not what I envision the NEA = protocols=20 solving. I agree with you 100% that this information is important, but = I=20 believe it is outside the charter for NEA.
 
 
Again - "I envision = solving" is a=20 statement that "your vision is different from others" and the reason for = that is=20 that there is NO COMMON USE MODEL that has been agreed = upon...


Intervendor security interoperability is the elephant in = the=20 room.
 
No actually the issue is in = defining=20 Intervendor Functionality across a common use model... again its the USE = MODEL=20 which is missing here still.
 
 
But it's still not why we're in the room :)
Take=20 care,
Rob

----- Original Message -----
From: Leif = Johansson=20 <leifj@it.su.se>
To: Robert Bird = <rbird@redlambda.com>
Cc:=20 nea@ietf.org
Sent: Monday, July 23, 2007 7:10:16 PM GMT-0500=20 US/Eastern
Subject: Re: [Nea] 03 comments - IDS as Posture=20 Collecotr

Robert Bird wrote:
> My instinct is that if an = IDS=20 provides NEA client functionality, then
> it should not be = considered=20 part of the IDS itself. If an IDS is
> acting as a = collector/validator,=20 that functionality should also be
> considered separate from its = functionality as an IDS. I believe we're
> risking running afoul = of=20 complications if we blur these lines.
>
I still don't = understand.=20 Here is the question: An active vulnerability
scanner (eg=20 nessus)
running on an IDS server knows things about the client = (from doing=20 a
scan). How is this
information folded into the process of = evaluating=20 the posture of the client?

    Cheers=20 Leif

_______________________________________________
Nea mailing=20 = list
Nea@ietf.org
https://www1.ietf.org/mailman/listinfo/nea
------=_NextPart_000_0078_01C7CDCA.6F5E7E20-- --===============1970193322== 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 --===============1970193322==-- From nea-bounces@ietf.org Tue Jul 24 11:32:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDMMi-0003Rk-Hs; Tue, 24 Jul 2007 11:32:00 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IDMMg-0003Rb-PC for nea-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 11:31:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDMMg-0003RT-FV for nea@ietf.org; Tue, 24 Jul 2007 11:31:58 -0400 Received: from cocalus.redlambda.com ([66.103.132.214]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDMMc-00020Q-Tx for nea@ietf.org; Tue, 24 Jul 2007 11:31:58 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by cocalus.redlambda.com (Postfix) with ESMTP id 9D7A71D0822F; Tue, 24 Jul 2007 11:36:18 -0400 (EDT) X-DSPAM-Result: Innocent X-DSPAM-Processed: Tue Jul 24 11:36:17 2007 X-DSPAM-Confidence: 0.9997 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 46a61c71224685093016810 X-DSPAM-Factors: 27, X-Virus-Scanned: amavisd-new at X-Spam-Score: -3.895 X-Spam-Level: X-Spam-Status: No, score=-3.895 tagged_above=-10 required=6.6 tests=[ALL_TRUSTED=-1.8, AWL=0.469, BAYES_00=-2.599, DSPAM_HAM=-0.1, HTML_50_60=0.134, HTML_MESSAGE=0.001] Received: from cocalus.redlambda.com ([127.0.0.1]) by localhost (cocalus.redlambda.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id idNjIwiBZCoe; Tue, 24 Jul 2007 11:36:17 -0400 (EDT) Received: from cocalus.redlambda.com (cocalus.redlambda.com [172.20.64.11]) by cocalus.redlambda.com (Postfix) with ESMTP id 756A41D0822A; Tue, 24 Jul 2007 11:36:17 -0400 (EDT) Message-ID: <14212697.10031185291377364.JavaMail.root@cocalus.redlambda.com> Date: Tue, 24 Jul 2007 11:36:17 -0400 (EDT) From: Robert Bird To: todd glassey Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr In-Reply-To: <007b01c7ce05$1d0406f0$174f7d40@home.glassey.com> MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b7d60495f1a7f2e853e8cbae7e6dbfc 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="===============1384241201==" Errors-To: nea-bounces@ietf.org --===============1384241201== Content-Type: multipart/alternative; boundary="----=_Part_225_16172787.1185291377363" ------=_Part_225_16172787.1185291377363 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Todd, thanks for the clarity regarding "use model" ...we are in agreement on this issue. Other comments inline. ----- Original Message ----- From: todd glassey To: Robert Bird , Leif Johansson Cc: nea@ietf.org Sent: Tuesday, July 24, 2007 11:12:53 AM GMT-0500 US/Eastern Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr Robert - I agree with you about most of your posting - but for the purpose of this mailing let me play the Devil's Advocate here... ----- Original Message ----- From: Robert Bird To: Leif Johansson Cc: nea@ietf.org Sent: Monday, July 23, 2007 5:04 PM Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr You raise an interesting point. In that situation, Robert - you mean "in that specific use model"... right? Yes. Specifically, the use model that he was referring to: leveraging vulnerability assessment and/or IDS information to double check posture claims. where you have combined an IDS with vulnerability assessment, we would love to have that information correlated with the information collected from the endpoint. Why? Because we cannot safely assume that the endpoint can be trusted. Why not? Why can we :p? Seriously, though, your point is well taken. There will be certain use models predicated on the assumption that endpoints can be trusted. Other use models will not. I still believe that posture is at best a claim made by the client. It may be factual, but only the use model will determine if those claims need to be validated by another source. I'm a big fan of doublechecking assumptions when it comes to security, and a whole lot of historical work ignores this issue. I am too but in some use scenario's it wont be necessary so the use model and its assurance levels will be what constrains and provides this info. Agreed. That problem, however, is not what I envision the NEA protocols solving. I agree with you 100% that this information is important, but I believe it is outside the charter for NEA. Again - "I envision solving" is a statement that "your vision is different from others" and the reason for that is that there is NO COMMON USE MODEL that has been agreed upon... Agreed. In fact, it's painfully obvious now that a use model needs to be defined. Intervendor security interoperability is the elephant in the room. No actually the issue is in defining Intervendor Functionality across a common use model... again its the USE MODEL which is missing here still. The horse is dead, and I'm still riding it :) But it's still not why we're in the room :) Take care, Rob ----- Original Message ----- From: Leif Johansson To: Robert Bird Cc: nea@ietf.org Sent: Monday, July 23, 2007 7:10:16 PM GMT-0500 US/Eastern Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr Robert Bird wrote: > My instinct is that if an IDS provides NEA client functionality, then > it should not be considered part of the IDS itself. If an IDS is > acting as a collector/validator, that functionality should also be > considered separate from its functionality as an IDS. I believe we're > risking running afoul of complications if we blur these lines. > I still don't understand. Here is the question: An active vulnerability scanner (eg nessus) running on an IDS server knows things about the client (from doing a scan). How is this information folded into the process of evaluating the posture of the client? Cheers Leif _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea ------=_Part_225_16172787.1185291377363 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Todd, thanks for the clarity regarding "use model"...we are in agreement on this issue. Other comments inline.

----- Original Message -----
From: todd glassey <tglassey@earthlink.net>
To: Robert Bird <rbird@redlambda.com>, Leif Johansson <leifj@it.su.se>
Cc: nea@ietf.org
Sent: Tuesday, July 24, 2007 11:12:53 AM GMT-0500 US/Eastern
Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr

Robert - I agree with you  about most of your posting - but for the purpose of this mailing let me play the Devil's Advocate here...
----- Original Message -----
Sent: Monday, July 23, 2007 5:04 PM
Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr

You raise an interesting point. In that situation,
 
Robert - you mean "in that specific use model"... right?

Yes. Specifically, the use model that he was referring to: leveraging vulnerability assessment and/or IDS information to double check posture claims.
 
where you have combined an IDS with vulnerability assessment, we would love to have that information correlated with the information collected from the endpoint. Why? Because we cannot safely assume that the endpoint can be trusted.
 
Why not?

Why can we :p? Seriously, though, your point is well taken. There will be certain use models predicated on the assumption that endpoints can be trusted. Other use models will not. I still believe that posture is at best a claim made by the client. It may be factual, but only the use model will determine if those claims need to be validated by another source.
 
 
I'm a big fan of doublechecking assumptions when it comes to security, and a whole lot of historical work ignores this issue.
 
I am too but in some use scenario's it wont be necessary so the use model and its assurance levels will be what constrains and provides this info.

Agreed.


That problem, however, is not what I envision the NEA protocols solving. I agree with you 100% that this information is important, but I believe it is outside the charter for NEA.
 
 
Again - "I envision solving" is a statement that "your vision is different from others" and the reason for that is that there is NO COMMON USE MODEL that has been agreed upon...

Agreed. In fact, it's painfully obvious now that a use model needs to be defined.


Intervendor security interoperability is the elephant in the room.
 
No actually the issue is in defining Intervendor Functionality across a common use model... again its the USE MODEL which is missing here still.

The horse is dead, and I'm still riding it :)
 
 
But it's still not why we're in the room :)
Take care,
Rob

----- Original Message -----
From: Leif Johansson <leifj@it.su.se>
To: Robert Bird <rbird@redlambda.com>
Cc: nea@ietf.org
Sent: Monday, July 23, 2007 7:10:16 PM GMT-0500 US/Eastern
Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr

Robert Bird wrote:
> My instinct is that if an IDS provides NEA client functionality, then
> it should not be considered part of the IDS itself. If an IDS is
> acting as a collector/validator, that functionality should also be
> considered separate from its functionality as an IDS. I believe we're
> risking running afoul of complications if we blur these lines.
>
I still don't understand. Here is the question: An active vulnerability
scanner (eg nessus)
running on an IDS server knows things about the client (from doing a
scan). How is this
information folded into the process of evaluating the posture of the client?

    Cheers Leif

_______________________________________________
Nea mailing list
Nea@ietf.org
https://www1.ietf.org/mailman/listinfo/nea
------=_Part_225_16172787.1185291377363-- --===============1384241201== 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 --===============1384241201==-- From nea-bounces@ietf.org Tue Jul 24 11:36:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDMRI-0001Kn-Hs; Tue, 24 Jul 2007 11:36:44 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IDMRH-0001Kf-Jm for nea-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 11:36:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDMRH-0001IA-47 for nea@ietf.org; Tue, 24 Jul 2007 11:36:43 -0400 Received: from elasmtp-spurfowl.atl.sa.earthlink.net ([209.86.89.66]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDMRF-0005bs-Rx for nea@ietf.org; Tue, 24 Jul 2007 11:36:42 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=snf74zKo5WqInvsZ0huq9WJoK3c3Vz5mpcE5eZ53RisAUNeGmYvgbxzBDtLJT360; 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 [64.125.79.23] (helo=gw) by elasmtp-spurfowl.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IDMRC-0006cm-CN; Tue, 24 Jul 2007 11:36:38 -0400 Message-ID: <00db01c7ce08$7b2dae40$174f7d40@home.glassey.com> From: "todd glassey" To: "Robert Bird" References: <14212697.10031185291377364.JavaMail.root@cocalus.redlambda.com> Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr Date: Tue, 24 Jul 2007 08:37:00 -0700 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79bdb5822ab3f2e13411421139e9e0be5b350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.125.79.23 X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3d702b63698072ba67a75ce9e0fc9e 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="===============1512822489==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============1512822489== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00D6_01C7CDCD.CD7512A0" This is a multi-part message in MIME format. ------=_NextPart_000_00D6_01C7CDCD.CD7512A0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Robert - I also to illustrate also that MANY of the existing IETF = Protocols suffer from this 'gerrymandering set of functionalities' in = trying to meet the desires of the committee that is working on them at = any given instant. What this means is that the functionality of the = Standard's or proposed Standards is a moving target and that is what = needs to be nailed down in my opinion... (humble or otherwise). What NEA needs to have is a set of pre-defined specific use and = functionality models which will define the specific features and = constraints for each of those end-use models. It will also allow = Auditor's to use NEA models more readily which will be a key value to = the Industry in implementing the IETF's vision and guidance from this WG = as to its use. 2 more cents.=20 Todd ----- Original Message -----=20 From: Robert Bird=20 To: todd glassey=20 Cc: nea@ietf.org ; Leif Johansson=20 Sent: Tuesday, July 24, 2007 8:36 AM Subject: Re: [Nea] 03 comments - IDS as Posture Collector Todd, thanks for the clarity regarding "use model"...we are in = agreement on this issue. Other comments inline. ----- Original Message ----- From: todd glassey To: Robert Bird , Leif Johansson Cc: nea@ietf.org Sent: Tuesday, July 24, 2007 11:12:53 AM GMT-0500 US/Eastern Subject: Re: [Nea] 03 comments - IDS as Posture Collector Robert - I agree with you about most of your posting - but for the = purpose of this mailing let me play the Devil's Advocate here... ----- Original Message -----=20 From: Robert Bird=20 To: Leif Johansson=20 Cc: nea@ietf.org=20 Sent: Monday, July 23, 2007 5:04 PM Subject: Re: [Nea] 03 comments - IDS as Posture Collector You raise an interesting point. In that situation,=20 Robert - you mean "in that specific use model"... right? Yes. Specifically, the use model that he was referring to: leveraging = vulnerability assessment and/or IDS information to double check posture = claims. where you have combined an IDS with vulnerability assessment, we = would love to have that information correlated with the information = collected from the endpoint. Why? Because we cannot safely assume that = the endpoint can be trusted.=20 Why not? Why can we :p? Seriously, though, your point is well taken. There will = be certain use models predicated on the assumption that endpoints can be = trusted. Other use models will not. I still believe that posture is at = best a claim made by the client. It may be factual, but only the use = model will determine if those claims need to be validated by another = source. I'm a big fan of doublechecking assumptions when it comes to = security, and a whole lot of historical work ignores this issue. I am too but in some use scenario's it wont be necessary so the use = model and its assurance levels will be what constrains and provides this = info. Agreed. That problem, however, is not what I envision the NEA protocols = solving. I agree with you 100% that this information is important, but I = believe it is outside the charter for NEA. Again - "I envision solving" is a statement that "your vision is = different from others" and the reason for that is that there is NO = COMMON USE MODEL that has been agreed upon... Agreed. In fact, it's painfully obvious now that a use model needs to = be defined. Intervendor security interoperability is the elephant in the room.=20 No actually the issue is in defining Intervendor Functionality across = a common use model... again its the USE MODEL which is missing here = still. The horse is dead, and I'm still riding it :) But it's still not why we're in the room :) Take care, Rob ----- Original Message ----- From: Leif Johansson To: Robert Bird Cc: nea@ietf.org Sent: Monday, July 23, 2007 7:10:16 PM GMT-0500 US/Eastern Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr Robert Bird wrote: > My instinct is that if an IDS provides NEA client functionality, = then > it should not be considered part of the IDS itself. If an IDS is > acting as a collector/validator, that functionality should also be > considered separate from its functionality as an IDS. I believe = we're > risking running afoul of complications if we blur these lines. > I still don't understand. Here is the question: An active = vulnerability scanner (eg nessus) running on an IDS server knows things about the client (from doing a scan). How is this information folded into the process of evaluating the posture of the = client? Cheers Leif -------------------------------------------------------------------------= --- _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea ------=_NextPart_000_00D6_01C7CDCD.CD7512A0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Robert - I also to = illustrate also that=20 MANY of the existing IETF Protocols suffer from this 'gerrymandering set = of=20 functionalities' in trying to meet the desires of the committee that is = working=20 on them at any given instant. What this means is that the functionality = of the=20 Standard's or proposed Standards is a moving target and that is what = needs to be=20 nailed down in my opinion... (humble or otherwise).

What NEA needs to have is a set of pre-defined specific use and = functionality models which will define the specific features and = constraints for=20 each of those end-use models. It will also allow Auditor's to use NEA = models=20 more readily which will be a key value to the Industry in implementing = the=20 IETF's vision and guidance from this WG as to its use.
 
2 more cents.
 
Todd
----- Original Message -----
From:=20 Robert Bird=20
Sent: Tuesday, July 24, 2007 = 8:36=20 AM
Subject: Re: [Nea] 03 comments = - IDS as=20 Posture Collector

Todd, thanks for the clarity regarding "use model"...we = are in=20 agreement on this issue. Other comments inline.

----- Original = Message=20 -----
From: todd glassey <tglassey@earthlink.net>
= To:=20 Robert Bird <rbird@redlambda.com>, Leif = Johansson=20 <leifj@it.su.se>
Cc: nea@ietf.org
Sent: Tuesday, July = 24, 2007=20 11:12:53 AM GMT-0500 US/Eastern
Subject: Re: [Nea] 03 comments - = IDS as=20 Posture Collector

Robert - I agree with = you  about=20 most of your posting - but for the purpose of this mailing let me play = the=20 Devil's Advocate here...
-----=20 Original Message ----- From:=20 Robert Bird To:=20 Leif=20 Johansson Cc:=20 nea@ietf.org Sent:=20 Monday, July 23, 2007 5:04 PM Subject:=20 Re: [Nea] 03 comments - IDS as Posture Collector

You raise an interesting point. In that situation,
 
Robert - you mean "in = that specific=20 use model"... right?

Yes. = Specifically,=20 the use model that he was referring to: leveraging vulnerability = assessment=20 and/or IDS information to double check posture = claims.
 
where you have combined an IDS with vulnerability assessment, = we would=20 love to have that information correlated with the information = collected from=20 the endpoint. Why? Because we cannot safely assume that the endpoint = can be=20 trusted.
 
Why not?

Why can = we :p?=20 Seriously, though, your point is well taken. There will be certain use = models=20 predicated on the assumption that endpoints can be trusted. Other use = models=20 will not. I still believe that posture is at best a claim made by the = client.=20 It may be factual, but only the use model will determine if those = claims need=20 to be validated by another source.
 
 
I'm a big fan of doublechecking assumptions when it comes to = security,=20 and a whole lot of historical work ignores this issue.
 
I am too but in some use = scenario's=20 it wont be necessary so the use model and its assurance levels will be = what=20 constrains and provides this info.

Agreed.


That problem, however, is not what I envision the NEA = protocols=20 solving. I agree with you 100% that this information is important, = but I=20 believe it is outside the charter for NEA.
 
 
Again - "I envision = solving" is a=20 statement that "your vision is different from others" and the reason = for that=20 is that there is NO COMMON USE MODEL that has been agreed = upon...

Agreed. In fact, it's painfully obvious = now that a=20 use model needs to be defined.


Intervendor security interoperability is the elephant = in the=20 room.
 
No actually the issue is = in defining=20 Intervendor Functionality across a common use model... again its the = USE MODEL=20 which is missing here still.

The horse=20 is dead, and I'm still riding it :)
 
 
But it's still not why we're in the room :)
Take=20 care,
Rob

----- Original Message -----
From: Leif = Johansson=20 <leifj@it.su.se>
To: Robert Bird = <rbird@redlambda.com>
Cc:=20 nea@ietf.org
Sent: Monday, July 23, 2007 7:10:16 PM GMT-0500=20 US/Eastern
Subject: Re: [Nea] 03 comments - IDS as Posture=20 Collecotr

Robert Bird wrote:
> My instinct is that if = an IDS=20 provides NEA client functionality, then
> it should not be = considered=20 part of the IDS itself. If an IDS is
> acting as a=20 collector/validator, that functionality should also be
> = considered=20 separate from its functionality as an IDS. I believe we're
> = risking=20 running afoul of complications if we blur these lines.
>
I = still=20 don't understand. Here is the question: An active = vulnerability
scanner=20 (eg nessus)
running on an IDS server knows things about the = client (from=20 doing a
scan). How is this
information folded into the process = of=20 evaluating the posture of the client?

   =  Cheers=20 Leif

_______________________________________________
Nea = mailing=20 = list
Nea@ietf.org
https://www1.ietf.org/mailman/listinfo/nea
------=_NextPart_000_00D6_01C7CDCD.CD7512A0-- --===============1512822489== 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 --===============1512822489==-- From nea-bounces@ietf.org Tue Jul 24 11:40:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDMVI-0002pj-8S; Tue, 24 Jul 2007 11:40:52 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IDMVG-0002oR-Pe for nea-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 11:40:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDMVG-0002oE-Fs for nea@ietf.org; Tue, 24 Jul 2007 11:40:50 -0400 Received: from www.deployingradius.com ([216.240.42.17] helo=deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDMVE-0002HF-Ua for nea@ietf.org; Tue, 24 Jul 2007 11:40:50 -0400 Received: from [130.129.16.75] (dhcp-104b.ietf69.org [130.129.16.75]) by deployingradius.com (Postfix) with ESMTP id BAB85A7161; Tue, 24 Jul 2007 08:40:45 -0700 (PDT) Message-ID: <46A61D7B.5060808@deployingradius.com> Date: Tue, 24 Jul 2007 11:40:43 -0400 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: todd glassey Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr References: <46A60DAC.7020202@deployingradius.com> <006101c7ce04$3ab91e70$174f7d40@home.glassey.com> In-Reply-To: <006101c7ce04$3ab91e70$174f7d40@home.glassey.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: nea@ietf.org, Paul Sangster X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org todd glassey wrote: > Alan - and Frank - the key issue is in creating a USE MODEL for the > actual NEA package and its components which performs the collection and > dissemination processes. Without these end-user guidance models we wont > know what functions are critical and what are not. The requirements document does a good job of describing many use models. The discussion here is about additional use models that should be permitted under NEA. Those additional use models are being deployed *now* using existing protocols, precisely because administrators see those functions as being critical. My proposal is that the NEA WG recognize that other use models exist, and that those use models should not be prevented by the NEA design. I do NOT want to spend time standardizing them in NEA, as I see them as being out of scope of the charter. We should concentrate on endpoints, rather than additional posture collection points. > I propose that NEA actually put forth the effort to build these rather > than spending thousands of the collectives hours designing 'yet another > solution in search of a problem' which most other IETF initiatives are > shackled down by. I'm not sure what you mean by that. All of the use models discussed here are: * requested by network administrators * deployed today in non-standard protocols * deployed today in non-NEA protocols. Alan DeKok. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Jul 24 12:04:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDMsB-00074v-LT; Tue, 24 Jul 2007 12:04:31 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IDMs9-00074g-RT for nea-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 12:04:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDMs9-00074X-FE for nea@ietf.org; Tue, 24 Jul 2007 12:04:29 -0400 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDMs8-0006Gd-SC for nea@ietf.org; Tue, 24 Jul 2007 12:04:29 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=K4v9l3c+QVjnWNI7pIfyCqD5c0cJFmN5zgbiUYvavfNKiWX2BqQrkv2NXnfyf4ea; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.32] (helo=elwamui-cypress.atl.sa.earthlink.net) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IDMs6-0001dP-Pc; Tue, 24 Jul 2007 12:04:26 -0400 Received: from 209.133.117.100 by webmail.pas.earthlink.net with HTTP; Tue, 24 Jul 2007 12:04:26 -0400 Message-ID: <8823488.1185293066599.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> Date: Tue, 24 Jul 2007 09:04:26 -0700 (GMT-07:00) From: Todd Glassey To: Alan DeKok Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec7924295716c182735d7ad345a24e298cdf350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.32 X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: nea@ietf.org, Paul Sangster X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Todd Glassey List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Alan - again my push back is in the role of Devil's Advocate... more inline below - -----Original Message----- >From: Alan DeKok >Sent: Jul 24, 2007 8:40 AM >To: todd glassey >Cc: Frank Yeh Jr , nea@ietf.org, Paul Sangster >Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr > >todd glassey wrote: >> Alan - and Frank - the key issue is in creating a USE MODEL for the >> actual NEA package and its components which performs the collection and >> dissemination processes. Without these end-user guidance models we wont >> know what functions are critical and what are not. > > The requirements document does a good job of describing many use >models. The point is that each USE MODEL has its own constraints and that is what is not defined. Also defining a "USE MODEL" is not just illustrating a potential use, but rather building a flow and protocol for that use's operations and that is totally missing from the work now IMHO. > The discussion here is about additional use models that should >be permitted under NEA. Those additional use models are being deployed >*now* using existing protocols, precisely because administrators see >those functions as being critical. Not really - the discussion here is whether the undocumented uses existing today should be expanded to meet more 'ideas of how to use NEA'... > > My proposal is that the NEA WG recognize that other use models exist, >and that those use models should not be prevented by the NEA design. This MAY OR MAY NOT make severe changes in the underlying functionality of the NEA suite. That's the problem too - some of the new uses may be contraindicated from those already established. > I >do NOT want to spend time standardizing them in NEA, as I see them as >being out of scope of the charter. We should concentrate on endpoints, >rather than additional posture collection points. This is the basic flaw in much of the IETF's operations - the "We want to build something that is everything to everyone" mindset and its what screws up most of these initiatives. The Functionality of NEA is a key part of what NEA is and does, and its that it seems you want to expand. I would put it that this expansion requires a new use model for each expansion and that these use models need proper 'release engineering' done on them, not just the core-engineering that the IETF likes to apply to something and then quickly call it a standard. > >> I propose that NEA actually put forth the effort to build these rather >> than spending thousands of the collectives hours designing 'yet another >> solution in search of a problem' which most other IETF initiatives are >> shackled down by. > > I'm not sure what you mean by that. All of the use models discussed >here are: > > * requested by network administrators For what purpose? > * deployed today in non-standard protocols to accomplish what purpose? > * deployed today in non-NEA protocols. Which means that NEA-WG may be replicating features and functionality already codified inside the IETF too eh? Isnt that a violation of the IETF's charter - to reinvent the wheel in a new color or type of rubber for each new car? > > Alan DeKok. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Jul 24 12:20:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDN7p-0001gw-7e; Tue, 24 Jul 2007 12:20:41 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IDN7f-0001ZI-Vj for nea-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 12:20:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDN7c-0001WX-SC for nea@ietf.org; Tue, 24 Jul 2007 12:20:29 -0400 Received: from e33.co.us.ibm.com ([32.97.110.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDN7a-0004CP-NL for nea@ietf.org; Tue, 24 Jul 2007 12:20:28 -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.13.8) with ESMTP id l6OGKQ51021323 for ; Tue, 24 Jul 2007 12:20:26 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.4) with ESMTP id l6OGKPUK205348 for ; Tue, 24 Jul 2007 10:20:25 -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 l6OGKPNM022927 for ; Tue, 24 Jul 2007 10:20:25 -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 l6OGKPtv022913; Tue, 24 Jul 2007 10:20:25 -0600 In-Reply-To: <00db01c7ce08$7b2dae40$174f7d40@home.glassey.com> Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr To: "todd glassey" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Frank Yeh Jr Date: Tue, 24 Jul 2007 09:20:22 -0700 X-MIMETrack: Serialize by Router on D03NM129/03/M/IBM(Release 7.0.2HF32 | October 17, 2006) at 07/24/2007 10:20:24 MIME-Version: 1.0 X-Spam-Score: -4.0 (----) X-Scan-Signature: 92bf9d0448089f15cee3c3c378c3e25d 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="===============0173874596==" Errors-To: nea-bounces@ietf.org --===============0173874596== Content-type: multipart/related; Boundary="0__=07BBF9B1DFC540598f9e8a93df938690918c07BBF9B1DFC54059" --0__=07BBF9B1DFC540598f9e8a93df938690918c07BBF9B1DFC54059 Content-type: multipart/alternative; Boundary="1__=07BBF9B1DFC540598f9e8a93df938690918c07BBF9B1DFC54059" --1__=07BBF9B1DFC540598f9e8a93df938690918c07BBF9B1DFC54059 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Greetings, I may have missed something as the NEA work and the CNAC/TNC protocols are starting to get a little blended in my head, but I was un= der the impression that we had well-defined use cases for the protocol. Much of the discussions about IDS or other third parties being ab= le to terminate a client's connectivity are focused on post-admission chec= king rather than pre-admission checking and these two cases are the only realistic split. For pre-admission, I believe the existing discussions are fine an= d it has been pointed out that there is nothing precluding the use of an IDS= as a validator that provides an admission decision to the server. For post-admission I am not convinced we need to give an external= entity the ability to initiate a conversation with the NEA components. = All current definitions allow the validator or the client to perform period= ic or triggered revalidations and terminate the connection if non-complian= t state is found. This gives the collectors and validators the freedom to= do whatever post-admission checking they desire. Now for post-admission decisions coming from say and IDS server, = the implication is that the IDS server reaches a decision as to the non-compliant state of a client independently of the NEA protocols. The= re is then nothing to preclude such an IDS server from terminating the client's connectiovity using a RADIUS command to the network device. Wh= ile, this is how the CNAC and TNC servers communicate with the network devic= es, they do not have a monopoly on this. For my money, I would want the IDS operating independently from t= he NEA stuff. Tighter integration leads to tainting. If you want the IDS t= o be a watchdog, do not associate it with the protocol, make it a completely= independent observer with the ability to cut off a client's access independent of NEA. Now what I might see as viable would be a way for t= he IDS to perform a second check while the client is in "quarantine" so th= at it can validate that the non-compliant state that it detected in the fi= rst place has been remediated. This is why I favor the IDS as an actual validator on the server side of the NEA protocol, talking to the NEA se= rver as all validators do. This would allow the IDS to be a part of the pre-admission decision and to terminate a client's access post-admissio= n, and to independently reinitiate a revalidation of the client. All of th= is would operate within the current definitions of the procotol. Regards, Frank Yeh Sr. Security & Privacy Integration Architect IBM Global Technology Services Security & Privacy Technology Integration Team Second Life: Yehoo Newall = "todd glassey" = = To "Robert Bird" 07/24/2007 08:37 = cc AM nea@ietf.org = Subj= ect Re: [Nea] 03 comments - IDS as = Posture Collecotr = = = = = = = Robert - I also to illustrate also that MANY of the existing IETF Proto= cols suffer from this 'gerrymandering set of functionalities' in trying to m= eet the desires of the committee that is working on them at any given insta= nt. What this means is that the functionality of the Standard's or proposed= Standards is a moving target and that is what needs to be nailed down i= n my opinion... (humble or otherwise). What NEA needs to have is a set of pre-defined specific use and functionality models which will define the specific features and constraints for each of those end-use models. It will also allow Audito= r's to use NEA models more readily which will be a key value to the Industr= y in implementing the IETF's vision and guidance from this WG as to its use.= 2 more cents. Todd ----- Original Message ----- From: Robert Bird To: todd glassey Cc: nea@ietf.org ; Leif Johansson Sent: Tuesday, July 24, 2007 8:36 AM Subject: Re: [Nea] 03 comments - IDS as Posture Collector Todd, thanks for the clarity regarding "use model"...we are in agreeme= nt on this issue. Other comments inline. ----- Original Message ----- From: todd glassey To: Robert Bird , Leif Johansson = Cc: nea@ietf.org Sent: Tuesday, July 24, 2007 11:12:53 AM GMT-0500 US/Eastern Subject: Re: [Nea] 03 comments - IDS as Posture Collector Robert - I agree with you about most of your posting - but for the purpose of this mailing let me play the Devil's Advocate here... ----- Original Message ----- From: Robert Bird To: Leif Johansson Cc: nea@ietf.org Sent: Monday, July 23, 2007 5:04 PM Subject: Re: [Nea] 03 comments - IDS as Posture Collector You raise an interesting point. In that situation, Robert - you mean "in that specific use model"... right? Yes. Specifically, the use model that he was referring to: leveraging vulnerability assessment and/or IDS information to double check postur= e claims. where you have combined an IDS with vulnerability assessment, we would= love to have that information correlated with the information collecte= d from the endpoint. Why? Because we cannot safely assume that the endpo= int can be trusted. Why not? Why can we :p? Seriously, though, your point is well taken. There will= be certain use models predicated on the assumption that endpoints can be trusted. Other use models will not. I still believe that posture is at= best a claim made by the client. It may be factual, but only the use m= odel will determine if those claims need to be validated by another source.= I'm a big fan of doublechecking assumptions when it comes to security,= and a whole lot of historical work ignores this issue. I am too but in some use scenario's it wont be necessary so the use mo= del and its assurance levels will be what constrains and provides this inf= o. Agreed. That problem, however, is not what I envision the NEA protocols solvin= g. I agree with you 100% that this information is important, but I believe = it is outside the charter for NEA. Again - "I envision solving" is a statement that "your vision is diffe= rent from others" and the reason for that is that there is NO COMMON USE MO= DEL that has been agreed upon... Agreed. In fact, it's painfully obvious now that a use model needs to = be defined. Intervendor security interoperability is the elephant in the room. No actually the issue is in defining Intervendor Functionality across = a common use model... again its the USE MODEL which is missing here stil= l. The horse is dead, and I'm still riding it :) But it's still not why we're in the room :) Take care, Rob ----- Original Message ----- From: Leif Johansson To: Robert Bird Cc: nea@ietf.org Sent: Monday, July 23, 2007 7:10:16 PM GMT-0500 US/Eastern Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr Robert Bird wrote: > My instinct is that if an IDS provides NEA client functionality, the= n > it should not be considered part of the IDS itself. If an IDS is > acting as a collector/validator, that functionality should also be > considered separate from its functionality as an IDS. I believe we'r= e > risking running afoul of complications if we blur these lines. > I still don't understand. Here is the question: An active vulnerabilit= y scanner (eg nessus) running on an IDS server knows things about the client (from doing a scan). How is this information folded into the process of evaluating the posture of the client? Cheers Leif _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea = --1__=07BBF9B1DFC540598f9e8a93df938690918c07BBF9B1DFC54059 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Greetings,

I may have missed something as the NEA work and the CNAC/TNC protocols= are starting to get a little blended in my head, but I was under the i= mpression that we had well-defined use cases for the protocol.

Much of the discussions about IDS or other third parties being able to= terminate a client's connectivity are focused on post-admission checki= ng rather than pre-admission checking and these two cases are the only = realistic split.

For pre-admission, I believe the existing discussions are fine and it = has been pointed out that there is nothing precluding the use of an IDS= as a validator that provides an admission decision to the server.

For post-admission I am not convinced we need to give an external enti= ty the ability to initiate a conversation with the NEA components. All = current definitions allow the validator or the client to perform period= ic or triggered revalidations and terminate the connection if non-compl= iant state is found. This gives the collectors and validators the freed= om to do whatever post-admission checking they desire.

Now for post-admission decisions coming from say and IDS server, the i= mplication is that the IDS server reaches a decision as to the non-comp= liant state of a client independently of the NEA protocols. There is th= en nothing to preclude such an IDS server from terminating the client's= connectiovity using a RADIUS command to the network device. While, thi= s is how the CNAC and TNC servers communicate with the network devices,= they do not have a monopoly on this.

For my money, I would want the IDS operating independently from the NE= A stuff. Tighter integration leads to tainting. If you want the IDS to = be a watchdog, do not associate it with the protocol, make it a complet= ely independent observer with the ability to cut off a client's access = independent of NEA. Now what I might see as viable would be a way for t= he IDS to perform a second check while the client is in "quarantin= e" so that it can validate that the non-compliant state that it de= tected in the first place has been remediated. This is why I favor the = IDS as an actual validator on the server side of the NEA protocol, talk= ing to the NEA server as all validators do. This would allow the IDS to= be a part of the pre-admission decision and to terminate a client's ac= cess post-admission, and to independently reinitiate a revalidation of = the client. All of this would operate within the current definitions of= the procotol.


Regards,
Frank Yeh
Sr. Security & Privacy Integration Architect
IBM Global Technology Services
Security & Privacy Technology Integration Team

Second Life: Yehoo Newall

3D"Inactive"todd glassey&= quot; <tglassey@earthlink.net>


=
          "todd glassey" <tglassey@earthlink= .net>

          07/24/2007 08:37 AM

 =
3D=
To
3D""
"Robert Bird" <rbird@redlambda.com>
3D=
cc
3D""
nea@ietf.org
3D=
Subject
3D""
Re: [Nea] 03 comments - IDS as Posture Collecotr
3D=3D""

Robert - I also to illustrate also that = MANY of the existing IETF Protocols suffer from this 'gerrymandering se= t of functionalities' in trying to meet the desires of the committee th= at is working on them at any given instant. What this means is that the= functionality of the Standard's or proposed Standards is a moving targ= et and that is what needs to be nailed down in my opinion... (humble or= otherwise).

What NEA needs to have is a set of pre-defined specific use and functio= nality models which will define the specific features and constraints f= or each of those end-use models. It will also allow Auditor's to use NE= A models more readily which will be a key value to the Industry in impl= ementing the IETF's vision and guidance from this WG as to its use.

2 more cents.

Todd
----- Original Message -----
From: Robe= rt Bird
To: tod= d glassey
Cc: nea@ietf.org<= /font> ; Leif Johansson=
Sent: Tuesday, July 24,= 2007 8:36 AM
Subject: Re: [Nea] 03 c= omments - IDS as Posture Collector

Todd, thanks for the clarity regarding "use model= "...we are in agreement on this issue. Other comments inline.

----- Original Message -----
From: todd glassey <tglassey@earthlink.net>
To: Robert Bird <rbird@redlambda.com>, Leif Johansson <leifj@it.su.se= >
Cc: nea@ietf.org
Sent: Tuesday, July 24, 2007 11:12:53 AM GMT-0500 US/Eastern
Subject: Re: [Nea] 03 comments - IDS as Posture Collector

Robert - I agree with you about most of= your posting - but for the purpose of this mailing let me play the Dev= il's Advocate here...
----- Original Message -----
From: Robert Bird
To: Leif Johansson
Cc: nea@ietf.org
Sent: Monday, July 23, = 2007 5:04 PM
Subject: Re: [Nea] 03 c= omments - IDS as Posture Collector

You raise an interesting point. In that situation,

Robert - you mean "in that specific= use model"... right?

Yes. Specifically, the use model that he was referring to: leveraging v= ulnerability assessment and/or IDS information to double check posture = claims.

where you have combined an IDS with vulnerability asse= ssment, we would love to have that information correlated with the info= rmation collected from the endpoint. Why? Because we cannot safely assu= me that the endpoint can be trusted.

Why not?

Why can we :p? Seriously, though, your point is well taken. There will = be certain use models predicated on the assumption that endpoints can b= e trusted. Other use models will not. I still believe that posture is a= t best a claim made by the client. It may be factual, but only the use = model will determine if those claims need to be validated by another so= urce.


I'm a big fan of doublechecking assumptions when it co= mes to security, and a whole lot of historical work ignores this issue.=

I am too but in some use scenario's it w= ont be necessary so the use model and its assurance levels will be what= constrains and provides this info.

Agreed.


That problem, however, is not what I envision the NEA protocols solving= . I agree with you 100% that this information is important, but I belie= ve it is outside the charter for NEA.


Again - "I envision solving" i= s a statement that "your vision is different from others" and= the reason for that is that there is NO COMMON USE MODEL that has been= agreed upon...

Agreed. In fact, it's painfully obvious now that a use model needs to b= e defined.


Intervendor security interoperability is the elephant in the room.

No actually the issue is in defining Int= ervendor Functionality across a common use model... again its the USE M= ODEL which is missing here still.

The horse is dead, and I'm still riding it :)


But it's still not why we're in the room :)
Take care,
Rob

----- Original Message -----
From: Leif Johansson <leifj@it.su.se>
To: Robert Bird <rbird@redlambda.com>
Cc: nea@ietf.org
Sent: Monday, July 23, 2007 7:10:16 PM GMT-0500 US/Eastern
Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr

Robert Bird wrote:
> My instinct is that if an IDS provides NEA client functionality, t= hen
> it should not be considered part of the IDS itself. If an IDS is > acting as a collector/validator, that functionality should also be=
> considered separate from its functionality as an IDS. I believe we= 're
> risking running afoul of complications if we blur these lines.
= >
I still don't understand. Here is the question: An active vulnerability=
scanner (eg nessus)
running on an IDS server knows things about the client (from doing a scan). How is this
information folded into the process of evaluating the posture of the cl= ient?

Cheers Leif

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

= --1__=07BBF9B1DFC540598f9e8a93df938690918c07BBF9B1DFC54059-- --0__=07BBF9B1DFC540598f9e8a93df938690918c07BBF9B1DFC54059 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=07BBF9B1DFC540598f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=07BBF9B1DFC540598f9e8a93df938690918c07BBF9B1DFC54059 Content-type: image/gif; name="pic11839.gif" Content-Disposition: inline; filename="pic11839.gif" Content-ID: <2__=07BBF9B1DFC540598f9e8a93df938@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__=07BBF9B1DFC540598f9e8a93df938690918c07BBF9B1DFC54059 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <3__=07BBF9B1DFC540598f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=07BBF9B1DFC540598f9e8a93df938690918c07BBF9B1DFC54059-- --===============0173874596== 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 --===============0173874596==-- From nea-bounces@ietf.org Tue Jul 24 12:25:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDNCT-0003Gg-Rp; Tue, 24 Jul 2007 12:25:29 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IDNCS-0003GL-Li for nea-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 12:25:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDNCS-0003GB-9F for nea@ietf.org; Tue, 24 Jul 2007 12:25:28 -0400 Received: from smtp3.su.se ([130.237.93.228]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDNCR-0007pE-Mt for nea@ietf.org; Tue, 24 Jul 2007 12:25:28 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 76C123BE7F; Tue, 24 Jul 2007 18:25:26 +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 19448-01-17; Tue, 24 Jul 2007 18:25:26 +0200 (CEST) Received: from [130.129.18.102] (dhcp-1266.ietf69.org [130.129.18.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id CCA253BE79; Tue, 24 Jul 2007 18:25:24 +0200 (CEST) Message-ID: <46A627FC.6030004@it.su.se> Date: Tue, 24 Jul 2007 18:25:32 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Alan DeKok Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr References: <46A60DAC.7020202@deployingradius.com> <006101c7ce04$3ab91e70$174f7d40@home.glassey.com> <46A61D7B.5060808@deployingradius.com> In-Reply-To: <46A61D7B.5060808@deployingradius.com> X-Enigmail-Version: 0.94.2.0 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.903 tagged_above=-99 required=7 tests=[AWL=0.409, BAYES_00=-2.312] X-Spam-Level: X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: nea@ietf.org, Paul Sangster X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 wrote: > todd glassey wrote: > >> Alan - and Frank - the key issue is in creating a USE MODEL for the >> actual NEA package and its components which performs the collection and >> dissemination processes. Without these end-user guidance models we wont >> know what functions are critical and what are not. >> > > The requirements document does a good job of describing many use > models. The discussion here is about additional use models that should > be permitted under NEA. Those additional use models are being deployed > *now* using existing protocols, precisely because administrators see > those functions as being critical. > Yes! Exactly. As a network manager I worry that my existing solution for admissions control won't be able to coexist with a deployed NEA framework which I'm pretty sure I will have since (for instance) I also deploy commercial anti-virus software. > My proposal is that the NEA WG recognize that other use models exist, > and that those use models should not be prevented by the NEA design. I > do NOT want to spend time standardizing them in NEA, as I see them as > being out of scope of the charter. We should concentrate on endpoints, > rather than additional posture collection points. > I'm fine with this allowing for individual work which provides alternative profiles of NEA (using the word profile very loosly here). Cheers Leif _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Jul 24 14:14:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDOtu-00083B-4V; Tue, 24 Jul 2007 14:14:26 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IDOts-0007n7-L4 for nea-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 14:14:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDOts-0007im-63 for nea@ietf.org; Tue, 24 Jul 2007 14:14:24 -0400 Received: from elasmtp-galgo.atl.sa.earthlink.net ([209.86.89.61]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDOtq-0007Xd-Jh for nea@ietf.org; Tue, 24 Jul 2007 14:14:24 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=mEpvlvIywOSqi1nG0bwLNTJ8i+ebcmSV5AJuirguBXaZ2BowSgrGjFnJKr7aer7E; 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 [64.125.79.23] (helo=gw) by elasmtp-galgo.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IDOtn-0002cM-Rp; Tue, 24 Jul 2007 14:14:20 -0400 Message-ID: <016c01c7ce1e$82b0bcf0$174f7d40@home.glassey.com> From: "todd glassey" To: "Leif Johansson" , "Alan DeKok" References: <46A60DAC.7020202@deployingradius.com> <006101c7ce04$3ab91e70$174f7d40@home.glassey.com> <46A61D7B.5060808@deployingradius.com> <46A627FC.6030004@it.su.se> Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr Date: Tue, 24 Jul 2007 11:14:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79f12d358de72605a1d99f116a6126ec73350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.125.79.23 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: nea@ietf.org, Paul Sangster X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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: "Leif Johansson" To: "Alan DeKok" Cc: "todd glassey" ; ; "Paul Sangster" Sent: Tuesday, July 24, 2007 9:25 AM Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr > Alan DeKok wrote: >> todd glassey wrote: >> >>> Alan - and Frank - the key issue is in creating a USE MODEL for the >>> actual NEA package and its components which performs the collection and >>> dissemination processes. Without these end-user guidance models we wont >>> know what functions are critical and what are not. >>> >> >> The requirements document does a good job of describing many use >> models. The discussion here is about additional use models that should >> be permitted under NEA. Those additional use models are being deployed >> *now* using existing protocols, precisely because administrators see >> those functions as being critical. >> > Yes! Exactly. As a network manager I worry that my existing > solution for admissions control won't be able to coexist with > a deployed NEA framework which I'm pretty sure I will have > since (for instance) I also deploy commercial anti-virus software. >> My proposal is that the NEA WG recognize that other use models exist, >> and that those use models should not be prevented by the NEA design. I >> do NOT want to spend time standardizing them in NEA, as I see them as >> being out of scope of the charter. We should concentrate on endpoints, >> rather than additional posture collection points. >> > I'm fine with this allowing for individual work which provides > alternative profiles of NEA (using the word profile very loosly > here). I am not per se. NEA functionality is NOT something that should be left to anyone to make ad-hoc changes to and still be able to claim compliance to the NEA standards. Likewise the use models need to be tied to compliance processes either in Network Security or Platform/Device Integtrity Management directly IMHO. T > > Cheers Leif _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Jul 24 14:39:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDPIB-00050U-3u; Tue, 24 Jul 2007 14:39:31 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IDPIA-00050P-Do for nea-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 14:39:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDPIA-00050F-1o for nea@ietf.org; Tue, 24 Jul 2007 14:39:30 -0400 Received: from www.deployingradius.com ([216.240.42.17] helo=deployingradius.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDPI9-0003NC-Ea for nea@ietf.org; Tue, 24 Jul 2007 14:39:29 -0400 Received: from [130.129.16.75] (dhcp-104b.ietf69.org [130.129.16.75]) by deployingradius.com (Postfix) with ESMTP id BEFC4A7161; Tue, 24 Jul 2007 11:39:24 -0700 (PDT) Message-ID: <46A6475A.7050900@deployingradius.com> Date: Tue, 24 Jul 2007 14:39:22 -0400 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Frank Yeh Jr Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr References: In-Reply-To: X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Frank Yeh Jr wrote: > For pre-admission, I believe the existing discussions are fine and it > has been pointed out that there is nothing precluding the use of an IDS > as a validator that provides an admission decision to the server. I'm not sure how an IDS provides information about an endpoint that doesn't yet have network access... but OK. > For post-admission I am not convinced we need to give an external entity > the ability to initiate a conversation with the NEA components. They will be in the same network. They will have the capability to communicate. We can't pretend otherwise. > Now for post-admission decisions coming from say and IDS server, the > implication is that the IDS server reaches a decision as to the > non-compliant state of a client independently of the NEA protocols. Yes. This is what people do today. The IDS may determine that the device is not compliant to IDS policy. The user on an NEA-compliant endpoint can still run software unknown to NEA that attacks the network. The IDS can detect this. Existing application servers can detect things like "3 failed login attempts", and inform the administrator. > For my money, I would want the IDS operating independently from the NEA > stuff. Tighter integration leads to tainting. If you want the IDS to be > a watchdog, do not associate it with the protocol, make it a completely > independent observer with the ability to cut off a client's access > independent of NEA. How? NEA is already defined to be able to trigger re-assessment, and to block / filter user traffic. Why would the IDS (or other) not use that functionality? Again, this is not to make IDS a core component of NEA. But we can't realistically pretend that administrators won't integrate the two. Alan DeKok. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Jul 24 14:49:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDPS9-0003tX-KU; Tue, 24 Jul 2007 14:49:49 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IDPS8-0003tO-64 for nea-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 14:49:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDPS7-0003tG-Sa for nea@ietf.org; Tue, 24 Jul 2007 14:49:47 -0400 Received: from www.deployingradius.com ([216.240.42.17] helo=deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDPS6-0008OK-R2 for nea@ietf.org; Tue, 24 Jul 2007 14:49:47 -0400 Received: from [130.129.16.75] (dhcp-104b.ietf69.org [130.129.16.75]) by deployingradius.com (Postfix) with ESMTP id 82EB3A7161; Tue, 24 Jul 2007 11:49:42 -0700 (PDT) Message-ID: <46A649C4.20808@deployingradius.com> Date: Tue, 24 Jul 2007 14:49:40 -0400 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Todd Glassey Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr References: <8823488.1185293066599.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> In-Reply-To: <8823488.1185293066599.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: nea@ietf.org, Paul Sangster X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Todd Glassey wrote: > The point is that each USE MODEL has its own constraints and that is what is not defined. Also defining a "USE MODEL" is not just illustrating a potential use, but rather building a flow and protocol for that use's operations and that is totally missing from the work now IMHO. The existing requirements document has (relatively) clear descriptions of use models. If those aren't clear, there are many examples. > Not really - the discussion here is whether the undocumented uses existing today should be expanded to meet more 'ideas of how to use NEA'... Thank you for correcting me about the point I was trying to make. >> My proposal is that the NEA WG recognize that other use models exist, >> and that those use models should not be prevented by the NEA design. > > This MAY OR MAY NOT make severe changes in the underlying functionality of the NEA suite. That's the problem too - some of the new uses may be contraindicated from those already established. I MAY OR MAY NOT have something bad happen to me. Talking about anything that MAY OR MAY NOT happen means you can avoid talking about the message I was trying to communicate: NEA interaction with IDS is out of scope. We should not design NEA to require an IDS. We should not design NEA to require interaction with an IDS. We MAY design NEA to be capable of interacting with an IDS. I was sure I had said that already. >> I >> do NOT want to spend time standardizing them in NEA, as I see them as >> being out of scope of the charter. We should concentrate on endpoints, >> rather than additional posture collection points. > > This is the basic flaw in much of the IETF's operations - the "We want to build something that is everything to everyone" mindset and its what screws up most of these initiatives. The Functionality of NEA is a key part of what NEA is and does, and its that it seems you want to expand. Hmm... I say I want to concentrate on charter activities, and you conclude that I want to expand the scope of NEA. Playing devils advocate is one thing. Inventing straw men is another. > I would put it that this expansion requires a new use model What expansion? I pointedly said I didn't want one. I said I didn't want to spend much time discussing out of charter activities. Therefore, my best approach is to ignore the FUD around IDS. Alan DeKok. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Jul 24 15:05:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDPhm-0001k2-PN; Tue, 24 Jul 2007 15:05:58 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IDPhl-0001ju-3r for nea-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 15:05:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDPhk-0001jk-QK for nea@ietf.org; Tue, 24 Jul 2007 15:05:56 -0400 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDPhj-0000HU-Bm for nea@ietf.org; Tue, 24 Jul 2007 15:05:56 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 7470A3BEFF; Tue, 24 Jul 2007 21:05:54 +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 27863-02-14; Tue, 24 Jul 2007 21:05:54 +0200 (CEST) Received: from [130.129.18.102] (dhcp-1266.ietf69.org [130.129.18.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 40C3C3BE5F; Tue, 24 Jul 2007 21:05:53 +0200 (CEST) Message-ID: <46A64D93.8080104@it.su.se> Date: Tue, 24 Jul 2007 21:05:55 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Alan DeKok Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr References: <8823488.1185293066599.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> <46A649C4.20808@deployingradius.com> In-Reply-To: <46A649C4.20808@deployingradius.com> X-Enigmail-Version: 0.94.2.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at smtp.su.se X-Spam-Status: No, hits=-1.908 tagged_above=-99 required=7 tests=[AWL=0.404, BAYES_00=-2.312] X-Spam-Level: X-Spam-Score: -4.0 (----) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: nea@ietf.org, Paul Sangster X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 would put it that this expansion requires a new use model >> > > What expansion? I pointedly said I didn't want one. I said I didn't > want to spend much time discussing out of charter activities. > > Therefore, my best approach is to ignore the FUD around IDS. > > I think the impact on the model is minor to negligible but I concede I could be wrong on that point and that consensus doesn't seem clearly in favor of my suggestion. However in that case I do claim that the acronym "IDS" should _not_ occur in the draft since it is clearly misleading. Cheers Leif _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Jul 24 15:11:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDPnG-0006Gh-G7; Tue, 24 Jul 2007 15:11:38 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IDPnE-0006GZ-Q5 for nea-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 15:11:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDPnE-0006GN-DW for nea@ietf.org; Tue, 24 Jul 2007 15:11:36 -0400 Received: from smtpa.juniper.net ([207.17.137.120]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDPnD-00043e-Qb for nea@ietf.org; Tue, 24 Jul 2007 15:11:36 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpa.juniper.net with ESMTP; 24 Jul 2007 12:11:35 -0700 X-IronPort-AV: i="4.16,575,1175497200"; d="scan'208"; a="42920950:sNHT50859568" 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] 03 comments - IDS as Posture Collecotr Date: Tue, 24 Jul 2007 15:11:39 -0400 Message-ID: In-Reply-To: <46A649C4.20808@deployingradius.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] 03 comments - IDS as Posture Collecotr Thread-Index: AcfOI3VdIfV/L+f4SqC6RUHV8H6VoQAAGlnA References: <8823488.1185293066599.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> <46A649C4.20808@deployingradius.com> From: "Stephen Hanna" To: "Alan DeKok" , "Todd Glassey" X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: nea@ietf.org, Paul Sangster X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Let me step in here with my WG Chair hat on. Having the NEA Server consult with an IDS is not in scope for the NEA WG at the current time. Our job is to agree on protocols for assessing endpoint posture. Monitoring endpoint behavior via an IDS and integrating that with a NEA Server may be a very good thing but it is not in scope for the NEA WG. Thanks, Steve -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com]=20 Sent: Tuesday, July 24, 2007 1:50 PM To: Todd Glassey Cc: nea@ietf.org; Paul Sangster Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr Todd Glassey wrote: > The point is that each USE MODEL has its own constraints and that is what is not defined. Also defining a "USE MODEL" is not just illustrating a potential use, but rather building a flow and protocol for that use's operations and that is totally missing from the work now IMHO. The existing requirements document has (relatively) clear descriptions of use models. If those aren't clear, there are many examples. > Not really - the discussion here is whether the undocumented uses existing today should be expanded to meet more 'ideas of how to use NEA'... Thank you for correcting me about the point I was trying to make. >> My proposal is that the NEA WG recognize that other use models exist, >> and that those use models should not be prevented by the NEA design. >=20 > This MAY OR MAY NOT make severe changes in the underlying functionality of the NEA suite. That's the problem too - some of the new uses may be contraindicated from those already established.=20 I MAY OR MAY NOT have something bad happen to me. Talking about anything that MAY OR MAY NOT happen means you can avoid talking about the message I was trying to communicate: NEA interaction with IDS is out of scope. We should not design NEA to require an IDS. We should not design NEA to require interaction with an IDS. We MAY design NEA to be capable of interacting with an IDS. I was sure I had said that already. >> I >> do NOT want to spend time standardizing them in NEA, as I see them as >> being out of scope of the charter. We should concentrate on endpoints, >> rather than additional posture collection points. >=20 > This is the basic flaw in much of the IETF's operations - the "We want to build something that is everything to everyone" mindset and its what screws up most of these initiatives. The Functionality of NEA is a key part of what NEA is and does, and its that it seems you want to expand. Hmm... I say I want to concentrate on charter activities, and you conclude that I want to expand the scope of NEA. Playing devils advocate is one thing. Inventing straw men is another. > I would put it that this expansion requires a new use model=20 What expansion? I pointedly said I didn't want one. I said I didn't want to spend much time discussing out of charter activities. Therefore, my best approach is to ignore the FUD around IDS. Alan DeKok. _______________________________________________ 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 Jul 24 15:17:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDPt1-00027Q-Ax; Tue, 24 Jul 2007 15:17:35 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IDPsz-00026q-J0 for nea-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 15:17:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDPsz-00026g-8J for nea@ietf.org; Tue, 24 Jul 2007 15:17:33 -0400 Received: from smtp3.su.se ([130.237.93.228]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDPsy-0004E1-Qn for nea@ietf.org; Tue, 24 Jul 2007 15:17:33 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 886B03BF30; Tue, 24 Jul 2007 21:17: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 27863-02-36; Tue, 24 Jul 2007 21:17:31 +0200 (CEST) Received: from [130.129.18.102] (dhcp-1266.ietf69.org [130.129.18.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 135603BE5F; Tue, 24 Jul 2007 21:17:24 +0200 (CEST) Message-ID: <46A6504C.5080009@it.su.se> Date: Tue, 24 Jul 2007 21:17:32 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Stephen Hanna Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr References: <8823488.1185293066599.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> <46A649C4.20808@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.94.2.0 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.909 tagged_above=-99 required=7 tests=[AWL=0.403, BAYES_00=-2.312] X-Spam-Level: X-Spam-Score: -4.0 (----) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Paul Sangster , 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 Stephen Hanna wrote: > Let me step in here with my WG Chair hat on. > > Having the NEA Server consult with an IDS is not > in scope for the NEA WG at the current time. > Our job is to agree on protocols for assessing > endpoint posture. Monitoring endpoint behavior > via an IDS and integrating that with a NEA Server > may be a very good thing but it is not in scope > for the NEA WG. > Good clarification. That seems to imply we need to update 03 to remove references to "IDS" to avoid confusion. Cheers Leif _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Jul 24 15:21:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDPx4-0006g1-A3; Tue, 24 Jul 2007 15:21:46 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IDPx2-0006fs-Mq for nea-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 15:21:44 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDPx2-0006ff-AY for nea@ietf.org; Tue, 24 Jul 2007 15:21:44 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDPx1-0004Nd-Sa for nea@ietf.org; Tue, 24 Jul 2007 15:21:44 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 24 Jul 2007 12:21:43 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAIPtpUarR7PE/2dsb2JhbAA X-IronPort-AV: i="4.16,575,1175497200"; d="scan'208"; a="10232724:sNHT15136992" 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/8.12.11) with ESMTP id l6OJLhvw032101; Tue, 24 Jul 2007 12:21:43 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l6OJLgA0000990; Tue, 24 Jul 2007 19:21:42 GMT Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 12:21:42 -0700 Received: from 10.21.68.73 ([10.21.68.73]) by xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) with Microsoft Exchange Server HTTP-DAV ; Tue, 24 Jul 2007 19:21:42 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Tue, 24 Jul 2007 12:21:40 -0700 Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr From: Kaushik Narayan To: Leif Johansson , Alan DeKok Message-ID: Thread-Topic: [Nea] 03 comments - IDS as Posture Collecotr Thread-Index: AcfOJ9xkGzPFezobEdyWpAAX8tamGQ== In-Reply-To: <46A627FC.6030004@it.su.se> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 24 Jul 2007 19:21:42.0482 (UTC) FILETIME=[DDDFB320:01C7CE27] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=979; t=1185304903; x=1186168903; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kaushik@cisco.com; z=From:=20Kaushik=20Narayan=20 |Subject:=20Re=3A=20[Nea]=2003=20comments=20-=20IDS=20as=20Posture=20Coll ecotr |Sender:=20; bh=QY4YE/lHeISP7F/dOFC1jvddccpQHOMitv83OaJh5ok=; b=tvzha2mDVFgsY9i4BlAeDt403ZEWtDiQoc2UeRM6fCOpo/X+QgaLty1Dg0qqYPpLQZtevopU xwQuMoRYoC1qi8oaMcbtXfFxFEMOO46fUpD3dDjJHrKM/AKhz7Tv+aam; Authentication-Results: sj-dkim-4; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: nea@ietf.org, Paul Sangster X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 Leif, Please my reply inline. > Yes! Exactly. As a network manager I worry that my existing > solution for admissions control won't be able to coexist with > a deployed NEA framework which I'm pretty sure I will have > since (for instance) I also deploy commercial anti-virus software. >> I don't think that the NEA framework makes co-existence difficult. The integration of additional sources of endpoint posture (other than the endpoint itself) can be achieved completely within the realm of NEA server and does not require any interaction between NEA client and NEA server which is the scope of the NEA protocols. There are a variety of implementation specific mechanisms which range from standard attribute assertion protocols such as SAML to specific interfaces such as web services that can be used by the NEA server implementations to acquire endpoint posture attributes from systems such as IDS systems. regards, kaushik _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Jul 24 15:33:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDQ8T-0007CG-Tf; Tue, 24 Jul 2007 15:33:33 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IDQ8T-0007CB-6L for nea-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 15:33:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDQ8S-0007C2-Qy for nea@ietf.org; Tue, 24 Jul 2007 15:33:32 -0400 Received: from elasmtp-kukur.atl.sa.earthlink.net ([209.86.89.65]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDQ8S-0004ka-3C for nea@ietf.org; Tue, 24 Jul 2007 15:33:32 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=hBj+l52JQbX28V4A94rBgo6XqV/MLl1hBHtQyqWZB1UkSVg5tNtGW342TKjWVL07; 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 [64.125.79.23] (helo=gw) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IDQ8Q-0005FV-RB; Tue, 24 Jul 2007 15:33:31 -0400 Message-ID: <019101c7ce29$9294e140$174f7d40@home.glassey.com> From: "todd glassey" To: "Stephen Hanna" , "Alan DeKok" References: <8823488.1185293066599.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> <46A649C4.20808@deployingradius.com> Subject: Re: [Nea] 03 comments - IDS as Posture Collector Date: Tue, 24 Jul 2007 12:32:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec793b10e1a6fa1b8ac53d7dbc8426d74193350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.125.79.23 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: nea@ietf.org, Paul Sangster X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 - let me ask - If the device is an appliance and not an OS based instance, this may change I would think, any thoughts on this? Also for some more detail how does this apply to devices like the new 'network co-processors' that integrate the Stack, Stream Head, and TLI for instance into a silicon device? It would be totally reasonable for a SNORT type stack-enhancement to one of these to be queried by NEA prior to a connection's establishment, but for OS based systems, I agree with you totally. Todd ----- Original Message ----- From: "Stephen Hanna" To: "Alan DeKok" ; "Todd Glassey" Cc: ; "Paul Sangster" Sent: Tuesday, July 24, 2007 12:11 PM Subject: RE: [Nea] 03 comments - IDS as Posture Collecotr Let me step in here with my WG Chair hat on. Having the NEA Server consult with an IDS is not in scope for the NEA WG at the current time. Our job is to agree on protocols for assessing endpoint posture. Monitoring endpoint behavior via an IDS and integrating that with a NEA Server may be a very good thing but it is not in scope for the NEA WG. Thanks, Steve -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com] Sent: Tuesday, July 24, 2007 1:50 PM To: Todd Glassey Cc: nea@ietf.org; Paul Sangster Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr Todd Glassey wrote: > The point is that each USE MODEL has its own constraints and that is what is not defined. Also defining a "USE MODEL" is not just illustrating a potential use, but rather building a flow and protocol for that use's operations and that is totally missing from the work now IMHO. The existing requirements document has (relatively) clear descriptions of use models. If those aren't clear, there are many examples. > Not really - the discussion here is whether the undocumented uses existing today should be expanded to meet more 'ideas of how to use NEA'... Thank you for correcting me about the point I was trying to make. >> My proposal is that the NEA WG recognize that other use models exist, >> and that those use models should not be prevented by the NEA design. > > This MAY OR MAY NOT make severe changes in the underlying functionality of the NEA suite. That's the problem too - some of the new uses may be contraindicated from those already established. I MAY OR MAY NOT have something bad happen to me. Talking about anything that MAY OR MAY NOT happen means you can avoid talking about the message I was trying to communicate: NEA interaction with IDS is out of scope. We should not design NEA to require an IDS. We should not design NEA to require interaction with an IDS. We MAY design NEA to be capable of interacting with an IDS. I was sure I had said that already. >> I >> do NOT want to spend time standardizing them in NEA, as I see them as >> being out of scope of the charter. We should concentrate on endpoints, >> rather than additional posture collection points. > > This is the basic flaw in much of the IETF's operations - the "We want to build something that is everything to everyone" mindset and its what screws up most of these initiatives. The Functionality of NEA is a key part of what NEA is and does, and its that it seems you want to expand. Hmm... I say I want to concentrate on charter activities, and you conclude that I want to expand the scope of NEA. Playing devils advocate is one thing. Inventing straw men is another. > I would put it that this expansion requires a new use model What expansion? I pointedly said I didn't want one. I said I didn't want to spend much time discussing out of charter activities. Therefore, my best approach is to ignore the FUD around IDS. Alan DeKok. _______________________________________________ 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 Jul 24 15:45:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDQJj-0006cV-1Y; Tue, 24 Jul 2007 15:45:11 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IDQJi-0006bH-7T for nea-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 15:45:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDQJh-0006b9-Tx for nea@ietf.org; Tue, 24 Jul 2007 15:45:09 -0400 Received: from smtpb.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDQJh-0001LJ-7D for nea@ietf.org; Tue, 24 Jul 2007 15:45:09 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpb.juniper.net with ESMTP; 24 Jul 2007 12:45:08 -0700 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] 03 comments - IDS as Posture Collector Date: Tue, 24 Jul 2007 15:45:13 -0400 Message-ID: In-Reply-To: <019101c7ce29$9294e140$174f7d40@home.glassey.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] 03 comments - IDS as Posture Collector Thread-Index: AcfOKZB9XaOCV4FiSo+Tfs732xyO1QAANpCA References: <8823488.1185293066599.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> <46A649C4.20808@deployingradius.com> <019101c7ce29$9294e140$174f7d40@home.glassey.com> From: "Stephen Hanna" To: "todd glassey" , "Alan DeKok" X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: nea@ietf.org, Paul Sangster X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org If the endpoint does not support NEA protocols, it is not addressed by the current scope of the NEA WG. Some appliances might support the NEA protocols. Some might not. If an endpoint includes a built-in IDS capability whose posture can be reported by a Posture Collector on the NEA Client and queried by the NEA Server as part of the NEA protocol exchange, then that should be OK. My email was primarily referring to network Intrusion Detection Systems. Thanks, Steve -----Original Message----- From: todd glassey [mailto:tglassey@earthlink.net]=20 Sent: Tuesday, July 24, 2007 2:33 PM To: Stephen Hanna; Alan DeKok Cc: nea@ietf.org; Paul Sangster Subject: Re: [Nea] 03 comments - IDS as Posture Collector Steve - let me ask - If the device is an appliance and not an OS based=20 instance, this may change I would think, any thoughts on this? Also for some more detail how does this apply to devices like the new=20 'network co-processors' that integrate the Stack, Stream Head, and TLI for=20 instance into a silicon device? It would be totally reasonable for a SNORT=20 type stack-enhancement to one of these to be queried by NEA prior to a=20 connection's establishment, but for OS based systems, I agree with you=20 totally. Todd ----- Original Message -----=20 From: "Stephen Hanna" To: "Alan DeKok" ; "Todd Glassey"=20 Cc: ; "Paul Sangster" Sent: Tuesday, July 24, 2007 12:11 PM Subject: RE: [Nea] 03 comments - IDS as Posture Collecotr Let me step in here with my WG Chair hat on. Having the NEA Server consult with an IDS is not in scope for the NEA WG at the current time. Our job is to agree on protocols for assessing endpoint posture. Monitoring endpoint behavior via an IDS and integrating that with a NEA Server may be a very good thing but it is not in scope for the NEA WG. Thanks, Steve -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com] Sent: Tuesday, July 24, 2007 1:50 PM To: Todd Glassey Cc: nea@ietf.org; Paul Sangster Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr Todd Glassey wrote: > The point is that each USE MODEL has its own constraints and that is what is not defined. Also defining a "USE MODEL" is not just illustrating a potential use, but rather building a flow and protocol for that use's operations and that is totally missing from the work now IMHO. The existing requirements document has (relatively) clear descriptions of use models. If those aren't clear, there are many examples. > Not really - the discussion here is whether the undocumented uses existing today should be expanded to meet more 'ideas of how to use NEA'... Thank you for correcting me about the point I was trying to make. >> My proposal is that the NEA WG recognize that other use models exist, >> and that those use models should not be prevented by the NEA design. > > This MAY OR MAY NOT make severe changes in the underlying functionality of the NEA suite. That's the problem too - some of the new uses may be contraindicated from those already established. I MAY OR MAY NOT have something bad happen to me. Talking about anything that MAY OR MAY NOT happen means you can avoid talking about the message I was trying to communicate: NEA interaction with IDS is out of scope. We should not design NEA to require an IDS. We should not design NEA to require interaction with an IDS. We MAY design NEA to be capable of interacting with an IDS. I was sure I had said that already. >> I >> do NOT want to spend time standardizing them in NEA, as I see them as >> being out of scope of the charter. We should concentrate on endpoints, >> rather than additional posture collection points. > > This is the basic flaw in much of the IETF's operations - the "We want to build something that is everything to everyone" mindset and its what screws up most of these initiatives. The Functionality of NEA is a key part of what NEA is and does, and its that it seems you want to expand. Hmm... I say I want to concentrate on charter activities, and you conclude that I want to expand the scope of NEA. Playing devils advocate is one thing. Inventing straw men is another. > I would put it that this expansion requires a new use model What expansion? I pointedly said I didn't want one. I said I didn't want to spend much time discussing out of charter activities. Therefore, my best approach is to ignore the FUD around IDS. Alan DeKok. _______________________________________________ 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 Jul 24 15:53:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDQRk-0005dl-6a; Tue, 24 Jul 2007 15:53:28 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IDQRi-0005ZD-5O for nea-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 15:53:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDQRh-0005Z5-Rj for nea@ietf.org; Tue, 24 Jul 2007 15:53:25 -0400 Received: from extu-mxob-2.symantec.com ([216.10.194.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDQRh-0001XI-8t for nea@ietf.org; Tue, 24 Jul 2007 15:53:25 -0400 Received: from tus1opsmtapin02.ges.symantec.com ([192.168.214.44]) by extu-mxob-2.symantec.com with esmtp (Exim 4.66) (envelope-from ) id 1IDQRg-0003PW-Lk; Tue, 24 Jul 2007 12:53:24 -0700 Received: from reserved-155-64-230-19.ges.symantec.com ([155.64.230.19] helo=TUS1XCHECNPIN02.enterprise.veritas.com) by tus1opsmtapin02.ges.symantec.com with esmtp (Exim 4.67) (envelope-from ) id 1IDQRg-0008TO-Cb; Tue, 24 Jul 2007 12:53:24 -0700 Received: from TUS1XCHEVSPIN05.enterprise.veritas.com ([155.64.231.28]) by TUS1XCHECNPIN02.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 12:53:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] 03 comments - IDS as Posture Collecotr Date: Tue, 24 Jul 2007 12:53:23 -0700 Message-ID: In-Reply-To: <46A6504C.5080009@it.su.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] 03 comments - IDS as Posture Collecotr thread-index: AcfOJ0+Ja3FnMYR0QsKo7Ny+PvgPqgAA7zcg References: <8823488.1185293066599.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> <46A649C4.20808@deployingradius.com> <46A6504C.5080009@it.su.se> From: "Paul Sangster" To: "Leif Johansson" , "Stephen Hanna" X-OriginalArrivalTime: 24 Jul 2007 19:53:24.0532 (UTC) FILETIME=[4B957F40:01C7CE2C] X-Brightmail-Verdict: VlJEQwAAAAIAAAABAAAAAAAAAAEAAAAAAAAAA2luYm94AG5lYUBpZXRmLm9yZwBzaGFubmFAanVuaXBlci5uZXQAbGVpZmpAaXQuc3Uuc2UA X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -4.0 (----) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org I'm not trying to continue this thread but would like to see if any changes are needed as a result of this discussion. Clearly this discussion is out of scope for our *current* charter. Leif mentioned removing the mention of IDS. The current spec uses of IDS include: 5.1.1.1 (one in question) which is referring to a host-based IDS ... Its says: "Typical examples include Posture Collectors that provide information about Operating System (OS) patch levels, anti-virus software, and security mechanisms on the endpoint such as host firewall or an Intrusion Detection System (IDS)." I'm ok with dropping the "or an Intrusion Detection System (IDS)" if folks find this confusing. This phrase was not referring to network based IDS which this thread focused upon. 8.1.1 also lists IDS/IPS as an example of an endpoint security mechanism which could be removed without impact if helpful. 8.1.2 is the final mention (also in security consideration) which is the only part which seems relevant to this thread: "Fourth, many networks include infrastructure such as IDS/IPS devices which monitor and take corrective action when suspicious behavior is observed on the network. These devices may have a relationship with the NEA Server which is not within scope for this specification. Devices trusted by the NEA Server to provide security information that might affect the NEA Server's decisions are trusted to operate properly and not cause the NEA Server to make incorrect decisions." Do we need to remove IDS from any other these sections? Paul > -----Original Message----- > From: Leif Johansson [mailto:leifj@it.su.se]=20 > Sent: Tuesday, July 24, 2007 12:18 PM > To: Stephen Hanna > Cc: Paul Sangster; nea@ietf.org > Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr >=20 > Stephen Hanna wrote: > > Let me step in here with my WG Chair hat on. > > > > Having the NEA Server consult with an IDS is not in scope=20 > for the NEA=20 > > WG at the current time. > > Our job is to agree on protocols for assessing endpoint posture.=20 > > Monitoring endpoint behavior via an IDS and integrating that with a=20 > > NEA Server may be a very good thing but it is not in scope=20 > for the NEA=20 > > WG. > > =20 > Good clarification. That seems to imply we need to update 03=20 > to remove references to "IDS" to avoid confusion. >=20 > Cheers Leif >=20 >=20 >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Jul 24 16:02:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDQaa-0003xr-9n; Tue, 24 Jul 2007 16:02:36 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IDQaZ-0003xk-1G for nea-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 16:02:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDQaY-0003xc-Jv for nea@ietf.org; Tue, 24 Jul 2007 16:02:34 -0400 Received: from extu-mxob-1.symantec.com ([216.10.194.28]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDQaX-0005RC-Mx for nea@ietf.org; Tue, 24 Jul 2007 16:02:34 -0400 Received: from tus1opsmtapin02.ges.symantec.com ([192.168.214.44]) by extu-mxob-1.symantec.com with esmtp (Exim 4.66) (envelope-from ) id 1IDQaW-0006In-MR; Tue, 24 Jul 2007 13:02:33 -0700 Received: from reserved-155-64-230-20.ges.symantec.com ([155.64.230.20] helo=TUS1XCHECNPIN03.enterprise.veritas.com) by tus1opsmtapin02.ges.symantec.com with esmtp (Exim 4.67) (envelope-from ) id 1IDQaW-0000ru-Co; Tue, 24 Jul 2007 13:02:32 -0700 Received: from TUS1XCHEVSPIN05.enterprise.veritas.com ([155.64.231.28]) by TUS1XCHECNPIN03.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 13:02: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] 03 comments - IDS as Posture Collector Date: Tue, 24 Jul 2007 13:02:31 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] 03 comments - IDS as Posture Collector thread-index: AcfOKZB9XaOCV4FiSo+Tfs732xyO1QAANpCAAACOU9A= References: <8823488.1185293066599.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> <46A649C4.20808@deployingradius.com> <019101c7ce29$9294e140$174f7d40@home.glassey.com> From: "Paul Sangster" To: "Stephen Hanna" , "todd glassey" , "Alan DeKok" X-OriginalArrivalTime: 24 Jul 2007 20:02:32.0710 (UTC) FILETIME=[9252D260:01C7CE2D] X-Brightmail-Verdict: VlJEQwAAAAIAAAABAAAAAAAAAAEAAAAAAAAABGluYm94AGFsYW5kQGRlcGxveWluZ3JhZGl1cy5jb20AbmVhQGlldGYub3JnAHNoYW5uYUBqdW5pcGVyLm5ldAB0Z2xhc3NleUBlYXJ0aGxpbmsubmV0AA== X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 3fbd9b434023f8abfcb1532abaec7a21 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 > -----Original Message----- > From: Stephen Hanna [mailto:shanna@juniper.net]=20 > Sent: Tuesday, July 24, 2007 12:45 PM > To: todd glassey; Alan DeKok > Cc: nea@ietf.org; Paul Sangster > Subject: RE: [Nea] 03 comments - IDS as Posture Collector >=20 > If the endpoint does not support NEA protocols, it is not=20 > addressed by the current scope of the NEA WG. Some appliances=20 > might support the NEA protocols. Some might not. >=20 > If an endpoint includes a built-in IDS capability whose=20 > posture can be reported by a Posture Collector on the NEA=20 > Client and queried by the NEA Server as part of the NEA=20 > protocol exchange, then that should be OK. My email was=20 > primarily referring to network Intrusion Detection Systems. Just to be extra clear because their has been some confusion about this. This topic is about 3rd parties (such as an network-based IDS/IDP) providing posture for an endpoint instead of a local NEA Client. If an IDS is running on the same system as the NEA Client, there is no problem with the NEA Client reporting the local host-based IDS's posture. This is what section 5.1.1.1 was referring to. >=20 > Thanks, >=20 > Steve >=20 > -----Original Message----- > From: todd glassey [mailto:tglassey@earthlink.net] > Sent: Tuesday, July 24, 2007 2:33 PM > To: Stephen Hanna; Alan DeKok > Cc: nea@ietf.org; Paul Sangster > Subject: Re: [Nea] 03 comments - IDS as Posture Collector >=20 > Steve - let me ask - If the device is an appliance and not an=20 > OS based instance, this may change I would think, any=20 > thoughts on this? >=20 > Also for some more detail how does this apply to devices like=20 > the new 'network co-processors' that integrate the Stack,=20 > Stream Head, and TLI for instance into a silicon device? It=20 > would be totally reasonable for a SNORT type=20 > stack-enhancement to one of these to be queried by NEA prior=20 > to a connection's establishment, but for OS based systems, I=20 > agree with you totally. >=20 > Todd >=20 > ----- Original Message -----=20 > From: "Stephen Hanna" > To: "Alan DeKok" ; "Todd Glassey"=20 > > Cc: ; "Paul Sangster" > Sent: Tuesday, July 24, 2007 12:11 PM > Subject: RE: [Nea] 03 comments - IDS as Posture Collecotr >=20 >=20 > Let me step in here with my WG Chair hat on. >=20 > Having the NEA Server consult with an IDS is not > in scope for the NEA WG at the current time. > Our job is to agree on protocols for assessing > endpoint posture. Monitoring endpoint behavior > via an IDS and integrating that with a NEA Server > may be a very good thing but it is not in scope > for the NEA WG. >=20 > Thanks, >=20 > Steve >=20 > -----Original Message----- > From: Alan DeKok [mailto:aland@deployingradius.com] > Sent: Tuesday, July 24, 2007 1:50 PM > To: Todd Glassey > Cc: nea@ietf.org; Paul Sangster > Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr >=20 > Todd Glassey wrote: > > The point is that each USE MODEL has its own constraints and that is > what is not defined. Also defining a "USE MODEL" is not just > illustrating a potential use, but rather building a flow and protocol > for that use's operations and that is totally missing from=20 > the work now > IMHO. >=20 > The existing requirements document has (relatively) clear=20 > descriptions > of use models. If those aren't clear, there are many examples. >=20 > > Not really - the discussion here is whether the undocumented uses > existing today should be expanded to meet more 'ideas of how to use > NEA'... >=20 > Thank you for correcting me about the point I was trying to make. >=20 > >> My proposal is that the NEA WG recognize that other use models > exist, > >> and that those use models should not be prevented by the=20 > NEA design. >=20 > > > > This MAY OR MAY NOT make severe changes in the underlying > functionality of the NEA suite. That's the problem too - some=20 > of the new > uses may be contraindicated from those already established. >=20 > I MAY OR MAY NOT have something bad happen to me. >=20 > Talking about anything that MAY OR MAY NOT happen means you=20 > can avoid > talking about the message I was trying to communicate: NEA interaction > with IDS is out of scope. We should not design NEA to require an IDS. > We should not design NEA to require interaction with an IDS. We MAY > design NEA to be capable of interacting with an IDS. >=20 > I was sure I had said that already. >=20 > >> I > >> do NOT want to spend time standardizing them in NEA, as I=20 > see them as > >> being out of scope of the charter. We should concentrate on > endpoints, > >> rather than additional posture collection points. > > > > This is the basic flaw in much of the IETF's operations -=20 > the "We want > to build something that is everything to everyone" mindset=20 > and its what > screws up most of these initiatives. The Functionality of NEA is a key > part of what NEA is and does, and its that it seems you want=20 > to expand. >=20 > Hmm... I say I want to concentrate on charter activities, and you > conclude that I want to expand the scope of NEA. >=20 > Playing devils advocate is one thing. Inventing straw men=20 > is another. >=20 > > I would put it that this expansion requires a new use model >=20 > What expansion? I pointedly said I didn't want one. I=20 > said I didn't > want to spend much time discussing out of charter activities. >=20 > Therefore, my best approach is to ignore the FUD around IDS. >=20 > Alan DeKok. >=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 Tue Jul 24 16:43:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDREb-0007fd-Rj; Tue, 24 Jul 2007 16:43:57 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IDREa-0007fW-OU for nea-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 16:43:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDREa-0007fO-CJ for nea@ietf.org; Tue, 24 Jul 2007 16:43:56 -0400 Received: from smtp3.su.se ([130.237.93.228]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDREZ-0006OH-QE for nea@ietf.org; Tue, 24 Jul 2007 16:43:56 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 83B083BF0F; Tue, 24 Jul 2007 22:43:54 +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 30846-02-36; Tue, 24 Jul 2007 22:43:54 +0200 (CEST) Received: from [130.129.18.102] (dhcp-1266.ietf69.org [130.129.18.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 3EEEC3BE7F; Tue, 24 Jul 2007 22:43:52 +0200 (CEST) Message-ID: <46A66490.4000001@it.su.se> Date: Tue, 24 Jul 2007 22:44:00 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Paul Sangster Subject: Re: [Nea] 03 comments - IDS as Posture Collector References: <8823488.1185293066599.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> <46A649C4.20808@deployingradius.com> <019101c7ce29$9294e140$174f7d40@home.glassey.com> In-Reply-To: X-Enigmail-Version: 0.94.2.0 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.912 tagged_above=-99 required=7 tests=[AWL=0.400, BAYES_00=-2.312] X-Spam-Level: X-Spam-Score: -4.0 (----) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 Paul Sangster wrote: > > > >> -----Original Message----- >> From: Stephen Hanna [mailto:shanna@juniper.net] >> Sent: Tuesday, July 24, 2007 12:45 PM >> To: todd glassey; Alan DeKok >> Cc: nea@ietf.org; Paul Sangster >> Subject: RE: [Nea] 03 comments - IDS as Posture Collector >> >> If the endpoint does not support NEA protocols, it is not >> addressed by the current scope of the NEA WG. Some appliances >> might support the NEA protocols. Some might not. >> >> If an endpoint includes a built-in IDS capability whose >> posture can be reported by a Posture Collector on the NEA >> Client and queried by the NEA Server as part of the NEA >> protocol exchange, then that should be OK. My email was >> primarily referring to network Intrusion Detection Systems. >> > > Just to be extra clear because their has been some confusion about this. > This topic is about 3rd parties (such as an network-based IDS/IDP) > providing posture for an endpoint instead of a local NEA Client. > > If an IDS is running on the same system as the NEA Client, there is no > problem with the NEA Client reporting the local host-based IDS's > posture. This is what section 5.1.1.1 was referring to. > > In that case this needs to be cleared up in the text. Cheers Leif _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Jul 24 17:21:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDRp5-0003ag-74; Tue, 24 Jul 2007 17:21:39 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IDRp3-0003ab-W7 for nea-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 17:21:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDRp3-0003aT-MN for nea@ietf.org; Tue, 24 Jul 2007 17:21:37 -0400 Received: from extu-mxob-1.symantec.com ([216.10.194.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDRp3-0003L2-5s for nea@ietf.org; Tue, 24 Jul 2007 17:21:37 -0400 Received: from tus1opsmtapin01.ges.symantec.com ([192.168.214.43]) by extu-mxob-1.symantec.com with esmtp (Exim 4.66) (envelope-from ) id 1IDRp2-0001mX-Ft; Tue, 24 Jul 2007 14:21:36 -0700 Received: from reserved-155-64-230-20.ges.symantec.com ([155.64.230.20] helo=TUS1XCHECNPIN03.enterprise.veritas.com) by tus1opsmtapin01.ges.symantec.com with esmtp (Exim 4.67) (envelope-from ) id 1IDRp2-00011u-0b; Tue, 24 Jul 2007 14:21:36 -0700 Received: from TUS1XCHEVSPIN05.enterprise.veritas.com ([155.64.231.28]) by TUS1XCHECNPIN03.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 14:21:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] 03 comments - IDS as Posture Collector Date: Tue, 24 Jul 2007 14:21:34 -0700 Message-ID: In-Reply-To: <46A66490.4000001@it.su.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] 03 comments - IDS as Posture Collector thread-index: AcfOM11YipjKnuZfTN2FlN/3VEs2oAABQuXg References: <8823488.1185293066599.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> <46A649C4.20808@deployingradius.com> <019101c7ce29$9294e140$174f7d40@home.glassey.com> <46A66490.4000001@it.su.se> From: "Paul Sangster" To: "Leif Johansson" X-OriginalArrivalTime: 24 Jul 2007 21:21:36.0426 (UTC) FILETIME=[9DCC70A0:01C7CE38] X-Brightmail-Verdict: VlJEQwAAAAIAAAABAAAAAAAAAAEAAAAAAAAABWluYm94AGFsYW5kQGRlcGxveWluZ3JhZGl1cy5jb20AbmVhQGlldGYub3JnAHNoYW5uYUBqdW5pcGVyLm5ldAB0Z2xhc3NleUBlYXJ0aGxpbmsubmV0AGxlaWZqQGl0LnN1LnNlAA== X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -4.0 (----) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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 > -----Original Message----- > From: Leif Johansson [mailto:leifj@it.su.se]=20 > Sent: Tuesday, July 24, 2007 1:44 PM > To: Paul Sangster > Cc: Stephen Hanna; todd glassey; Alan DeKok; nea@ietf.org > Subject: Re: [Nea] 03 comments - IDS as Posture Collector >=20 > Paul Sangster wrote: > > =20 > > > > =20 > >> -----Original Message----- > >> From: Stephen Hanna [mailto:shanna@juniper.net] > >> Sent: Tuesday, July 24, 2007 12:45 PM > >> To: todd glassey; Alan DeKok > >> Cc: nea@ietf.org; Paul Sangster > >> Subject: RE: [Nea] 03 comments - IDS as Posture Collector > >> > >> If the endpoint does not support NEA protocols, it is not=20 > addressed=20 > >> by the current scope of the NEA WG. Some appliances might=20 > support the=20 > >> NEA protocols. Some might not. > >> > >> If an endpoint includes a built-in IDS capability whose=20 > posture can=20 > >> be reported by a Posture Collector on the NEA Client and=20 > queried by=20 > >> the NEA Server as part of the NEA protocol exchange, then=20 > that should=20 > >> be OK. My email was primarily referring to network Intrusion=20 > >> Detection Systems. > >> =20 > > > > Just to be extra clear because their has been some=20 > confusion about this. > > This topic is about 3rd parties (such as an network-based IDS/IDP)=20 > > providing posture for an endpoint instead of a local NEA Client. > > > > If an IDS is running on the same system as the NEA Client,=20 > there is no=20 > > problem with the NEA Client reporting the local host-based IDS's=20 > > posture. This is what section 5.1.1.1 was referring to. > > > > =20 > In that case this needs to be cleared up in the text. > =20 Ok, suggest we add this to section 3.1 where we discuss topics which are out of scope. Thanks, Paul > Cheers Leif >=20 >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Jul 24 17:37:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDS4U-0000o1-MN; Tue, 24 Jul 2007 17:37:34 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IDS4U-0000nv-Am for nea-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 17:37:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDS4U-0000nn-0w for nea@ietf.org; Tue, 24 Jul 2007 17:37:34 -0400 Received: from e31.co.us.ibm.com ([32.97.110.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDS4S-0003fI-Rq for nea@ietf.org; Tue, 24 Jul 2007 17:37:34 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e31.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l6OLbWV5026422 for ; Tue, 24 Jul 2007 17:37:32 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.4) with ESMTP id l6OLbVRt064308 for ; Tue, 24 Jul 2007 15:37:31 -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 l6OLbVbx019215 for ; Tue, 24 Jul 2007 15:37:31 -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 l6OLbVIu019206; Tue, 24 Jul 2007 15:37:31 -0600 In-Reply-To: Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr To: Kaushik Narayan X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Frank Yeh Jr Date: Tue, 24 Jul 2007 14:37:12 -0700 X-MIMETrack: Serialize by Router on D03NM129/03/M/IBM(Release 7.0.2HF32 | October 17, 2006) at 07/24/2007 15:37:30 MIME-Version: 1.0 X-Spam-Score: -1.4 (-) X-Scan-Signature: 96e0f8497f38c15fbfc8f6f315bcdecb Cc: Paul Sangster , 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="===============0234256647==" Errors-To: nea-bounces@ietf.org --===============0234256647== Content-type: multipart/related; Boundary="0__=07BBF9B1DFE604148f9e8a93df938690918c07BBF9B1DFE60414" --0__=07BBF9B1DFE604148f9e8a93df938690918c07BBF9B1DFE60414 Content-type: multipart/alternative; Boundary="1__=07BBF9B1DFE604148f9e8a93df938690918c07BBF9B1DFE60414" --1__=07BBF9B1DFE604148f9e8a93df938690918c07BBF9B1DFE60414 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Greetings, Thanks, Kaushik. You seem to be able to say what I am thinking in= less words and with greater clarity_ maybe I can get you to just write = all my posts. ;-) Just to address a couple of disconnected comments: I want to make sure that it is Brutally clear to people that: 1) The protocol does support using a traditional IDS as a Posture Validator. So saying that people will integrate IDS and NEA is a given,= but they already have an interface to do so within the current scope. 2) There might be state about a client known to an IDS before the cl= ient actually tries to connect to the network being defended by NEA. In a reasonably typical scenario, you might have both a "public" network that is not secure and not admission controlled and a "private= " network to which admission is controlled and within which different rul= es apply. A network-attached IDS could be monitoring clients' activities i= n the public space and if a client were to then attempt access to the pri= vate space, a posture validator could query the client for its MAC address a= nd then pass that to the IDS asking if there were any violations detected = for that MAC Address. So if the client had been detected doing illicit activities in the public space, this could be cause for denial of acces= s to the private space. This would be a case where the IDS could be queried = for state of a client that is attempting to conect to "the network" but is = not yet attached to it. Regards, Frank Yeh Sr. Security & Privacy Integration Architect IBM Global Technology Services Security & Privacy Technology Integration Team Second Life: Yehoo Newall = Kaushik Narayan = = To Leif Johansson ,= 07/24/2007 12:21 Alan DeKok = PM = = cc nea@ietf.org, Paul Sangster = = Subj= ect Re: [Nea] 03 comments - IDS as = Posture Collecotr = = = = = = = Hi Leif, Please my reply inline. > Yes! Exactly. As a network manager I worry that my existing > solution for admissions control won't be able to coexist with > a deployed NEA framework which I'm pretty sure I will have > since (for instance) I also deploy commercial anti-virus software. >> I don't think that the NEA framework makes co-existence difficult. The integration of additional sources of endpoint posture (other than the endpoint itself) can be achieved completely within the realm of NEA ser= ver and does not require any interaction between NEA client and NEA server which is the scope of the NEA protocols. There are a variety of implementation specific mechanisms which range f= rom standard attribute assertion protocols such as SAML to specific interfa= ces such as web services that can be used by the NEA server implementations= to acquire endpoint posture attributes from systems such as IDS systems. regards, kaushik _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea = --1__=07BBF9B1DFE604148f9e8a93df938690918c07BBF9B1DFE60414 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Greetings,

Thanks, Kaushik. You seem to be able to say what I am thinking in less= words and with greater clarity_ maybe I can get you to just write all = my posts. ;-)

Just to address a couple of disconnected comments:

I want to make sure that it is Brutally clear to people that:

1) The protocol does support using a traditional IDS as a Posture Valid= ator. So saying that people will integrate IDS and NEA is a given, but = they already have an interface to do so within the current scope.

2) There might be state about a client known to an IDS before the clie= nt actually tries to connect to the network being defended by NEA.

In a reasonably typical scenario, you might have both a "public&q= uot; network that is not secure and not admission controlled and a &qu= ot;private" network to which admission is controlled and within wh= ich different rules apply. A network-attached IDS could be monitoring c= lients' activities in the public space and if a client were to then att= empt access to the private space, a posture validator could query the c= lient for its MAC address and then pass that to the IDS asking if there= were any violations detected for that MAC Address. So if the client ha= d been detected doing illicit activities in the public space, this coul= d be cause for denial of access to the private space. This would be a c= ase where the IDS could be queried for state of a client that is attemp= ting to conect to "the network" but is not yet attached to it= .

Regards,
Frank Yeh
Sr. Security & Privacy Integration Architect
IBM Global Technology Services
Security & Privacy Technology Integration Team

Second Life: Yehoo Newall

3D"InactiveKaushik Narayan <kaushik@cisco= .com>


=
          Kaushik Narayan <kaushik@cisco.com>

          07/24/2007 12:21 PM

 =
3D=
To
3D""
Leif Johansson <leifj@it.su.se>, Alan DeKok <= aland@deployingradius.com>
3D=
cc
3D""
nea@ietf.org, Paul Sangster <Paul_Sangster@symantec= .com>
3D=
Subject
3D""
Re: [Nea] 03 comments - IDS as Posture Collecotr
3D=3D""

Hi Leif,

Please my reply inline.

<snipped>

> Yes! Exactly. As a network manager I worry that my existing
> solution for admissions control won't be able to coexist with
> a deployed NEA framework which I'm pretty sure I will have
> since (for instance) I also deploy commercial anti-virus software.=
>>  

I don't think that the NEA framework makes co-existence difficult. The<= br> integration of additional sources of endpoint posture (other than the endpoint itself) can be achieved completely within the realm of NEA ser= ver
and does not require any interaction between NEA client and NEA server = which
is the scope of the NEA protocols.

There are a variety of implementation specific mechanisms which range f= rom
standard attribute assertion protocols such as SAML to specific interfa= ces
such as web services that can be used by the NEA server implementations= to
acquire endpoint posture attributes from systems such as IDS systems.
regards,
 kaushik



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

= --1__=07BBF9B1DFE604148f9e8a93df938690918c07BBF9B1DFE60414-- --0__=07BBF9B1DFE604148f9e8a93df938690918c07BBF9B1DFE60414 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=07BBF9B1DFE604148f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=07BBF9B1DFE604148f9e8a93df938690918c07BBF9B1DFE60414 Content-type: image/gif; name="pic16753.gif" Content-Disposition: inline; filename="pic16753.gif" Content-ID: <2__=07BBF9B1DFE604148f9e8a93df938@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__=07BBF9B1DFE604148f9e8a93df938690918c07BBF9B1DFE60414 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <3__=07BBF9B1DFE604148f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=07BBF9B1DFE604148f9e8a93df938690918c07BBF9B1DFE60414-- --===============0234256647== 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 --===============0234256647==-- From nea-bounces@ietf.org Tue Jul 24 19:44:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDU3K-0003oy-4l; Tue, 24 Jul 2007 19:44:30 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IDU3I-0003or-RB for nea-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 19:44:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDU3I-0003oe-Fs for nea@ietf.org; Tue, 24 Jul 2007 19:44:28 -0400 Received: from smtp3.su.se ([130.237.93.228]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDU3I-0001Et-2W for nea@ietf.org; Tue, 24 Jul 2007 19:44:28 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 0C5423BF45; Wed, 25 Jul 2007 01:44:27 +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 10768-01-21; Wed, 25 Jul 2007 01:44:26 +0200 (CEST) Received: from [130.129.18.102] (dhcp-1266.ietf69.org [130.129.18.102]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id 297E43BE9C; Wed, 25 Jul 2007 01:44:25 +0200 (CEST) Message-ID: <46A68EE1.2010909@it.su.se> Date: Wed, 25 Jul 2007 01:44:33 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Paul Sangster Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr References: <8823488.1185293066599.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> <46A649C4.20808@deployingradius.com> <46A6504C.5080009@it.su.se> In-Reply-To: X-Enigmail-Version: 0.94.2.0 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.916 tagged_above=-99 required=7 tests=[AWL=0.396, BAYES_00=-2.312] X-Spam-Level: X-Spam-Score: -4.0 (----) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 Paul Sangster wrote: > I'm not trying to continue this thread but would like to see if any > changes are needed as a result of this discussion. Clearly this > discussion is out of scope for our *current* charter. Leif mentioned > removing the mention of IDS. The current spec uses of IDS include: > Maybe you only need to clarify that you are talking about host-based IDS:en rather than network-based IDS:en (which from my background are the "traditional" ones, which may be the source of my confusion about the text). Cheers Leif >> >> _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Jul 25 23:59:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDuVK-0004wl-5H; Wed, 25 Jul 2007 23:59:10 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IDuVI-0004wZ-Gp for nea-confirm+ok@megatron.ietf.org; Wed, 25 Jul 2007 23:59:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDuVH-0004wO-JR for nea@ietf.org; Wed, 25 Jul 2007 23:59:07 -0400 Received: from smtpb.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDuVH-0002t1-8j for nea@ietf.org; Wed, 25 Jul 2007 23:59:07 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpb.juniper.net with ESMTP; 25 Jul 2007 20:59:07 -0700 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 25 Jul 2007 23:59:11 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IETF 69 NEA WG Summary Thread-Index: AcfO2aorBpkLaHrSRn2w+nGWTn03rgAXy+UQAAAVuzA= From: "Stephen Hanna" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Nea] FW: IETF 69 NEA WG Summary X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org For those who couldn't make it to Chicago and don't want to wait for the meeting minutes, here's a quick summary of what happened at the NEA WG meeting this week. Thanks, Steve=20 -----Original Message----- From: Stephen Hanna=20 Sent: Wednesday, July 25, 2007 10:58 PM To: saag@mit.edu Subject: IETF 69 NEA WG Summary The NEA WG met Monday, 23 July 2007, 1-3 PM CDT. The NEA Requirements I-D is in WGLC. Several good comments have been received but more were solicited. Seven new reviewers were signed up. Tim Polk promised to help find more, especially from outside the WG. Kaushik Narayan gave an overview of the current requirements document, including a review of changes since IETF 68 and a review of all the requirements. He raised several open issues for discussion such as whether the requirements document should contain non-normative design guidance. Consensus on these items will be confirmed on the list. One question needs more external input: whether the Privacy Considerations section of the draft is adequate. Tim Polk will help us get input from some privacy experts. Open discussion on the requirements document ensued. Steve Hanna reviewed the next steps for the WG. We'll finish the WGLC on the requirements document and issue a revised I-D. If the changes were major, we'll do another WGLC. When we have WG consensus on the requirements document, we'll submit it to the IESG for IETF LC and eventual publication as Informational. When the document is ready, we'll revise our milestones and begin work on the PA and PB protocols. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea