From nea-bounces@ietf.org Thu Aug 02 05:02: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 1IGWZV-0003DO-Ox; Thu, 02 Aug 2007 05:02:17 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IGWZT-00037c-Pu for nea-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 05:02:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGWZT-00037T-CR for nea@ietf.org; Thu, 02 Aug 2007 05:02:15 -0400 Received: from legolas.restena.lu ([158.64.1.34] helo=smtp.restena.lu) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGWZS-00034i-Qa for nea@ietf.org; Thu, 02 Aug 2007 05:02:15 -0400 Received: from smtp.restena.lu (localhost [127.0.0.1]) by smtp.restena.lu (Postfix) with ESMTP id 101DD3027247; Thu, 2 Aug 2007 11:02:14 +0200 (CEST) Received: from aragorn.restena.lu (aragorn.restena.lu [158.64.1.155]) by smtp.restena.lu (Postfix) with ESMTP id 003443027244; Thu, 2 Aug 2007 11:02:14 +0200 (CEST) From: Stefan Winter Organization: Fondation RESTENA To: nea@ietf.org Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr Date: Thu, 2 Aug 2007 11:02:53 +0200 User-Agent: KMail/1.9.7 References: <46A4FE22.8020808@it.su.se> <46A534B2.9060404@it.su.se> In-Reply-To: <46A534B2.9060404@it.su.se> X-Face: %j?V+uSSM.S0%383/M#=_w?DsL5os9fxa%z-TN:))c[W7~6eK)=2ek5>=?utf-8?q?=5Ed+=3B=5Dk=2EwY4k1ve=0A=092=23=5EC=5EstMo*JDE=3FS2YkN=3At=7E?= =?utf-8?q?Vv=7D?=(exS~'/q+xqA =?utf-8?q?KPf6=7E=5B=3B=0A=09=27=2EB=27=2EDkOdU6gj-r=23ei=7D=23d=60=3B?= =?utf-8?q?B=7C*8awL3HM-=5C=3DR?=>Z<(33?+#W+:Fy)TH&)Q({@ =?utf-8?q?ZBHm=26d8LZ=24=0A=09M/L!033=7CZlf7?=(=d<{]y!'$TmaI\276$)iMlA@A*ZA&q>W5"rsQ)FHGBp) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: 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="===============1390429201==" Errors-To: nea-bounces@ietf.org --===============1390429201== Content-Type: multipart/signed; boundary="nextPart3862606.GIjDxN9xUK"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart3862606.GIjDxN9xUK Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline > > 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. I agree with Leif. Imagine a linux box with an installed RPM which has no=20 known vulnerabilities (NEA reports state is good), but the user installed a= =20 beta version of the next release in /usr/local (or in a VM on the same=20 machine) and is using that one instead of the shipped one. The beta has=20 vulnerabilities and is breached already. An IDS detects the strange behavio= ur=20 while NEA possibly doesn't. That information *is* interesting, IMHO. Stefan Winter =2D-=20 Stefan WINTER Stiftung RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale e= t de=20 la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu =A0 =A0 Tel.: =A0 =A0+352 424409-1 http://www.restena.lu =A0 =A0 =A0 =A0 =A0 =A0 =A0 Fax: =A0 =A0 =A0+352 422= 473 --nextPart3862606.GIjDxN9xUK Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQBGsZ29+jm90f8eFWYRAnn8AJ9Esucq1uiMLauLK89PfbghzwaZYQCfd/Nq uDHiCrmhbqe3X9uFJZ1gnI4= =GuRZ -----END PGP SIGNATURE----- --nextPart3862606.GIjDxN9xUK-- --===============1390429201== 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 --===============1390429201==-- From nea-bounces@ietf.org Thu Aug 02 10:19: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 1IGbWU-0000oZ-K9; Thu, 02 Aug 2007 10:19:30 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IGbWU-0000oU-CL for nea-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 10:19:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGbWU-0000oM-2X for nea@ietf.org; Thu, 02 Aug 2007 10:19:30 -0400 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGbWS-00012W-He for nea@ietf.org; Thu, 02 Aug 2007 10:19:30 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Gf4GWo38Yeag605xnfybqi4jmImZNd0Wz56XGvRlX39BS8Q29kbKV0k0MVSa1xnS; 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 [24.23.176.93] (helo=tsg1) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IGbWR-0005xa-Qe; Thu, 02 Aug 2007 10:19:28 -0400 Message-ID: <002f01c7d510$222b3b00$6501a8c0@tsg1> From: "TS Glassey" To: "Stefan Winter" , References: <46A4FE22.8020808@it.su.se> <46A534B2.9060404@it.su.se> <200708021102.53553.stefan.winter@restena.lu> Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr Date: Thu, 2 Aug 2007 07:19:24 -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: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec7900ba8c728431d6ecbb0041ddc59518a6350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.23.176.93 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: 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 This is then about Configuration Management as well as Integrity? T ----- Original Message ----- From: "Stefan Winter" To: Cc: "Paul Sangster" Sent: Thursday, August 02, 2007 2:02 AM Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea > _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Aug 02 10:25: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 1IGbcC-0002m1-Ki; Thu, 02 Aug 2007 10:25:24 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IGbcB-0002lv-BJ for nea-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 10:25:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGbcB-0002lm-1Z for nea@ietf.org; Thu, 02 Aug 2007 10:25:23 -0400 Received: from an-out-0708.google.com ([209.85.132.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGbc9-00018d-Qm for nea@ietf.org; Thu, 02 Aug 2007 10:25:23 -0400 Received: by an-out-0708.google.com with SMTP id c17so101626anc for ; Thu, 02 Aug 2007 07:25:21 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aSrBCJO0f/GBW1JdHeFWgE7IR8yIFfTfnB0NeHuvT9Vi9mM2lGvbH9cg1BAqaM9zrj8ZGJl49+Fe+h+P93/67kypd83ampMKnnkVKXBeKO9MU19DoOt/ruIB0qPPB0UnPhwVSpmIqGnXxsEQW5xctKQ2qYcZEe0DAPubTLCSij0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=iki2vnL2kdFZNPAVS4M7e5VVKoIxrRHhfpZdD2Of/vPuDGjPCiiMJTzpHCiSJ4PVnODAvgo8rZbcrS8ZDlYX0ZE0v/m3UhUsmtjl2EL1UXTTqbODvXeor2DzDS/BUgH/TPcrqPgEbi7zaNCoHbmBzppjKlG07DKd0gtB+phvog4= Received: by 10.100.195.10 with SMTP id s10mr1112431anf.1186064721103; Thu, 02 Aug 2007 07:25:21 -0700 (PDT) Received: by 10.100.126.12 with HTTP; Thu, 2 Aug 2007 07:25:21 -0700 (PDT) Message-ID: Date: Thu, 2 Aug 2007 10:25:21 -0400 From: "Mike Fratto" To: "TS Glassey" Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr In-Reply-To: <002f01c7d510$222b3b00$6501a8c0@tsg1> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <46A4FE22.8020808@it.su.se> <46A534B2.9060404@it.su.se> <200708021102.53553.stefan.winter@restena.lu> <002f01c7d510$222b3b00$6501a8c0@tsg1> X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 Why not just clarify the language to indicate a "Host Based IDS" instead of "IDS"? Host based stuff is certainly within the charter. There are such beasties on the market and as part of posture validation, can be used in assessments in the same way an anti-virus or patch management product can. Besides, there is nothing to be gained by removing the reference and if removed, leaves a gap that is open to interpretation. On 8/2/07, TS Glassey wrote: > This is then about Configuration Management as well as Integrity? > > T > ----- Original Message ----- > From: "Stefan Winter" > To: > Cc: "Paul Sangster" > Sent: Thursday, August 02, 2007 2:02 AM > Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr > > > > _______________________________________________ > > Nea mailing list > > Nea@ietf.org > > https://www1.ietf.org/mailman/listinfo/nea > > > > > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea > _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Aug 02 10:41: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 1IGbsD-0003VL-5i; Thu, 02 Aug 2007 10:41:57 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IGbsC-0003VE-4C for nea-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 10:41:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGbsB-0003V6-Qy for nea@ietf.org; Thu, 02 Aug 2007 10:41:55 -0400 Received: from elasmtp-mealy.atl.sa.earthlink.net ([209.86.89.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGbsA-0001ZY-Ee for nea@ietf.org; Thu, 02 Aug 2007 10:41:55 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=swIZtaoFhGijPA0saYKfAaaEg+s3ooxnvq5/pWQfo/VcPW4qJwDasdlX4hZBHpw+; 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 [24.23.176.93] (helo=tsg1) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IGbs6-0001nE-G2; Thu, 02 Aug 2007 10:41:50 -0400 Message-ID: <005601c7d513$434bbb40$6501a8c0@tsg1> From: "TS Glassey" To: "Mike Fratto" References: <46A4FE22.8020808@it.su.se> <46A534B2.9060404@it.su.se> <200708021102.53553.stefan.winter@restena.lu> <002f01c7d510$222b3b00$6501a8c0@tsg1> Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr Date: Thu, 2 Aug 2007 07:41:48 -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: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79bb39df6f06c4db1d6979e1ea3bbeddb2350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.23.176.93 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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 Mike - I agree with the idea... conceptually there are two very different things going on here, and one of them is IDS centric and the other isnt, that being the 'footprint' verification functionality of some 'change management/control' service. As to amending the wording, I think NEA will need to do both functions since they are both key aspects of an ongoing Integrity Of Operations constrol set which this clearly is one. Todd ----- Original Message ----- From: "Mike Fratto" To: "TS Glassey" Cc: "Stefan Winter" ; ; "Paul Sangster" Sent: Thursday, August 02, 2007 7:25 AM Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr > Why not just clarify the language to indicate a "Host Based IDS" > instead of "IDS"? > > Host based stuff is certainly within the charter. There are such > beasties on the market and as part of posture validation, can be used > in assessments in the same way an anti-virus or patch management > product can. > > Besides, there is nothing to be gained by removing the reference and > if removed, leaves a gap that is open to interpretation. > > On 8/2/07, TS Glassey wrote: >> This is then about Configuration Management as well as Integrity? >> >> T >> ----- Original Message ----- >> From: "Stefan Winter" >> To: >> Cc: "Paul Sangster" >> Sent: Thursday, August 02, 2007 2:02 AM >> Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr >> >> >> > _______________________________________________ >> > Nea mailing list >> > Nea@ietf.org >> > https://www1.ietf.org/mailman/listinfo/nea >> > >> >> >> _______________________________________________ >> Nea mailing list >> Nea@ietf.org >> https://www1.ietf.org/mailman/listinfo/nea >> _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Aug 02 12:44:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGdme-000204-KB; Thu, 02 Aug 2007 12:44:20 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IGdmc-0001yX-08 for nea-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 12:44:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGdmb-0001yN-MH for nea@ietf.org; Thu, 02 Aug 2007 12:44:17 -0400 Received: from e36.co.us.ibm.com ([32.97.110.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGdmZ-0004xO-Uq for nea@ietf.org; Thu, 02 Aug 2007 12:44:17 -0400 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e36.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l72GiFIQ014736 for ; Thu, 2 Aug 2007 12:44:15 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v8.4) with ESMTP id l72GiFH3259640 for ; Thu, 2 Aug 2007 10:44:15 -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 l72GiEA0003935 for ; Thu, 2 Aug 2007 10:44:15 -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 l72GiD6V003896; Thu, 2 Aug 2007 10:44:14 -0600 In-Reply-To: <005601c7d513$434bbb40$6501a8c0@tsg1> Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr To: "TS Glassey" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Frank Yeh Jr Date: Thu, 2 Aug 2007 09:44:03 -0700 X-MIMETrack: Serialize by Router on D03NM129/03/M/IBM(Release 7.0.2HF32 | October 17, 2006) at 08/02/2007 10:44:13 MIME-Version: 1.0 X-Spam-Score: -1.4 (-) X-Scan-Signature: 746e7c8096e71e3815c27253c4c3edc6 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="===============0332008999==" Errors-To: nea-bounces@ietf.org --===============0332008999== Content-type: multipart/related; Boundary="0__=07BBF9B8DFC9B4328f9e8a93df938690918c07BBF9B8DFC9B432" --0__=07BBF9B8DFC9B4328f9e8a93df938690918c07BBF9B8DFC9B432 Content-type: multipart/alternative; Boundary="1__=07BBF9B8DFC9B4328f9e8a93df938690918c07BBF9B8DFC9B432" --1__=07BBF9B8DFC9B4328f9e8a93df938690918c07BBF9B8DFC9B432 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Greetings, Perhaps it would be useful to separate things based on what is be= ing measured and where the measurements are taken and validated. For our purposes, there are essentially two types of measurement_= state-based and behavior-based. The traditional IDS is behavior-based.= It does not really tell you anything about the state of an endpoint but te= lls you what it is doing on the network. Recent introduction of host-based = IDS (AKA Behavioral FireWall AKA HIPS Host-Based Intrusion Prevention Syste= m) technology does not change the fact that behavior is being measured. Integrity measurements are traditionally about state from a configuration standpoint. What software is installed, how it is configu= red, what values are found in the system registry or environment variables a= re examples of state. This is the traditional thinking in the various cam= ps that are feeding the NEA effort. So there seems to be some confusion over the fact that some are proposing a tighter coupling with IDS's be built into the protocol. IMHO, this would be a useless extension for which existing protoc= ols will serve perfectly well. There is no constraint on what is being measured, transported and verified. It is all simply data that relates = to a single endpoint. If an endpoint has invalid state or is performing ille= gal actions, either of these should cause the endpoint to be kicked off or denied access to the network. There is nothing in the protocol that specifies what content is to be transferred in the tunnel created betwe= en the measurement collectors and the verifiers. Furthermore, there is nothing in the current approach that preclu= des using an IDS on the verifier side and it will be just as easy to build = an integrity verifier on an IDS as to build a new interface to a new proto= col. In either case the code has to be written but will only have to be done= once. So an endpoint could simply be queried for its MAC Address which= could be sent to an IDS with a simple "are there any violations found f= or this MAC" query. Based on what the IDS reports, the decision can be mad= e. Why do we need anything else in the context of a network admission (or = post admission) decision? Regards, Frank Yeh Sr. Security & Privacy Integration Architect IBM Global Technology Services Security & Privacy Technology Integration Team Second Life: Yehoo Newall = "TS Glassey" = = To "Mike Fratto" 08/02/2007 07:41 = cc AM nea@ietf.org, Paul Sangster = = Subj= ect Re: [Nea] 03 comments - IDS as = Posture Collecotr = = = = = = = Mike - I agree with the idea... conceptually there are two very differe= nt things going on here, and one of them is IDS centric and the other isnt= , that being the 'footprint' verification functionality of some 'change management/control' service. As to amending the wording, I think NEA wi= ll need to do both functions since they are both key aspects of an ongoing= Integrity Of Operations constrol set which this clearly is one. Todd ----- Original Message ----- From: "Mike Fratto" To: "TS Glassey" Cc: "Stefan Winter" ; ; "Paul Sangster" Sent: Thursday, August 02, 2007 7:25 AM Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr > Why not just clarify the language to indicate a "Host Based IDS" > instead of "IDS"? > > Host based stuff is certainly within the charter. There are such > beasties on the market and as part of posture validation, can be used= > in assessments in the same way an anti-virus or patch management > product can. > > Besides, there is nothing to be gained by removing the reference and > if removed, leaves a gap that is open to interpretation. > > On 8/2/07, TS Glassey wrote: >> This is then about Configuration Management as well as Integrity? >> >> T >> ----- Original Message ----- >> From: "Stefan Winter" >> To: >> Cc: "Paul Sangster" >> Sent: Thursday, August 02, 2007 2:02 AM >> Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr >> >> >> > _______________________________________________ >> > Nea mailing list >> > Nea@ietf.org >> > https://www1.ietf.org/mailman/listinfo/nea >> > >> >> >> _______________________________________________ >> Nea mailing list >> Nea@ietf.org >> https://www1.ietf.org/mailman/listinfo/nea >> _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea = --1__=07BBF9B8DFC9B4328f9e8a93df938690918c07BBF9B8DFC9B432 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Greetings,

Perhaps it would be useful to separate things based on what is being m= easured and where the measurements are taken and validated.

For our purposes, there are essentially two types of measurement_ stat= e-based and behavior-based. The traditional IDS is behavior-based. It = does not really tell you anything about the state of an endpoint but te= lls you what it is doing on the network. Recent introduction of host-ba= sed IDS (AKA Behavioral FireWall AKA HIPS Host-Based Intrusion Preventi= on System) technology does not change the fact that behavior is being m= easured.

Integrity measurements are traditionally about state from a configurat= ion standpoint. What software is installed, how it is configured, what = values are found in the system registry or environment variables are ex= amples of state. This is the traditional thinking in the various camps= that are feeding the NEA effort.

So there seems to be some confusion over the fact that some are propos= ing a tighter coupling with IDS's be built into the protocol.

IMHO, this would be a useless extension for which existing protocols w= ill serve perfectly well. There is no constraint on what is being measu= red, transported and verified. It is all simply data that relates to a = single endpoint. If an endpoint has invalid state or is performing ille= gal actions, either of these should cause the endpoint to be kicked off= or denied access to the network. There is nothing in the protocol that= specifies what content is to be transferred in the tunnel created betw= een the measurement collectors and the verifiers.

Furthermore, there is nothing in the current approach that precludes u= sing an IDS on the verifier side and it will be just as easy to build a= n integrity verifier on an IDS as to build a new interface to a new pro= tocol. In either case the code has to be written but will only have to = be done once. So an endpoint could simply be queried for its MAC Addre= ss which could be sent to an IDS with a simple "are there any viol= ations found for this MAC" query. Based on what the IDS reports, t= he decision can be made. Why do we need anything else in the context of= a network admission (or post admission) decision?

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

Second Life: Yehoo Newall

3D"Inactive"TS Glassey"= ; <tglassey@earthlink.net>


=
          "TS Glassey" <tglassey@earthlink.n= et>

          08/02/2007 07:41 AM

 =
3D=
To
3D""
"Mike Fratto" <mfratto@gmail.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""

Mike - I agree with the idea... conceptually there are two very dif= ferent
things going on here, and one of them is IDS centric and the other isnt= ,
that being the 'footprint' verification functionality of some 'change <= br> management/control' service. As to amending the wording, I think NEA wi= ll
need to do both functions since they are both key aspects of an ongoing=
Integrity Of Operations constrol set which this clearly is one.

Todd
----- Original Message -----
From: "Mike Fratto" <mfratto@gmail.com>
To: "TS Glassey" <tglassey@earthlink.net>
Cc: "Stefan Winter" <stefan.winter@restena.lu>; <nea= @ietf.org>; "Paul
Sangster" <Paul_Sangster@symantec.com>
Sent: Thursday, August 02, 2007 7:25 AM
Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr


> Why not just clarify the language to indicate a "Host Based I= DS"
> instead of "IDS"?
>
> Host based stuff is certainly within the charter. There are such > beasties on the market and as part of posture validation, can be u= sed
> in assessments in the same way an anti-virus or patch management > product can.
>
> Besides, there is nothing to be gained by removing the reference a= nd
> if removed, leaves a gap that is open to interpretation.
>
> On 8/2/07, TS Glassey <tglassey@earthlink.net> wrote:
>> This is then about Configuration Management as well as Integri= ty?
>>
>> T
>> ----- Original Message -----
>> From: "Stefan Winter" <stefan.winter@restena.lu&g= t;
>> To: <nea@ietf.org>
>> Cc: "Paul Sangster" <Paul_Sangster@symantec.com&g= t;
>> Sent: Thursday, August 02, 2007 2:02 AM
>> Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr
>>
>>
>> > _______________________________________________
>> > Nea mailing list
>> > Nea@ietf.org
>> > https://www1.ietf.org/mailman/listinfo/nea
>> >
>>
>>
>> _______________________________________________
>> Nea mailing list
>> Nea@ietf.org
>> https://www1.ietf.org/mailman/listinfo/nea
>>



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

= --1__=07BBF9B8DFC9B4328f9e8a93df938690918c07BBF9B8DFC9B432-- --0__=07BBF9B8DFC9B4328f9e8a93df938690918c07BBF9B8DFC9B432 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=07BBF9B8DFC9B4328f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=07BBF9B8DFC9B4328f9e8a93df938690918c07BBF9B8DFC9B432 Content-type: image/gif; name="pic04694.gif" Content-Disposition: inline; filename="pic04694.gif" Content-ID: <2__=07BBF9B8DFC9B4328f9e8a93df938@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__=07BBF9B8DFC9B4328f9e8a93df938690918c07BBF9B8DFC9B432 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <3__=07BBF9B8DFC9B4328f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=07BBF9B8DFC9B4328f9e8a93df938690918c07BBF9B8DFC9B432-- --===============0332008999== 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 --===============0332008999==-- From nea-bounces@ietf.org Thu Aug 02 17:46:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGiUm-0007FE-5U; Thu, 02 Aug 2007 17:46:12 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IGiUk-0007Et-B1 for nea-confirm+ok@megatron.ietf.org; Thu, 02 Aug 2007 17:46:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGiUj-0007El-S6 for nea@ietf.org; Thu, 02 Aug 2007 17:46:10 -0400 Received: from e31.co.us.ibm.com ([32.97.110.149]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGiUh-0003wR-Js for nea@ietf.org; Thu, 02 Aug 2007 17:46:09 -0400 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e31.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l72Lk6es024034 for ; Thu, 2 Aug 2007 17:46:06 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v8.4) with ESMTP id l72Lk6SS258282 for ; Thu, 2 Aug 2007 15:46:06 -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 l72Lk6Bm032276 for ; Thu, 2 Aug 2007 15:46:06 -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 l72Lk6HU032264; Thu, 2 Aug 2007 15:46:06 -0600 In-Reply-To: <002301c7d525$7d4e53e0$6501a8c0@tsg1> Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr To: "TS Glassey" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Frank Yeh Jr Date: Thu, 2 Aug 2007 14:46:10 -0700 X-MIMETrack: Serialize by Router on D03NM129/03/M/IBM(Release 7.0.2HF32 | October 17, 2006) at 08/02/2007 15:46:05 MIME-Version: 1.0 X-Spam-Score: 2.6 (++) X-Scan-Signature: b67ab81b2db0d00304056d0360a5a39a 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="===============1407975592==" Errors-To: nea-bounces@ietf.org --===============1407975592== Content-type: multipart/related; Boundary="0__=07BBF9B8DFE4AC338f9e8a93df938690918c07BBF9B8DFE4AC33" --0__=07BBF9B8DFE4AC338f9e8a93df938690918c07BBF9B8DFE4AC33 Content-type: multipart/alternative; Boundary="1__=07BBF9B8DFE4AC338f9e8a93df938690918c07BBF9B8DFE4AC33" --1__=07BBF9B8DFE4AC338f9e8a93df938690918c07BBF9B8DFE4AC33 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Greetings, I understand your points but consider them to be out of scope for= NEA, which is about establishing and using a tunnel to pass data. What happens to the data outside of the tunnel, how it is collected, etc are= outside the scope of the protocol. What you want is a standard way of dealing with the data once it = is passed through the tunnel. NEA is purposely generic about this to make = it as flexible as possible. If you want to define a standard way to then p= ass that data to an IDS and figure out what to do, great. That would requir= e another specification which would use NEA as transport and as a network= admission control point. Regards, Frank Yeh Sr. Security & Privacy Integration Architect IBM Global Technology Services Security & Privacy Technology Integration Team Second Life: Yehoo Newall = "TS Glassey" = = To Frank Yeh Jr/Irvine/IBM@IBMUS = 08/02/2007 09:52 = cc AM "Mike Fratto" , , "Paul Sangster" = = Subj= ect Re: [Nea] 03 comments - IDS as = Posture Collecotr = = = = = = = pardon the blue-sky rant here but... The real value from a philosophica= l point I see for NEA is that it could be a collection point for a number= of Policy Service tools, and that it can tie this in with a set of attesta= tion practice models for running secured and reliable infrastructure. That s= aid, the point is that there keenly is a need to handle the stateful complia= nce with 'pre-specified policy and configuration management' and that this = is specific not only to just plugging a system into a network but in prefa= cing the connections of two distributed systems from untrusted networks together. OK -- so what does all that really mean? - Simple - it means that there= in the IETF's bag of tricks needs to be a really cool messaging and policy= communication language and protocol which can be used not only to quali= fy a machine for action in an environment, but also for operations as a pre-event transaction qualification as well. This possibly makes NEA it= . The one and only qualifer and setup infrastructure needed to bring mach= ines in or take them out, and to have applications use. t. ----- Original Message ----- From: Frank Yeh Jr To: TS Glassey Cc: Mike Fratto ; nea@ietf.org ; Paul Sangster Sent: Thursday, August 02, 2007 9:44 AM Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr Greetings, Perhaps it would be useful to separate things based on what is being measured and where the measurements are taken and validated. For our purposes, there are essentially two types of measurement_ state-based and behavior-based. The traditional IDS is behavior-based.= It does not really tell you anything about the state of an endpoint but t= ells you what it is doing on the network. Recent introduction of host-based= IDS (AKA Behavioral FireWall AKA HIPS Host-Based Intrusion Prevention Syst= em) technology does not change the fact that behavior is being measured. Integrity measurements are traditionally about state from a configurat= ion standpoint. What software is installed, how it is configured, what val= ues are found in the system registry or environment variables are examples= of state. This is the traditional thinking in the various camps that are feeding the NEA effort. So there seems to be some confusion over the fact that some are propos= ing a tighter coupling with IDS's be built into the protocol. IMHO, this would be a useless extension for which existing protocols w= ill serve perfectly well. There is no constraint on what is being measured= , transported and verified. It is all simply data that relates to a sing= le endpoint. If an endpoint has invalid state or is performing illegal actions, either of these should cause the endpoint to be kicked off or= denied access to the network. There is nothing in the protocol that specifies what content is to be transferred in the tunnel created betw= een the measurement collectors and the verifiers. Furthermore, there is nothing in the current approach that precludes u= sing an IDS on the verifier side and it will be just as easy to build an integrity verifier on an IDS as to build a new interface to a new protocol. In either case the code has to be written but will only have= to be done once. So an endpoint could simply be queried for its MAC Addre= ss which could be sent to an IDS with a simple "are there any violations found for this MAC" query. Based on what the IDS reports, the decision= can be made. Why do we need anything else in the context of a network admission (or post admission) decision? Regards, Frank Yeh Sr. Security & Privacy Integration Architect IBM Global Technology Services Security & Privacy Technology Integration Team Second Life: Yehoo Newall Inactive hide details for "TS Glassey" "TS Glassey" = "TS Glassey" = = = = To 08/02/2007 = 07:41 AM "Mike Fratto" = = = = cc = nea@ietf.org, Paul = Sangster = = = Subj= ect = Re: [Nea] 03 comments -= IDS as Posture Collecot= r = = = = = = Mike - I agree with the idea... conceptually there are two very differ= ent things going on here, and one of them is IDS centric and the other isn= t, that being the 'footprint' verification functionality of some 'change management/control' service. As to amending the wording, I think NEA w= ill need to do both functions since they are both key aspects of an ongoin= g Integrity Of Operations constrol set which this clearly is one. Todd ----- Original Message ----- From: "Mike Fratto" To: "TS Glassey" Cc: "Stefan Winter" ; ; "Paul Sangster" Sent: Thursday, August 02, 2007 7:25 AM Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr > Why not just clarify the language to indicate a "Host Based IDS" > instead of "IDS"? > > Host based stuff is certainly within the charter. There are such > beasties on the market and as part of posture validation, can be use= d > in assessments in the same way an anti-virus or patch management > product can. > > Besides, there is nothing to be gained by removing the reference and= > if removed, leaves a gap that is open to interpretation. > > On 8/2/07, TS Glassey wrote: >> This is then about Configuration Management as well as Integrity? >> >> T >> ----- Original Message ----- >> From: "Stefan Winter" >> To: >> Cc: "Paul Sangster" >> Sent: Thursday, August 02, 2007 2:02 AM >> Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr >> >> >> > _______________________________________________ >> > Nea mailing list >> > Nea@ietf.org >> > https://www1.ietf.org/mailman/listinfo/nea >> > >> >> >> _______________________________________________ >> Nea mailing list >> Nea@ietf.org >> https://www1.ietf.org/mailman/listinfo/nea >> _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea = --1__=07BBF9B8DFE4AC338f9e8a93df938690918c07BBF9B8DFE4AC33 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Greetings,

I understand your points but consider them to be out of scope for NEA,= which is about establishing and using a tunnel to pass data. What happ= ens to the data outside of the tunnel, how it is collected, etc are out= side the scope of the protocol.

What you want is a standard way of dealing with the data once it is pa= ssed through the tunnel. NEA is purposely generic about this to make it= as flexible as possible. If you want to define a standard way to then = pass that data to an IDS and figure out what to do, great. That would r= equire another specification which would use NEA as transport and as a = network admission control point.

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

Second Life: Yehoo Newall

3D"Inactive"TS Glassey"= ; <tglassey@earthlink.net>


=
          "TS Glassey" <tglassey@earthlink.n= et>

          08/02/2007 09:52 AM

 =
3D=
To
3D""
Frank Yeh Jr/Irvine/IBM@IBMUS
3D=
cc
3D""
"Mike Fratto" <mfratto@gmail.com>, <= ;nea@ietf.org>, "Paul Sangster" <Paul_Sangster@symantec= .com>
3D=
Subject
3D""
Re: [Nea] 03 comments - IDS as Posture Collecotr
3D=3D""

pardon the blue-sky rant here but... The real valu= e from a philosophical point I see for NEA is that it could be a collec= tion point for a number of Policy Service tools, and that it can tie th= is in with a set of attestation practice models for running secured and= reliable infrastructure. That said, the point is that there keenly is = a need to handle the stateful compliance with 'pre-specified policy and= configuration management' and that this is specific not only to just p= lugging a system into a network but in prefacing the connections of two= distributed systems from untrusted networks together.

OK -- so what does all that really mean? - Simple = - it means that there in the IETF's bag of tricks needs to be a really = cool messaging and policy communication language and protocol which can= be used not only to qualify a machine for action in an environment, bu= t also for operations as a pre-event transaction qualification as well.= This possibly makes NEA it. The one and only qualifer and setup infras= tructure needed to bring machines in or take them out, and to have appl= ications use.

t.
----- Original Message -----
From: Frank Ye= h Jr
To: TS = Glassey
Cc: Mike Fra= tto ; nea@ietf.org= ; Paul Sangster
Sent: Thursday, August = 02, 2007 9:44 AM
Subject: Re: [Nea] 03 c= omments - IDS as Posture Collecotr

Greetings,

Perhaps it would be useful to separate things based on what is being me= asured and where the measurements are taken and validated.

For our purposes, there are essentially two types of measurement_ state= -based and behavior-based. The traditional IDS is behavior-based. It do= es not really tell you anything about the state of an endpoint but tell= s you what it is doing on the network. Recent introduction of host-base= d IDS (AKA Behavioral FireWall AKA HIPS Host-Based Intrusion Prevention= System) technology does not change the fact that behavior is being mea= sured.

Integrity measurements are traditionally about state from a configurati= on standpoint. What software is installed, how it is configured, what v= alues are found in the system registry or environment variables are exa= mples of state. This is the traditional thinking in the various camps t= hat are feeding the NEA effort.

So there seems to be some confusion over the fact that some are proposi= ng a tighter coupling with IDS's be built into the protocol.

IMHO, this would be a useless extension for which existing protocols wi= ll serve perfectly well. There is no constraint on what is being measur= ed, transported and verified. It is all simply data that relates to a s= ingle endpoint. If an endpoint has invalid state or is performing illeg= al actions, either of these should cause the endpoint to be kicked off = or denied access to the network. There is nothing in the protocol that = specifies what content is to be transferred in the tunnel created betwe= en the measurement collectors and the verifiers.

Furthermore, there is nothing in the current approach that precludes us= ing an IDS on the verifier side and it will be just as easy to build an= integrity verifier on an IDS as to build a new interface to a new prot= ocol. In either case the code has to be written but will only have to b= e done once. So an endpoint could simply be queried for its MAC Address= which could be sent to an IDS with a simple "are there any violat= ions found for this MAC" query. Based on what the IDS reports, the= decision can be made. Why do we need anything else in the context of a= network admission (or post admission) decision?

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

Second Life: Yehoo Newall

3D"Inactive"TS G= lassey" <tglassey@earthlink.net>

 =
                  "TS Glassey" <tglassey@earthlink.net>

                  08/02/2007 07:41 AM

 =
To

"Mike Fratto" <mfratto@gmail.com>
cc

nea@ietf.org, Paul Sangster <Paul_Sangster@symantec.com>
Subject

Re: [Nea] 03 comments - IDS as Posture Collecotr
=

Mike - I agree with the idea... conceptually there are two very differe= nt
things going on here, and one of them is IDS centric and the other isnt= ,
that being the 'footprint' verification functionality of some 'change <= br> management/control' service. As to amending the wording, I think NEA wi= ll
need to do both functions since they are both key aspects of an ongoing=
Integrity Of Operations constrol set which this clearly is one.

Todd
----- Original Message -----
From: "Mike Fratto" <mfratto@gmail.com>
To: "TS Glassey" <tglassey@earthlink.net>
Cc: "Stefan Winter" <stefan.winter@restena.lu>; <nea= @ietf.org>; "Paul
Sangster" <Paul_Sangster@symantec.com>
Sent: Thursday, August 02, 2007 7:25 AM
Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr


> Why not just clarify the language to indicate a "Host Based I= DS"
> instead of "IDS"?
>
> Host based stuff is certainly within the charter. There are such > beasties on the market and as part of posture validation, can be u= sed
> in assessments in the same way an anti-virus or patch management > product can.
>
> Besides, there is nothing to be gained by removing the reference a= nd
> if removed, leaves a gap that is open to interpretation.
>
> On 8/2/07, TS Glassey <tglassey@earthlink.net> wrote:
>> This is then about Configuration Management as well as Integri= ty?
>>
>> T
>> ----- Original Message -----
>> From: "Stefan Winter" <stefan.winter@restena.lu&g= t;
>> To: <nea@ietf.org>
>> Cc: "Paul Sangster" <Paul_Sangster@symantec.com&g= t;
>> Sent: Thursday, August 02, 2007 2:02 AM
>> Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr
>>
>>
>> > _______________________________________________
>> > Nea mailing list
>> > Nea@ietf.org
>> > https://www1.ietf.o= rg/mailman/listinfo/nea
>> >
>>
>>
>> _______________________________________________
>> Nea mailing list
>> Nea@ietf.org
>> https://www1.ietf.org/ma= ilman/listinfo/nea
>>



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

= --1__=07BBF9B8DFE4AC338f9e8a93df938690918c07BBF9B8DFE4AC33-- --0__=07BBF9B8DFE4AC338f9e8a93df938690918c07BBF9B8DFE4AC33 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=07BBF9B8DFE4AC338f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=07BBF9B8DFE4AC338f9e8a93df938690918c07BBF9B8DFE4AC33 Content-type: image/gif; name="pic12040.gif" Content-Disposition: inline; filename="pic12040.gif" Content-ID: <2__=07BBF9B8DFE4AC338f9e8a93df938@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__=07BBF9B8DFE4AC338f9e8a93df938690918c07BBF9B8DFE4AC33 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <3__=07BBF9B8DFE4AC338f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=07BBF9B8DFE4AC338f9e8a93df938690918c07BBF9B8DFE4AC33 Content-type: image/gif; name="14368687.gif" Content-Disposition: inline; filename="14368687.gif" Content-ID: <4__=07BBF9B8DFE4AC338f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=07BBF9B8DFE4AC338f9e8a93df938690918c07BBF9B8DFE4AC33 Content-type: image/gif; name="14634822.gif" Content-Disposition: inline; filename="14634822.gif" Content-ID: <5__=07BBF9B8DFE4AC338f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=07BBF9B8DFE4AC338f9e8a93df938690918c07BBF9B8DFE4AC33-- --===============1407975592== 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 --===============1407975592==-- From nea-bounces@ietf.org Fri Aug 03 12:12:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGzli-0003vt-AN; Fri, 03 Aug 2007 12:12:50 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IGzlh-0003vo-2k for nea-confirm+ok@megatron.ietf.org; Fri, 03 Aug 2007 12:12:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGzlg-0003vf-L7 for nea@ietf.org; Fri, 03 Aug 2007 12:12:48 -0400 Received: from e32.co.us.ibm.com ([32.97.110.150]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGzld-0007bI-Q4 for nea@ietf.org; Fri, 03 Aug 2007 12:12:48 -0400 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e32.co.us.ibm.com (8.12.11.20060308/8.13.8) with ESMTP id l73F5phx003049 for ; Fri, 3 Aug 2007 11:05:51 -0400 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v8.4) with ESMTP id l73GC7ZB259724 for ; Fri, 3 Aug 2007 10:12:07 -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 l73GC6p7009648 for ; Fri, 3 Aug 2007 10:12:06 -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 l73GC6IW009599 for ; Fri, 3 Aug 2007 10:12:06 -0600 In-Reply-To: <005b01c7d5df$3fafaf10$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: Fri, 3 Aug 2007 09:12:12 -0700 X-MIMETrack: Serialize by Router on D03NM129/03/M/IBM(Release 7.0.2HF32 | October 17, 2006) at 08/03/2007 10:12:06 MIME-Version: 1.0 X-Spam-Score: 2.6 (++) X-Scan-Signature: dc60ea982e94509a7a8f1634aa16db79 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="===============0448570023==" Errors-To: nea-bounces@ietf.org --===============0448570023== Content-type: multipart/related; Boundary="0__=07BBF9BFDFCBEC4E8f9e8a93df938690918c07BBF9BFDFCBEC4E" --0__=07BBF9BFDFCBEC4E8f9e8a93df938690918c07BBF9BFDFCBEC4E Content-type: multipart/alternative; Boundary="1__=07BBF9BFDFCBEC4E8f9e8a93df938690918c07BBF9BFDFCBEC4E" --1__=07BBF9BFDFCBEC4E8f9e8a93df938690918c07BBF9BFDFCBEC4E Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Greetings, I believe we're just going to have to agree to disagree on this o= ne. We've been around and around on this issue and unless the consens= us in the group is that this is in scope, I am going to draw the line here= . You've heard my opinion and seem to understand it, I've heard yours but= I disagree with it. I guess this is why we vote on things. Regards, Frank Yeh Sr. Security & Privacy Integration Architect IBM Global Technology Services Security & Privacy Technology Integration Team Second Life: Yehoo Newall = "todd glassey" = = To Frank Yeh Jr/Irvine/IBM@IBMUS = 08/03/2007 08:01 = cc AM "Mike Fratto" , , "Paul Sangster" = = Subj= ect Re: [Nea] 03 comments - IDS as = Posture Collecotr = = = = = = = Then the scope of the protocol is probably broken - that said, let me a= sk what is the specific use of the service? - If it is just in establishin= g what I refer to as a tentative-connection - that being one that is erec= ted to pre-qualify the use of the service then that needs to have some proc= ess wherein it can assure the world that it separates the ability to transp= ort other IP traffic until that node is qualified. No other fantasy about creating yet another protocol to do things that other protocols already do makes sense here. If the idea is the be able to qualify and constrain the 'access to the IP/Network ' for a given system, then NEA doesn't seem to do that. Personally - I was thinking that the NEA process to really meet the aud= it requirements should be outside of TCP/IP itself, maybe be based on OSX/= SPX or XNS for instance. Or perhaps Mentat's modified IP Kernel, but making= NEA just another protocol running in a TCP/IP Network is more than a waste = of time IMHO, its a nightmare waiting to happen since NO ONE HERE can cont= rol what code is written to run on those networks and as such NEA just does= n't make sense. If the intent is to provide proper messaging and control of access and 'readiness status' as well as 'integrity status' then we need to carefu= lly define the User Functions and the Constraints involved in the process P= RIOR to defining the protocol so we know what we are all trying to do - and = that doesn't seem to have happened from reading the NEA document set, end-to-end. Just my two cents. Todd Glassey, CISM, CIFI as an Auditor ----- Original Message ----- From: Frank Yeh Jr To: TS Glassey Cc: Mike Fratto ; nea@ietf.org ; Paul Sangster Sent: Thursday, August 02, 2007 2:46 PM Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr Greetings, I understand your points but consider them to be out of scope for NEA,= which is about establishing and using a tunnel to pass data. What happ= ens to the data outside of the tunnel, how it is collected, etc are outsid= e the scope of the protocol. What you want is a standard way of dealing with the data once it is pa= ssed through the tunnel. NEA is purposely generic about this to make it as flexible as possible. If you want to define a standard way to then pas= s that data to an IDS and figure out what to do, great. That would requi= re another specification which would use NEA as transport and as a networ= k admission control point. Regards, Frank Yeh Sr. Security & Privacy Integration Architect IBM Global Technology Services Security & Privacy Technology Integration Team Second Life: Yehoo Newall Inactive hide details for "TS Glassey" "TS Glassey" = "TS = Glasse = y" = Frank Yeh Jr/Irvine/IBM@IBMUS = = = cc 08/02/ = 2007 "Mike Fratto" , 09:52 , "Paul Sangster" = AM = = Subj= ect = Re: [Nea] 03 comments - IDS as = Posture Collecotr = = = = = = = pardon the blue-sky rant here but... The real value from a philosophic= al point I see for NEA is that it could be a collection point for a numbe= r of Policy Service tools, and that it can tie this in with a set of attestation practice models for running secured and reliable infrastructure. That said, the point is that there keenly is a need to= handle the stateful compliance with 'pre-specified policy and configuration management' and that this is specific not only to just plugging a system into a network but in prefacing the connections of t= wo distributed systems from untrusted networks together. OK -- so what does all that really mean? - Simple - it means that ther= e in the IETF's bag of tricks needs to be a really cool messaging and polic= y communication language and protocol which can be used not only to qual= ify a machine for action in an environment, but also for operations as a pre-event transaction qualification as well. This possibly makes NEA i= t. The one and only qualifer and setup infrastructure needed to bring machines in or take them out, and to have applications use. t. ----- Original Message ----- From: Frank Yeh Jr To: TS Glassey Cc: Mike Fratto ; nea@ietf.org ; Paul Sangster Sent: Thursday, August 02, 2007 9:44 AM Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr Greetings, Perhaps it would be useful to separate things based on what is being measured and where the measurements are taken and validated. For our purposes, there are essentially two types of measurement_ state-based and behavior-based. The traditional IDS is behavior-based.= It does not really tell you anything about the state of an endpoint but t= ells you what it is doing on the network. Recent introduction of host-based= IDS (AKA Behavioral FireWall AKA HIPS Host-Based Intrusion Prevention Syst= em) technology does not change the fact that behavior is being measured. Integrity measurements are traditionally about state from a configurat= ion standpoint. What software is installed, how it is configured, what val= ues are found in the system registry or environment variables are examples= of state. This is the traditional thinking in the various camps that are feeding the NEA effort. So there seems to be some confusion over the fact that some are propos= ing a tighter coupling with IDS's be built into the protocol. IMHO, this would be a useless extension for which existing protocols w= ill serve perfectly well. There is no constraint on what is being measured= , transported and verified. It is all simply data that relates to a sing= le endpoint. If an endpoint has invalid state or is performing illegal actions, either of these should cause the endpoint to be kicked off or= denied access to the network. There is nothing in the protocol that specifies what content is to be transferred in the tunnel created betw= een the measurement collectors and the verifiers. Furthermore, there is nothing in the current approach that precludes u= sing an IDS on the verifier side and it will be just as easy to build an integrity verifier on an IDS as to build a new interface to a new protocol. In either case the code has to be written but will only have= to be done once. So an endpoint could simply be queried for its MAC Addre= ss which could be sent to an IDS with a simple "are there any violations found for this MAC" query. Based on what the IDS reports, the decision= can be made. Why do we need anything else in the context of a network admission (or post admission) decision? Regards, Frank Yeh Sr. Security & Privacy Integration Architect IBM Global Technology Services Security & Privacy Technology Integration Team Second Life: Yehoo Newall Inactive hide details for "TS Glassey" "TS Glassey" = "TS Glassey" = = = 08/02/2007 07:41 AM = = To = "Mike Fratto" = = = cc = nea@ietf.org, Paul= Sangster = = = Subj= ect = Re: [Nea] 03 comme= nts - IDS as Posture = Collecotr = = = = = = = Mike - I agree with the idea... conceptually there are two very differ= ent things going on here, and one of them is IDS centric and the other isn= t, that being the 'footprint' verification functionality of some 'change management/control' service. As to amending the wording, I think NEA w= ill need to do both functions since they are both key aspects of an ongoin= g Integrity Of Operations constrol set which this clearly is one. Todd ----- Original Message ----- From: "Mike Fratto" To: "TS Glassey" Cc: "Stefan Winter" ; ; "Paul Sangster" Sent: Thursday, August 02, 2007 7:25 AM Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr > Why not just clarify the language to indicate a "Host Based IDS" > instead of "IDS"? > > Host based stuff is certainly within the charter. There are such > beasties on the market and as part of posture validation, can be use= d > in assessments in the same way an anti-virus or patch management > product can. > > Besides, there is nothing to be gained by removing the reference and= > if removed, leaves a gap that is open to interpretation. > > On 8/2/07, TS Glassey wrote: >> This is then about Configuration Management as well as Integrity? >> >> T >> ----- Original Message ----- >> From: "Stefan Winter" >> To: >> Cc: "Paul Sangster" >> Sent: Thursday, August 02, 2007 2:02 AM >> Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr >> >> >> > _______________________________________________ >> > Nea mailing list >> > Nea@ietf.org >> > https://www1.ietf.org/mailman/listinfo/nea >> > >> >> >> _______________________________________________ >> Nea mailing list >> Nea@ietf.org >> https://www1.ietf.org/mailman/listinfo/nea >> _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea = --1__=07BBF9BFDFCBEC4E8f9e8a93df938690918c07BBF9BFDFCBEC4E Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Greetings,

I believe we're just going to have to agree to disagree on this one.
We've been around and around on this issue and unless the consensus in= the group is that this is in scope, I am going to draw the line here. = You've heard my opinion and seem to understand it, I've heard yours but= I disagree with it.

I guess this is why we vote on things.

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>

          08/03/2007 08:01 AM

 =
3D=
To
3D""
Frank Yeh Jr/Irvine/IBM@IBMUS
3D=
cc
3D""
"Mike Fratto" <mfratto@gmail.com>, <= ;nea@ietf.org>, "Paul Sangster" <Paul_Sangster@symantec= .com>
3D=
Subject
3D""
Re: [Nea] 03 comments - IDS as Posture Collecotr
3D=3D""

Then the scope of the protocol is probab= ly broken - that said, let me ask what is the specific use of the servi= ce? - If it is just in establishing what I refer to as a tentative-conn= ection - that being one that is erected to pre-qualify the use of the s= ervice then that needs to have some process wherein it can assure the w= orld that it separates the ability to transport other IP traffic until = that node is qualified.

No other fantasy about creating yet anot= her protocol to do things that other protocols already do makes sense h= ere.

If the idea is the be able to qualify an= d constrain the 'access to the IP/Network ' for a given system, then NE= A doesn't seem to do that. Personally - I was thinking that the NEA pr= ocess to really meet the audit requirements should be outside of TCP/IP= itself, maybe be based on OSX/SPX or XNS for instance. Or perhaps Ment= at's modified IP Kernel, but making NEA just another protocol running i= n a TCP/IP Network is more than a waste of time IMHO, its a nightmare w= aiting to happen since NO ONE HERE can control what code is written to = run on those networks and as such NEA just doesn't make sense.
If the intent is to provide proper messa= ging and control of access and 'readiness status' as well as 'integrity= status' then we need to carefully define the User Functions and the Co= nstraints involved in the process PRIOR to defining the protocol so we = know what we are all trying to do - and that doesn't seem to have happe= ned from reading the NEA document set, end-to-end.


Just my two cents.

Todd Glassey, CISM, CIFI
as an Auditor
----- Original Message -----
From: Frank Ye= h Jr
To: TS = Glassey
Cc: Mike Fra= tto ; nea@ietf.org= ; Paul Sangster
Sent: Thursday, August = 02, 2007 2:46 PM
Subject: Re: [Nea] 03 c= omments - IDS as Posture Collecotr

Greetings,

I understand your points but consider them to be out of scope for NEA, = which is about establishing and using a tunnel to pass data. What happe= ns to the data outside of the tunnel, how it is collected, etc are outs= ide the scope of the protocol.

What you want is a standard way of dealing with the data once it is pas= sed through the tunnel. NEA is purposely generic about this to make it = as flexible as possible. If you want to define a standard way to then p= ass that data to an IDS and figure out what to do, great. That would re= quire another specification which would use NEA as transport and as a n= etwork admission control point.

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

Second Life: Yehoo Newall

3D"Inactive"TS G= lassey" <tglassey@earthlink.net>

 =
                  "TS Glassey" <tglassey@earthlink.net>

                  08/02/2007 09:52 AM

 =
To

Frank Yeh Jr/Irvine/IBM@IBMUS
cc

"Mike Fratto" <mfratto@gmail.com>, <nea@ietf.org>= , "Paul Sangster" <Paul_Sangster@symantec.com>
Subject

Re: [Nea] 03 comments - IDS as Posture Collecotr
=

pardon the blue-sky rant here but... The real value from a philosophica= l point I see for NEA is that it could be a collection point for a numb= er of Policy Service tools, and that it can tie this in with a set of a= ttestation practice models for running secured and reliable infrastruct= ure. That said, the point is that there keenly is a need to handle the = stateful compliance with 'pre-specified policy and configuration manage= ment' and that this is specific not only to just plugging a system into= a network but in prefacing the connections of two distributed systems = from untrusted networks together.

OK -- so what does all that really mean? - Simple - it means that there= in the IETF's bag of tricks needs to be a really cool messaging and po= licy communication language and protocol which can be used not only to = qualify a machine for action in an environment, but also for operations= as a pre-event transaction qualification as well. This possibly makes = NEA it. The one and only qualifer and setup infrastructure needed to br= ing machines in or take them out, and to have applications use.<= font size=3D"4">

t.
----- Original Message -----
From: Frank Yeh Jr<= font size=3D"5">
To: TS Glassey
Cc: Mike Fratto ; nea@ietf.org ; Paul Sangster =
Sent: Thursday, August 02, 2007 9:44 AM
Subject: Re: [Nea] 03 comments - IDS as Pos= ture Collecotr

Greetings,

Perhaps it would be useful to separate things based on what is being me= asured and where the measurements are taken and validated.

For our purposes, there are essentially two types of measurement_ state= -based and behavior-based. The traditional IDS is behavior-based. It do= es not really tell you anything about the state of an endpoint but tell= s you what it is doing on the network. Recent introduction of host-base= d IDS (AKA Behavioral FireWall AKA HIPS Host-Based Intrusion Prevention= System) technology does not change the fact that behavior is being mea= sured.

Integrity measurements are traditionally about state from a configurati= on standpoint. What software is installed, how it is configured, what v= alues are found in the system registry or environment variables are exa= mples of state. This is the traditional thinking in the various camps t= hat are feeding the NEA effort.

So there seems to be some confusion over the fact that some are proposi= ng a tighter coupling with IDS's be built into the protocol.

IMHO, this would be a useless extension for which existing protocols wi= ll serve perfectly well. There is no constraint on what is being measur= ed, transported and verified. It is all simply data that relates to a s= ingle endpoint. If an endpoint has invalid state or is performing illeg= al actions, either of these should cause the endpoint to be kicked off = or denied access to the network. There is nothing in the protocol that = specifies what content is to be transferred in the tunnel created betwe= en the measurement collectors and the verifiers.

Furthermore, there is nothing in the current approach that precludes us= ing an IDS on the verifier side and it will be just as easy to build an= integrity verifier on an IDS as to build a new interface to a new prot= ocol. In either case the code has to be written but will only have to b= e done once. So an endpoint could simply be queried for its MAC Address= which could be sent to an IDS with a simple "are there any violat= ions found for this MAC" query. Based on what the IDS reports, the= decision can be made. Why do we need anything else in the context of a= network admission (or post admission) decision?

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

Second Life: Yehoo Newall

3D"Inactive"TS G= lassey" <tglassey@earthlink.net>
 =
                                  "TS Glassey" <tglassey@earthlink.n= et>

                                  08/02/2007 07:41 AM

 =
To

"Mike Fratto" <mfratto@gmail.com>
cc

nea@ietf.org, Paul Sangster <Paul_Sangster@symantec.com>
Subject

Re: [Nea] 03 comments - IDS as Posture Collecotr
=

Mike - I agree with the idea... conceptually there are two very differe= nt
things going on here, and one of them is IDS centric and the other isnt= ,
that being the 'footprint' verification functionality of some 'change <= br> management/control' service. As to amending the wording, I think NEA wi= ll
need to do both functions since they are both key aspects of an ongoing=
Integrity Of Operations constrol set which this clearly is one.

Todd
----- Original Message -----
From: "Mike Fratto" <mfratto@gmail.com>
To: "TS Glassey" <tglassey@earthlink.net>
Cc: "Stefan Winter" <stefan.winter@restena.lu>; <nea= @ietf.org>; "Paul
Sangster" <Paul_Sangster@symantec.com>
Sent: Thursday, August 02, 2007 7:25 AM
Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr


> Why not just clarify the language to indicate a "Host Based I= DS"
> instead of "IDS"?
>
> Host based stuff is certainly within the charter. There are such > beasties on the market and as part of posture validation, can be u= sed
> in assessments in the same way an anti-virus or patch management > product can.
>
> Besides, there is nothing to be gained by removing the reference a= nd
> if removed, leaves a gap that is open to interpretation.
>
> On 8/2/07, TS Glassey <tglassey@earthlink.net> wrote:
>> This is then about Configuration Management as well as Integri= ty?
>>
>> T
>> ----- Original Message -----
>> From: "Stefan Winter" <stefan.winter@restena.lu&g= t;
>> To: <nea@ietf.org>
>> Cc: "Paul Sangster" <Paul_Sangster@symantec.com&g= t;
>> Sent: Thursday, August 02, 2007 2:02 AM
>> Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr
>>
>>
>> > _______________________________________________
>> > Nea mailing list
>> > Nea@ietf.org
>> > https://www1.ietf.o= rg/mailman/listinfo/nea
>> >
>>
>>
>> _______________________________________________
>> Nea mailing list
>> Nea@ietf.org
>> https://www1.ietf.org/ma= ilman/listinfo/nea
>>



_______________________________________________
Nea mailing list
Nea@ietf.org
<= u>https://www1.ietf.org/mailman/list= info/nea

= --1__=07BBF9BFDFCBEC4E8f9e8a93df938690918c07BBF9BFDFCBEC4E-- --0__=07BBF9BFDFCBEC4E8f9e8a93df938690918c07BBF9BFDFCBEC4E Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=07BBF9BFDFCBEC4E8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=07BBF9BFDFCBEC4E8f9e8a93df938690918c07BBF9BFDFCBEC4E Content-type: image/gif; name="pic23239.gif" Content-Disposition: inline; filename="pic23239.gif" Content-ID: <2__=07BBF9BFDFCBEC4E8f9e8a93df938@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__=07BBF9BFDFCBEC4E8f9e8a93df938690918c07BBF9BFDFCBEC4E Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <3__=07BBF9BFDFCBEC4E8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=07BBF9BFDFCBEC4E8f9e8a93df938690918c07BBF9BFDFCBEC4E Content-type: image/gif; name="10639620.gif" Content-Disposition: inline; filename="10639620.gif" Content-ID: <4__=07BBF9BFDFCBEC4E8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=07BBF9BFDFCBEC4E8f9e8a93df938690918c07BBF9BFDFCBEC4E Content-type: image/gif; name="10471753.gif" Content-Disposition: inline; filename="10471753.gif" Content-ID: <5__=07BBF9BFDFCBEC4E8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=07BBF9BFDFCBEC4E8f9e8a93df938690918c07BBF9BFDFCBEC4E-- --===============0448570023== 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 --===============0448570023==-- From nea-bounces@ietf.org Fri Aug 03 12:32:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH04f-0006r9-2a; Fri, 03 Aug 2007 12:32:25 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IH04d-0006r4-Nr for nea-confirm+ok@megatron.ietf.org; Fri, 03 Aug 2007 12:32:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH04d-0006qw-AU for nea@ietf.org; Fri, 03 Aug 2007 12:32:23 -0400 Received: from smtpa.juniper.net ([207.17.137.120]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IH04a-000859-Gf for nea@ietf.org; Fri, 03 Aug 2007 12:32:23 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpa.juniper.net with ESMTP; 03 Aug 2007 09:27:32 -0700 X-IronPort-AV: i="4.19,217,1183359600"; d="gif'147?scan'147,208,217,147"; a="49208182:sNHT187004816" X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Nea] 03 comments - IDS as Posture Collecotr Date: Fri, 3 Aug 2007 12:27:29 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Nea] 03 comments - IDS as Posture Collecotr Thread-Index: AcfV6TjN+fcCW6M0TVS9gZcn/eWk7QAASjXQ References: <005b01c7d5df$3fafaf10$174f7d40@home.glassey.com> From: "Stephen Hanna" To: "Frank Yeh Jr" , "todd glassey" X-Spam-Score: 3.6 (+++) X-Scan-Signature: 0cc6ce33a3e165c84359672fc0328059 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="===============1096332115==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============1096332115== Content-class: urn:content-classes:message Content-Type: multipart/related; boundary="----_=_NextPart_001_01C7D5EB.2FFE134A"; type="multipart/alternative" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7D5EB.2FFE134A Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C7D5EB.2FFE134A" ------_=_NextPart_002_01C7D5EB.2FFE134A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Actually, we don't vote in IETF. We use rough consensus. But our charter states clearly that enforcement is out of scope for NEA and as co-chair, I believe we have rough consensus to stick with that charter. So this discussion is out of scope. =20 There are many interesting topics that are out of scope for NEA but they're not pertinent for discussion on this list. Let's try to focus on topics that are in scope. Could everyone please review the latest NEA requirements document and send comments to the list? The requirements document is in Working Group Last Call so now's the time to do this review. =20 Thanks, =20 Steve ________________________________ From: Frank Yeh Jr [mailto:fyeh@us.ibm.com]=20 Sent: Friday, August 03, 2007 12:12 PM To: todd glassey Cc: nea@ietf.org; Paul Sangster Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr Greetings, I believe we're just going to have to agree to disagree on this one. We've been around and around on this issue and unless the consensus in the group is that this is in scope, I am going to draw the line here. You've heard my opinion and seem to understand it, I've heard yours but I disagree with it. I guess this is why we vote on things. Regards, Frank Yeh Sr. Security & Privacy Integration Architect IBM Global Technology Services Security & Privacy Technology Integration Team Second Life: Yehoo Newall "todd glassey" "todd glassey" =20 08/03/2007 08:01 AM =20 To Frank Yeh Jr/Irvine/IBM@IBMUS=09 cc "Mike Fratto" , , "Paul Sangster" =09 Subject Re: [Nea] 03 comments - IDS as Posture Collecotr=09 =09 Then the scope of the protocol is probably broken - that said, let me ask what is the specific use of the service? - If it is just in establishing what I refer to as a tentative-connection - that being one that is erected to pre-qualify the use of the service then that needs to have some process wherein it can assure the world that it separates the ability to transport other IP traffic until that node is qualified.=20 No other fantasy about creating yet another protocol to do things that other protocols already do makes sense here.=20 If the idea is the be able to qualify and constrain the 'access to the IP/Network ' for a given system, then NEA doesn't seem to do that. Personally - I was thinking that the NEA process to really meet the audit requirements should be outside of TCP/IP itself, maybe be based on OSX/SPX or XNS for instance. Or perhaps Mentat's modified IP Kernel, but making NEA just another protocol running in a TCP/IP Network is more than a waste of time IMHO, its a nightmare waiting to happen since NO ONE HERE can control what code is written to run on those networks and as such NEA just doesn't make sense. If the intent is to provide proper messaging and control of access and 'readiness status' as well as 'integrity status' then we need to carefully define the User Functions and the Constraints involved in the process PRIOR to defining the protocol so we know what we are all trying to do - and that doesn't seem to have happened from reading the NEA document set, end-to-end. Just my two cents. Todd Glassey, CISM, CIFI as an Auditor ----- Original Message -----=20 From: Frank Yeh Jr =20 To: TS Glassey =20 Cc: Mike Fratto ; nea@ietf.org ; Paul Sangster =20 Sent: Thursday, August 02, 2007 2:46 PM Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr Greetings, I understand your points but consider them to be out of scope for NEA, which is about establishing and using a tunnel to pass data. What happens to the data outside of the tunnel, how it is collected, etc are outside the scope of the protocol. What you want is a standard way of dealing with the data once it is passed through the tunnel. NEA is purposely generic about this to make it as flexible as possible. If you want to define a standard way to then pass that data to an IDS and figure out what to do, great. That would require another specification which would use NEA as transport and as a network admission control point. Regards, Frank Yeh Sr. Security & Privacy Integration Architect IBM Global Technology Services Security & Privacy Technology Integration Team Second Life: Yehoo Newall "TS Glassey" "TS Glassey" =20 08/02/2007 09:52 AM =20 To Frank Yeh Jr/Irvine/IBM@IBMUS=09 =20 cc "Mike Fratto" , , "Paul Sangster" =09 =20 Subject Re: [Nea] 03 comments - IDS as Posture Collecotr=09 =09 pardon the blue-sky rant here but... The real value from a philosophical point I see for NEA is that it could be a collection point for a number of Policy Service tools, and that it can tie this in with a set of attestation practice models for running secured and reliable infrastructure. That said, the point is that there keenly is a need to handle the stateful compliance with 'pre-specified policy and configuration management' and that this is specific not only to just plugging a system into a network but in prefacing the connections of two distributed systems from untrusted networks together. OK -- so what does all that really mean? - Simple - it means that there in the IETF's bag of tricks needs to be a really cool messaging and policy communication language and protocol which can be used not only to qualify a machine for action in an environment, but also for operations as a pre-event transaction qualification as well. This possibly makes NEA it. The one and only qualifer and setup infrastructure needed to bring machines in or take them out, and to have applications use. t. ----- Original Message -----=20 From: Frank Yeh Jr =20 To: TS Glassey =20 Cc: Mike Fratto ; nea@ietf.org ; Paul Sangster =20 Sent: Thursday, August 02, 2007 9:44 AM Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr=20 Greetings, Perhaps it would be useful to separate things based on what is being measured and where the measurements are taken and validated. For our purposes, there are essentially two types of measurement_ state-based and behavior-based. The traditional IDS is behavior-based. It does not really tell you anything about the state of an endpoint but tells you what it is doing on the network. Recent introduction of host-based IDS (AKA Behavioral FireWall AKA HIPS Host-Based Intrusion Prevention System) technology does not change the fact that behavior is being measured. Integrity measurements are traditionally about state from a configuration standpoint. What software is installed, how it is configured, what values are found in the system registry or environment variables are examples of state. This is the traditional thinking in the various camps that are feeding the NEA effort. So there seems to be some confusion over the fact that some are proposing a tighter coupling with IDS's be built into the protocol. IMHO, this would be a useless extension for which existing protocols will serve perfectly well. There is no constraint on what is being measured, transported and verified. It is all simply data that relates to a single endpoint. If an endpoint has invalid state or is performing illegal actions, either of these should cause the endpoint to be kicked off or denied access to the network. There is nothing in the protocol that specifies what content is to be transferred in the tunnel created between the measurement collectors and the verifiers. Furthermore, there is nothing in the current approach that precludes using an IDS on the verifier side and it will be just as easy to build an integrity verifier on an IDS as to build a new interface to a new protocol. In either case the code has to be written but will only have to be done once. So an endpoint could simply be queried for its MAC Address which could be sent to an IDS with a simple "are there any violations found for this MAC" query. Based on what the IDS reports, the decision can be made. Why do we need anything else in the context of a network admission (or post admission) decision? Regards, Frank Yeh Sr. Security & Privacy Integration Architect IBM Global Technology Services Security & Privacy Technology Integration Team Second Life: Yehoo Newall "TS Glassey" "TS Glassey" =20 08/02/2007 07:41 AM =20 To "Mike Fratto" =09 =20 cc nea@ietf.org, Paul Sangster =09 =20 Subject Re: [Nea] 03 comments - IDS as Posture Collecotr=09 =09 Mike - I agree with the idea... conceptually there are two very different=20 things going on here, and one of them is IDS centric and the other isnt, that being the 'footprint' verification functionality of some 'change=20 management/control' service. As to amending the wording, I think NEA will=20 need to do both functions since they are both key aspects of an ongoing=20 Integrity Of Operations constrol set which this clearly is one. Todd ----- Original Message -----=20 From: "Mike Fratto" To: "TS Glassey" Cc: "Stefan Winter" ; ; "Paul=20 Sangster" Sent: Thursday, August 02, 2007 7:25 AM Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr > Why not just clarify the language to indicate a "Host Based IDS" > instead of "IDS"? > > Host based stuff is certainly within the charter. There are such > beasties on the market and as part of posture validation, can be used > in assessments in the same way an anti-virus or patch management > product can. > > Besides, there is nothing to be gained by removing the reference and > if removed, leaves a gap that is open to interpretation. > > On 8/2/07, TS Glassey wrote: >> This is then about Configuration Management as well as Integrity? >> >> T >> ----- Original Message ----- >> From: "Stefan Winter" >> To: >> Cc: "Paul Sangster" >> Sent: Thursday, August 02, 2007 2:02 AM >> Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr >> >> >> > _______________________________________________ >> > Nea mailing list >> > Nea@ietf.org >> > https://www1.ietf.org/mailman/listinfo/nea =20 >> > >> >> >> _______________________________________________ >> Nea mailing list >> Nea@ietf.org >> https://www1.ietf.org/mailman/listinfo/nea =20 >>=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea =20 ------_=_NextPart_002_01C7D5EB.2FFE134A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Actually, we don't vote in IETF. We use rough = consensus.=20 But our charter states clearly that enforcement is out of scope for NEA = and as=20 co-chair, I believe we have rough consensus to stick with that charter. = So this=20 discussion is out of scope.
 
There are many interesting topics that are out = of scope for=20 NEA but they're not pertinent for discussion on this list. Let's try to = focus=20 on topics that are in scope. Could everyone please review the = latest NEA=20 requirements document and send comments to the list? The requirements = document=20 is in Working Group Last Call so now's the time to do this=20 review.
 
Thanks,
 
Steve

From: Frank Yeh Jr = [mailto:fyeh@us.ibm.com]=20
Sent: Friday, August 03, 2007 12:12 PM
To: todd=20 glassey
Cc: nea@ietf.org; Paul Sangster
Subject: Re: = [Nea]=20 03 comments - IDS as Posture Collecotr

Greetings,

I believe we're just going to have to agree to = disagree on=20 this one.

We've been around and around on this issue and unless = the=20 consensus in the group is that this is in scope, I am going to draw the = line=20 here. You've heard my opinion and seem to understand it, I've heard = yours but I=20 disagree with it.

I guess this is why we vote on=20 things.

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

Second Life: Yehoo Newall

3D'Inactive'=20 src=3D"cid:125442116@03082007-0C5E" width=3D16 border=3D0>"todd glassey" = <tglassey@earthlink.net>


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

          08/03/2007 08:01 = AM

3D""=20
To
 3D""=20
Frank Yeh Jr/Irvine/IBM@IBMUS
3D""=20
cc
 3D""=20
"Mike Fratto" <mfratto@gmail.com>,=20 <nea@ietf.org>, "Paul Sangster"=20 <Paul_Sangster@symantec.com>
3D""=20
Subject
 3D""=20
Re: [Nea] 03 comments - IDS as Posture=20 Collecotr
3D"" 3D""

Then the scope of the protocol is probably = broken - that=20 said, let me ask what is the specific use of the service? - If it is = just in=20 establishing what I refer to as a tentative-connection - that being one = that is=20 erected to pre-qualify the use of the service then that needs to have = some=20 process wherein it can assure the world that it separates the ability to = transport other IP traffic until that node is qualified. =

No other fantasy = about creating=20 yet another protocol to do things that other protocols already do makes = sense=20 here.

If the=20 idea is the be able to qualify and constrain the 'access to the = IP/Network ' for=20 a given system, then NEA doesn't seem to do that. Personally - I was = thinking=20 that the NEA process to really meet the audit requirements should be = outside of=20 TCP/IP itself, maybe be based on OSX/SPX or XNS for instance. Or perhaps = Mentat's modified IP Kernel, but making NEA just another protocol = running in a=20 TCP/IP Network is more than a waste of time IMHO, its a nightmare = waiting to=20 happen since NO ONE HERE can control what code is written to run on = those=20 networks and as such NEA just doesn't make sense.

If the intent is to = provide=20 proper messaging and control of access and 'readiness status' as well as = 'integrity status' then we need to carefully define the User Functions = and the=20 Constraints involved in the process PRIOR to defining the protocol so we = know=20 what we are all trying to do - and that doesn't seem to have happened = from=20 reading the NEA document set, end-to-end.


Just my=20 two cents.

Todd=20 Glassey, CISM, CIFI
as an=20 Auditor
----- Original Message ----- =
From: Frank = Yeh=20 Jr
To: TS Glassey
Cc: Mike = Fratto ; nea@ietf.org ; Paul=20 Sangster
Sent: Thursday, August 02, 2007 2:46=20 PM
Subject: Re: = [Nea] 03=20 comments - IDS as Posture Collecotr

Greetings,

I understand your points but = consider them to=20 be out of scope for NEA, which is about establishing and using a tunnel = to pass=20 data. What happens to the data outside of the tunnel, how it is = collected, etc=20 are outside the scope of the protocol.

What you want is a = standard way of=20 dealing with the data once it is passed through the tunnel. NEA is = purposely=20 generic about this to make it as flexible as possible. If you want to = define a=20 standard way to then pass that data to an IDS and figure out what to do, = great.=20 That would require another specification which would use NEA as = transport and as=20 a network admission control point.

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

Second=20 Life: Yehoo Newall

3D'Inactive'=20 src=3D"cid:125442116@03082007-0C6C" width=3D16>"TS = Glassey"=20 <tglassey@earthlink.net>
                  "TS Glassey" = <tglassey@earthlink.net>=20

                  08/02/2007 09:52 = AM
To
Frank Yeh Jr/Irvine/IBM@IBMUS
cc
"Mike Fratto" <mfratto@gmail.com>,=20 <nea@ietf.org>, "Paul Sangster"=20 <Paul_Sangster@symantec.com>
Subject
Re: [Nea] 03 comments - IDS as Posture=20 Collecotr

pardon the blue-sky rant here but... The real value from a=20 philosophical point I see for NEA is that it could be a collection point = for a=20 number of Policy Service tools, and that it can tie this in with a set = of=20 attestation practice models for running secured and reliable = infrastructure.=20 That said, the point is that there keenly is a need to handle the = stateful=20 compliance with 'pre-specified policy and configuration management' and = that=20 this is specific not only to just plugging a system into a network but = in=20 prefacing the connections of two distributed systems from untrusted = networks=20 together.

OK -- so=20 what does all that really mean? - Simple - it means that there in the = IETF's bag=20 of tricks needs to be a really cool messaging and policy communication = language=20 and protocol which can be used not only to qualify a machine for action = in an=20 environment, but also for operations as a pre-event transaction = qualification as=20 well. This possibly makes NEA it. The one and only qualifer and setup=20 infrastructure needed to bring machines in or take them out, and to have = applications use.

t.
----- Original Message -----=20
From: Frank = Yeh=20 Jr
To: TS Glassey
Cc: Mike = Fratto ; nea@ietf.org ; Paul=20 Sangster
Sent: Thursday, August 02, 2007 = 9:44=20 AM
Subject: Re: = [Nea] 03=20 comments - IDS as Posture Collecotr=20

Greetings,

Perhaps it would be useful to = separate things=20 based on what is being measured and where the measurements are taken and = validated.

For our purposes, there are essentially two types of=20 measurement_ state-based and behavior-based. The traditional IDS is=20 behavior-based. It does not really tell you anything about the state of = an=20 endpoint but tells you what it is doing on the network. Recent = introduction of=20 host-based IDS (AKA Behavioral FireWall AKA HIPS Host-Based Intrusion = Prevention=20 System) technology does not change the fact that behavior is being=20 measured.

Integrity measurements are traditionally about state = from a=20 configuration standpoint. What software is installed, how it is = configured, what=20 values are found in the system registry or environment variables are = examples of=20 state. This is the traditional thinking in the various camps that are = feeding=20 the NEA effort.

So there seems to be some confusion over the fact = that=20 some are proposing a tighter coupling with IDS's be built into the=20 protocol.

IMHO, this would be a useless extension for which = existing=20 protocols will serve perfectly well. There is no constraint on what is = being=20 measured, transported and verified. It is all simply data that relates = to a=20 single endpoint. If an endpoint has invalid state or is performing = illegal=20 actions, either of these should cause the endpoint to be kicked off or = denied=20 access to the network. There is nothing in the protocol that specifies = what=20 content is to be transferred in the tunnel created between the = measurement=20 collectors and the verifiers.

Furthermore, there is nothing in = the=20 current approach that precludes using an IDS on the verifier side and it = will be=20 just as easy to build an integrity verifier on an IDS as to build a new=20 interface to a new protocol. In either case the code has to be written = but will=20 only have to be done once. So an endpoint could simply be queried for = its MAC=20 Address which could be sent to an IDS with a simple "are there any = violations=20 found for this MAC" query. Based on what the IDS reports, the decision = can be=20 made. Why do we need anything else in the context of a network admission = (or=20 post admission) decision?

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

Second Life: Yehoo=20 Newall

3D'Inactive'=20 src=3D"cid:125442116@03082007-0C6C" width=3D16>"TS = Glassey"=20 <tglassey@earthlink.net>
                                  "TS Glassey"=20 = <tglassey@earthlink.net>

                                  08/02/2007 07:41=20 = AM

          =
To
"Mike Fratto"=20 <mfratto@gmail.com>
cc
nea@ietf.org, Paul Sangster=20 <Paul_Sangster@symantec.com>
Subject
Re: [Nea] 03 comments - IDS as = Posture=20 Collecotr

Mike - I agree with the idea... conceptually there are two = very=20 different
things going on here, and one of them is IDS centric and = the other=20 isnt,
that being the 'footprint' verification functionality of some = 'change=20
management/control' service. As to amending the wording, I think NEA = will=20
need to do both functions since they are both key aspects of an = ongoing=20
Integrity Of Operations constrol set which this clearly is=20 one.

Todd
----- Original Message -----
From: "Mike Fratto" = <mfratto@gmail.com>
To: "TS Glassey"=20 <tglassey@earthlink.net>
Cc: "Stefan Winter"=20 <stefan.winter@restena.lu>; <nea@ietf.org>; "Paul =
Sangster"=20 <Paul_Sangster@symantec.com>
Sent: Thursday, August 02, 2007 = 7:25=20 AM
Subject: Re: [Nea] 03 comments - IDS as Posture = Collecotr


>=20 Why not just clarify the language to indicate a "Host Based IDS"
> = instead=20 of "IDS"?
>
> Host based stuff is certainly within the = charter.=20 There are such
> beasties on the market and as part of posture = validation,=20 can be used
> in assessments in the same way an anti-virus or = patch=20 management
> product can.
>
> Besides, there is = nothing to be=20 gained by removing the reference and
> if removed, leaves a gap = that is=20 open to interpretation.
>
> On 8/2/07, TS Glassey=20 <tglassey@earthlink.net> wrote:
>> This is then about=20 Configuration Management as well as Integrity?
>>
>>=20 T
>> ----- Original Message -----
>> From: "Stefan = Winter"=20 <stefan.winter@restena.lu>
>> To:=20 <nea@ietf.org>
>> Cc: "Paul Sangster"=20 <Paul_Sangster@symantec.com>
>> Sent: Thursday, August = 02, 2007=20 2:02 AM
>> Subject: Re: [Nea] 03 comments - IDS as Posture=20 Collecotr
>>
>>
>> >=20 _______________________________________________
>> > Nea = mailing=20 list
>> > Nea@ietf.org
>> > https://www1.ietf.org/mailman/listinfo/nea
>> >
>>
>>
>>=20 _______________________________________________
>> Nea mailing=20 list
>> Nea@ietf.org
>> https://www1.ietf.org/mailman/listinfo/nea
>>=20



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

------_=_NextPart_002_01C7D5EB.2FFE134A-- ------_=_NextPart_001_01C7D5EB.2FFE134A Content-Type: image/gif; name="graycol.gif" Content-Transfer-Encoding: base64 Content-ID: <125442116@03082007-0C5E> Content-Description: graycol.gif Content-Location: graycol.gif R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 ------_=_NextPart_001_01C7D5EB.2FFE134A Content-Type: image/gif; name="ecblank.gif" Content-Transfer-Encoding: base64 Content-ID: <125442116@03082007-0C65> Content-Description: ecblank.gif Content-Location: ecblank.gif R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 ------_=_NextPart_001_01C7D5EB.2FFE134A Content-Type: image/gif; name="10639620.gif" Content-Transfer-Encoding: base64 Content-ID: <125442116@03082007-0C6C> Content-Description: 10639620.gif Content-Location: 10639620.gif R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 ------_=_NextPart_001_01C7D5EB.2FFE134A Content-Type: image/gif; name="10471753.gif" Content-Transfer-Encoding: base64 Content-ID: <125442116@03082007-0C73> Content-Description: 10471753.gif Content-Location: 10471753.gif R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 ------_=_NextPart_001_01C7D5EB.2FFE134A-- --===============1096332115== 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 --===============1096332115==-- From nea-bounces@ietf.org Fri Aug 03 13:29: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 1IH0xW-0003pf-JX; Fri, 03 Aug 2007 13:29:06 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IH0xV-0003pT-Nt for nea-confirm+ok@megatron.ietf.org; Fri, 03 Aug 2007 13:29:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH0xV-0003pI-8t for nea@ietf.org; Fri, 03 Aug 2007 13:29:05 -0400 Received: from smtpb.juniper.net ([207.17.137.119]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IH0xS-00010u-AC for nea@ietf.org; Fri, 03 Aug 2007 13:29:05 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpb.juniper.net with ESMTP; 03 Aug 2007 10:29:01 -0700 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Nea] 03 comments - IDS as Posture Collecotr Date: Fri, 3 Aug 2007 13:29:00 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Nea] 03 comments - IDS as Posture Collecotr Thread-Index: AcfV6TjN+fcCW6M0TVS9gZcn/eWk7QAASjXQAAJNa6A= References: <005b01c7d5df$3fafaf10$174f7d40@home.glassey.com> From: "Stephen Hanna" To: X-Spam-Score: 3.6 (+++) X-Scan-Signature: acbee687725127cbf106f41c48a81403 X-BeenThere: nea@ietf.org X-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="===============0628932228==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============0628932228== Content-class: urn:content-classes:message Content-Type: multipart/related; boundary="----_=_NextPart_001_01C7D5F3.C781514F"; type="multipart/alternative" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7D5F3.C781514F Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C7D5F3.C781514F" ------_=_NextPart_002_01C7D5F3.C781514F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Todd suggested that I send the URL for the requirements document to make it convenient to review. That is http://www.ietf.org/internet-drafts/draft-ietf-nea-requirements-03.txt =20 Thanks, =20 Steve ________________________________ From: Stephen Hanna=20 Sent: Friday, August 03, 2007 12:27 PM To: Frank Yeh Jr; todd glassey Cc: nea@ietf.org; Paul Sangster Subject: RE: [Nea] 03 comments - IDS as Posture Collecotr Actually, we don't vote in IETF. We use rough consensus. But our charter states clearly that enforcement is out of scope for NEA and as co-chair, I believe we have rough consensus to stick with that charter. So this discussion is out of scope. =20 There are many interesting topics that are out of scope for NEA but they're not pertinent for discussion on this list. Let's try to focus on topics that are in scope. Could everyone please review the latest NEA requirements document and send comments to the list? The requirements document is in Working Group Last Call so now's the time to do this review. =20 Thanks, =20 Steve ________________________________ From: Frank Yeh Jr [mailto:fyeh@us.ibm.com]=20 Sent: Friday, August 03, 2007 12:12 PM To: todd glassey Cc: nea@ietf.org; Paul Sangster Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr Greetings, I believe we're just going to have to agree to disagree on this one. We've been around and around on this issue and unless the consensus in the group is that this is in scope, I am going to draw the line here. You've heard my opinion and seem to understand it, I've heard yours but I disagree with it. I guess this is why we vote on things. Regards, Frank Yeh Sr. Security & Privacy Integration Architect IBM Global Technology Services Security & Privacy Technology Integration Team Second Life: Yehoo Newall "todd glassey" "todd glassey" =20 08/03/2007 08:01 AM =20 To Frank Yeh Jr/Irvine/IBM@IBMUS=09 cc "Mike Fratto" , , "Paul Sangster" =09 Subject Re: [Nea] 03 comments - IDS as Posture Collecotr=09 =09 Then the scope of the protocol is probably broken - that said, let me ask what is the specific use of the service? - If it is just in establishing what I refer to as a tentative-connection - that being one that is erected to pre-qualify the use of the service then that needs to have some process wherein it can assure the world that it separates the ability to transport other IP traffic until that node is qualified.=20 No other fantasy about creating yet another protocol to do things that other protocols already do makes sense here.=20 If the idea is the be able to qualify and constrain the 'access to the IP/Network ' for a given system, then NEA doesn't seem to do that. Personally - I was thinking that the NEA process to really meet the audit requirements should be outside of TCP/IP itself, maybe be based on OSX/SPX or XNS for instance. Or perhaps Mentat's modified IP Kernel, but making NEA just another protocol running in a TCP/IP Network is more than a waste of time IMHO, its a nightmare waiting to happen since NO ONE HERE can control what code is written to run on those networks and as such NEA just doesn't make sense. If the intent is to provide proper messaging and control of access and 'readiness status' as well as 'integrity status' then we need to carefully define the User Functions and the Constraints involved in the process PRIOR to defining the protocol so we know what we are all trying to do - and that doesn't seem to have happened from reading the NEA document set, end-to-end. Just my two cents. Todd Glassey, CISM, CIFI as an Auditor ----- Original Message -----=20 From: Frank Yeh Jr =20 To: TS Glassey =20 Cc: Mike Fratto ; nea@ietf.org ; Paul Sangster =20 Sent: Thursday, August 02, 2007 2:46 PM Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr Greetings, I understand your points but consider them to be out of scope for NEA, which is about establishing and using a tunnel to pass data. What happens to the data outside of the tunnel, how it is collected, etc are outside the scope of the protocol. What you want is a standard way of dealing with the data once it is passed through the tunnel. NEA is purposely generic about this to make it as flexible as possible. If you want to define a standard way to then pass that data to an IDS and figure out what to do, great. That would require another specification which would use NEA as transport and as a network admission control point. Regards, Frank Yeh Sr. Security & Privacy Integration Architect IBM Global Technology Services Security & Privacy Technology Integration Team Second Life: Yehoo Newall "TS Glassey" "TS Glassey" =20 08/02/2007 09:52 AM =20 To Frank Yeh Jr/Irvine/IBM@IBMUS=09 =20 cc "Mike Fratto" , , "Paul Sangster" =09 =20 Subject Re: [Nea] 03 comments - IDS as Posture Collecotr=09 =09 pardon the blue-sky rant here but... The real value from a philosophical point I see for NEA is that it could be a collection point for a number of Policy Service tools, and that it can tie this in with a set of attestation practice models for running secured and reliable infrastructure. That said, the point is that there keenly is a need to handle the stateful compliance with 'pre-specified policy and configuration management' and that this is specific not only to just plugging a system into a network but in prefacing the connections of two distributed systems from untrusted networks together. OK -- so what does all that really mean? - Simple - it means that there in the IETF's bag of tricks needs to be a really cool messaging and policy communication language and protocol which can be used not only to qualify a machine for action in an environment, but also for operations as a pre-event transaction qualification as well. This possibly makes NEA it. The one and only qualifer and setup infrastructure needed to bring machines in or take them out, and to have applications use. t. ----- Original Message -----=20 From: Frank Yeh Jr =20 To: TS Glassey =20 Cc: Mike Fratto ; nea@ietf.org ; Paul Sangster =20 Sent: Thursday, August 02, 2007 9:44 AM Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr=20 Greetings, Perhaps it would be useful to separate things based on what is being measured and where the measurements are taken and validated. For our purposes, there are essentially two types of measurement_ state-based and behavior-based. The traditional IDS is behavior-based. It does not really tell you anything about the state of an endpoint but tells you what it is doing on the network. Recent introduction of host-based IDS (AKA Behavioral FireWall AKA HIPS Host-Based Intrusion Prevention System) technology does not change the fact that behavior is being measured. Integrity measurements are traditionally about state from a configuration standpoint. What software is installed, how it is configured, what values are found in the system registry or environment variables are examples of state. This is the traditional thinking in the various camps that are feeding the NEA effort. So there seems to be some confusion over the fact that some are proposing a tighter coupling with IDS's be built into the protocol. IMHO, this would be a useless extension for which existing protocols will serve perfectly well. There is no constraint on what is being measured, transported and verified. It is all simply data that relates to a single endpoint. If an endpoint has invalid state or is performing illegal actions, either of these should cause the endpoint to be kicked off or denied access to the network. There is nothing in the protocol that specifies what content is to be transferred in the tunnel created between the measurement collectors and the verifiers. Furthermore, there is nothing in the current approach that precludes using an IDS on the verifier side and it will be just as easy to build an integrity verifier on an IDS as to build a new interface to a new protocol. In either case the code has to be written but will only have to be done once. So an endpoint could simply be queried for its MAC Address which could be sent to an IDS with a simple "are there any violations found for this MAC" query. Based on what the IDS reports, the decision can be made. Why do we need anything else in the context of a network admission (or post admission) decision? Regards, Frank Yeh Sr. Security & Privacy Integration Architect IBM Global Technology Services Security & Privacy Technology Integration Team Second Life: Yehoo Newall "TS Glassey" "TS Glassey" =20 08/02/2007 07:41 AM =20 To "Mike Fratto" =09 =20 cc nea@ietf.org, Paul Sangster =09 =20 Subject Re: [Nea] 03 comments - IDS as Posture Collecotr=09 =09 Mike - I agree with the idea... conceptually there are two very different=20 things going on here, and one of them is IDS centric and the other isnt, that being the 'footprint' verification functionality of some 'change=20 management/control' service. As to amending the wording, I think NEA will=20 need to do both functions since they are both key aspects of an ongoing=20 Integrity Of Operations constrol set which this clearly is one. Todd ----- Original Message -----=20 From: "Mike Fratto" To: "TS Glassey" Cc: "Stefan Winter" ; ; "Paul=20 Sangster" Sent: Thursday, August 02, 2007 7:25 AM Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr > Why not just clarify the language to indicate a "Host Based IDS" > instead of "IDS"? > > Host based stuff is certainly within the charter. There are such > beasties on the market and as part of posture validation, can be used > in assessments in the same way an anti-virus or patch management > product can. > > Besides, there is nothing to be gained by removing the reference and > if removed, leaves a gap that is open to interpretation. > > On 8/2/07, TS Glassey wrote: >> This is then about Configuration Management as well as Integrity? >> >> T >> ----- Original Message ----- >> From: "Stefan Winter" >> To: >> Cc: "Paul Sangster" >> Sent: Thursday, August 02, 2007 2:02 AM >> Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr >> >> >> > _______________________________________________ >> > Nea mailing list >> > Nea@ietf.org >> > https://www1.ietf.org/mailman/listinfo/nea =20 >> > >> >> >> _______________________________________________ >> Nea mailing list >> Nea@ietf.org >> https://www1.ietf.org/mailman/listinfo/nea =20 >>=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea =20 ------_=_NextPart_002_01C7D5F3.C781514F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Todd suggested that I send the URL for the = requirements document to make it convenient to review. That=20 is
http://www.ietf.org/internet-drafts/draft-ietf-nea-requirements-03= .txt
 
Thanks,
 
Steve

From: Stephen Hanna
Sent: = Friday,=20 August 03, 2007 12:27 PM
To: Frank Yeh Jr; todd = glassey
Cc:=20 nea@ietf.org; Paul Sangster
Subject: RE: [Nea] 03 comments - = IDS as=20 Posture Collecotr

Actually, we don't vote in IETF. We use rough = consensus.=20 But our charter states clearly that enforcement is out of scope for NEA = and as=20 co-chair, I believe we have rough consensus to stick with that charter. = So this=20 discussion is out of scope.
 
There are many interesting topics that are out = of scope for=20 NEA but they're not pertinent for discussion on this list. Let's try to = focus=20 on topics that are in scope. Could everyone please review the = latest NEA=20 requirements document and send comments to the list? The requirements = document=20 is in Working Group Last Call so now's the time to do this=20 review.
 
Thanks,
 
Steve

From: Frank Yeh Jr = [mailto:fyeh@us.ibm.com]=20
Sent: Friday, August 03, 2007 12:12 PM
To: todd=20 glassey
Cc: nea@ietf.org; Paul Sangster
Subject: Re: = [Nea]=20 03 comments - IDS as Posture Collecotr

Greetings,

I believe we're just going to have to agree to = disagree on=20 this one.

We've been around and around on this issue and unless = the=20 consensus in the group is that this is in scope, I am going to draw the = line=20 here. You've heard my opinion and seem to understand it, I've heard = yours but I=20 disagree with it.

I guess this is why we vote on=20 things.

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

Second Life: Yehoo Newall

3D'Inactive'=20 src=3D"cid:640392717@03082007-0C7A" width=3D16 border=3D0>"todd glassey" = <tglassey@earthlink.net>


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

          08/03/2007 08:01 = AM

3D""=20
To
 3D""=20
Frank Yeh Jr/Irvine/IBM@IBMUS
3D""=20
cc
 3D""=20
"Mike Fratto" <mfratto@gmail.com>,=20 <nea@ietf.org>, "Paul Sangster"=20 <Paul_Sangster@symantec.com>
3D""=20
Subject
 3D""=20
Re: [Nea] 03 comments - IDS as Posture=20 Collecotr
3D"" 3D""

Then the scope of the protocol is probably = broken - that=20 said, let me ask what is the specific use of the service? - If it is = just in=20 establishing what I refer to as a tentative-connection - that being one = that is=20 erected to pre-qualify the use of the service then that needs to have = some=20 process wherein it can assure the world that it separates the ability to = transport other IP traffic until that node is qualified. =

No other fantasy = about creating=20 yet another protocol to do things that other protocols already do makes = sense=20 here.

If the=20 idea is the be able to qualify and constrain the 'access to the = IP/Network ' for=20 a given system, then NEA doesn't seem to do that. Personally - I was = thinking=20 that the NEA process to really meet the audit requirements should be = outside of=20 TCP/IP itself, maybe be based on OSX/SPX or XNS for instance. Or perhaps = Mentat's modified IP Kernel, but making NEA just another protocol = running in a=20 TCP/IP Network is more than a waste of time IMHO, its a nightmare = waiting to=20 happen since NO ONE HERE can control what code is written to run on = those=20 networks and as such NEA just doesn't make sense.

If the intent is to = provide=20 proper messaging and control of access and 'readiness status' as well as = 'integrity status' then we need to carefully define the User Functions = and the=20 Constraints involved in the process PRIOR to defining the protocol so we = know=20 what we are all trying to do - and that doesn't seem to have happened = from=20 reading the NEA document set, end-to-end.


Just my=20 two cents.

Todd=20 Glassey, CISM, CIFI
as an=20 Auditor
----- Original Message ----- =
From: Frank = Yeh=20 Jr
To: TS Glassey
Cc: Mike = Fratto ; nea@ietf.org ; Paul=20 Sangster
Sent: Thursday, August 02, 2007 2:46=20 PM
Subject: Re: = [Nea] 03=20 comments - IDS as Posture Collecotr

Greetings,

I understand your points but = consider them to=20 be out of scope for NEA, which is about establishing and using a tunnel = to pass=20 data. What happens to the data outside of the tunnel, how it is = collected, etc=20 are outside the scope of the protocol.

What you want is a = standard way of=20 dealing with the data once it is passed through the tunnel. NEA is = purposely=20 generic about this to make it as flexible as possible. If you want to = define a=20 standard way to then pass that data to an IDS and figure out what to do, = great.=20 That would require another specification which would use NEA as = transport and as=20 a network admission control point.

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

Second=20 Life: Yehoo Newall

3D'Inactive'=20 src=3D"cid:640392717@03082007-0C88" width=3D16>"TS = Glassey"=20 <tglassey@earthlink.net>
                  "TS Glassey" = <tglassey@earthlink.net>=20

                  08/02/2007 09:52 = AM
=20
To
Frank Yeh Jr/Irvine/IBM@IBMUS
=20
cc
"Mike Fratto" <mfratto@gmail.com>,=20 <nea@ietf.org>, "Paul Sangster"=20 <Paul_Sangster@symantec.com>
=20
Subject
Re: [Nea] 03 comments - IDS as Posture=20 Collecotr

pardon the blue-sky rant here but... The real value from a=20 philosophical point I see for NEA is that it could be a collection point = for a=20 number of Policy Service tools, and that it can tie this in with a set = of=20 attestation practice models for running secured and reliable = infrastructure.=20 That said, the point is that there keenly is a need to handle the = stateful=20 compliance with 'pre-specified policy and configuration management' and = that=20 this is specific not only to just plugging a system into a network but = in=20 prefacing the connections of two distributed systems from untrusted = networks=20 together.

OK -- so=20 what does all that really mean? - Simple - it means that there in the = IETF's bag=20 of tricks needs to be a really cool messaging and policy communication = language=20 and protocol which can be used not only to qualify a machine for action = in an=20 environment, but also for operations as a pre-event transaction = qualification as=20 well. This possibly makes NEA it. The one and only qualifer and setup=20 infrastructure needed to bring machines in or take them out, and to have = applications use.

t.
----- Original Message -----=20
From: Frank = Yeh=20 Jr
To: TS Glassey
Cc: Mike = Fratto ; nea@ietf.org ; Paul=20 Sangster
Sent: Thursday, August 02, 2007 = 9:44=20 AM
Subject: Re: = [Nea] 03=20 comments - IDS as Posture Collecotr=20

Greetings,

Perhaps it would be useful to = separate things=20 based on what is being measured and where the measurements are taken and = validated.

For our purposes, there are essentially two types of=20 measurement_ state-based and behavior-based. The traditional IDS is=20 behavior-based. It does not really tell you anything about the state of = an=20 endpoint but tells you what it is doing on the network. Recent = introduction of=20 host-based IDS (AKA Behavioral FireWall AKA HIPS Host-Based Intrusion = Prevention=20 System) technology does not change the fact that behavior is being=20 measured.

Integrity measurements are traditionally about state = from a=20 configuration standpoint. What software is installed, how it is = configured, what=20 values are found in the system registry or environment variables are = examples of=20 state. This is the traditional thinking in the various camps that are = feeding=20 the NEA effort.

So there seems to be some confusion over the fact = that=20 some are proposing a tighter coupling with IDS's be built into the=20 protocol.

IMHO, this would be a useless extension for which = existing=20 protocols will serve perfectly well. There is no constraint on what is = being=20 measured, transported and verified. It is all simply data that relates = to a=20 single endpoint. If an endpoint has invalid state or is performing = illegal=20 actions, either of these should cause the endpoint to be kicked off or = denied=20 access to the network. There is nothing in the protocol that specifies = what=20 content is to be transferred in the tunnel created between the = measurement=20 collectors and the verifiers.

Furthermore, there is nothing in = the=20 current approach that precludes using an IDS on the verifier side and it = will be=20 just as easy to build an integrity verifier on an IDS as to build a new=20 interface to a new protocol. In either case the code has to be written = but will=20 only have to be done once. So an endpoint could simply be queried for = its MAC=20 Address which could be sent to an IDS with a simple "are there any = violations=20 found for this MAC" query. Based on what the IDS reports, the decision = can be=20 made. Why do we need anything else in the context of a network admission = (or=20 post admission) decision?

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

Second Life: Yehoo=20 Newall

3D'Inactive'=20 src=3D"cid:640392717@03082007-0C88" width=3D16>"TS = Glassey"=20 <tglassey@earthlink.net>
                                  "TS Glassey"=20 = <tglassey@earthlink.net>

                                  08/02/2007 07:41=20 = AM

          =
=20
To
"Mike Fratto"=20 <mfratto@gmail.com>
=20
cc
nea@ietf.org, Paul Sangster=20 <Paul_Sangster@symantec.com>
=20
Subject
Re: [Nea] 03 comments - IDS as = Posture=20 Collecotr

Mike - I agree with the idea... conceptually there are two = very=20 different
things going on here, and one of them is IDS centric and = the other=20 isnt,
that being the 'footprint' verification functionality of some = 'change=20
management/control' service. As to amending the wording, I think NEA = will=20
need to do both functions since they are both key aspects of an = ongoing=20
Integrity Of Operations constrol set which this clearly is=20 one.

Todd
----- Original Message -----
From: "Mike Fratto" = <mfratto@gmail.com>
To: "TS Glassey"=20 <tglassey@earthlink.net>
Cc: "Stefan Winter"=20 <stefan.winter@restena.lu>; <nea@ietf.org>; "Paul =
Sangster"=20 <Paul_Sangster@symantec.com>
Sent: Thursday, August 02, 2007 = 7:25=20 AM
Subject: Re: [Nea] 03 comments - IDS as Posture = Collecotr


>=20 Why not just clarify the language to indicate a "Host Based IDS"
> = instead=20 of "IDS"?
>
> Host based stuff is certainly within the = charter.=20 There are such
> beasties on the market and as part of posture = validation,=20 can be used
> in assessments in the same way an anti-virus or = patch=20 management
> product can.
>
> Besides, there is = nothing to be=20 gained by removing the reference and
> if removed, leaves a gap = that is=20 open to interpretation.
>
> On 8/2/07, TS Glassey=20 <tglassey@earthlink.net> wrote:
>> This is then about=20 Configuration Management as well as Integrity?
>>
>>=20 T
>> ----- Original Message -----
>> From: "Stefan = Winter"=20 <stefan.winter@restena.lu>
>> To:=20 <nea@ietf.org>
>> Cc: "Paul Sangster"=20 <Paul_Sangster@symantec.com>
>> Sent: Thursday, August = 02, 2007=20 2:02 AM
>> Subject: Re: [Nea] 03 comments - IDS as Posture=20 Collecotr
>>
>>
>> >=20 _______________________________________________
>> > Nea = mailing=20 list
>> > Nea@ietf.org
>> > https://www1.ietf.org/mailman/listinfo/nea
>> >
>>
>>
>>=20 _______________________________________________
>> Nea mailing=20 list
>> Nea@ietf.org
>> https://www1.ietf.org/mailman/listinfo/nea
>>=20



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

------_=_NextPart_002_01C7D5F3.C781514F-- ------_=_NextPart_001_01C7D5F3.C781514F Content-Type: image/gif; name="graycol.gif" Content-Transfer-Encoding: base64 Content-ID: <640392717@03082007-0C7A> Content-Description: graycol.gif Content-Location: graycol.gif R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 ------_=_NextPart_001_01C7D5F3.C781514F Content-Type: image/gif; name="ecblank.gif" Content-Transfer-Encoding: base64 Content-ID: <640392717@03082007-0C81> Content-Description: ecblank.gif Content-Location: ecblank.gif R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 ------_=_NextPart_001_01C7D5F3.C781514F Content-Type: image/gif; name="10639620.gif" Content-Transfer-Encoding: base64 Content-ID: <640392717@03082007-0C88> Content-Description: 10639620.gif Content-Location: 10639620.gif R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 ------_=_NextPart_001_01C7D5F3.C781514F Content-Type: image/gif; name="10471753.gif" Content-Transfer-Encoding: base64 Content-ID: <640392717@03082007-0C8F> Content-Description: 10471753.gif Content-Location: 10471753.gif R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 ------_=_NextPart_001_01C7D5F3.C781514F-- --===============0628932228== 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 --===============0628932228==-- From nea-bounces@ietf.org Sat Aug 04 16:05: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 1IHPsR-00054F-6W; Sat, 04 Aug 2007 16:05:31 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IHPsQ-000548-3x for nea-confirm+ok@megatron.ietf.org; Sat, 04 Aug 2007 16:05:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHPsP-000540-Qe for nea@ietf.org; Sat, 04 Aug 2007 16:05:29 -0400 Received: from smtp3.su.se ([130.237.93.228]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IHPsP-00086K-BF for nea@ietf.org; Sat, 04 Aug 2007 16:05:29 -0400 Received: from localhost (localhost [127.0.0.1]) by smtp3.su.se (Postfix) with ESMTP id 692EE3BEF1; Sat, 4 Aug 2007 22:05:28 +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 31755-01-4; Sat, 4 Aug 2007 22:05:28 +0200 (CEST) Received: from [10.0.0.11] (ua-83-227-179-169.cust.bredbandsbolaget.se [83.227.179.169]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp3.su.se (Postfix) with ESMTP id A7AA03BED4; Sat, 4 Aug 2007 22:05:23 +0200 (CEST) Message-ID: <46B4DC13.4030601@it.su.se> Date: Sat, 04 Aug 2007 22:05:39 +0200 From: Leif Johansson User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Mike Fratto Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr References: <46A4FE22.8020808@it.su.se> <46A534B2.9060404@it.su.se> <200708021102.53553.stefan.winter@restena.lu> <002f01c7d510$222b3b00$6501a8c0@tsg1> 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=-2.285 tagged_above=-99 required=7 tests=[AWL=0.027, BAYES_00=-2.312] X-Spam-Level: X-Spam-Score: -4.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 Mike Fratto wrote: > Why not just clarify the language to indicate a "Host Based IDS" > instead of "IDS"? > I agree. I do believe NEA will eventually have to revisit this stuff but as Stephen Hanna pointed out it is outside the charter for now. Cheers Leif _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Sun Aug 05 19:23: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 1IHpRO-0003vg-P3; Sun, 05 Aug 2007 19:23:18 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IHpRN-0003vb-RG for nea-confirm+ok@megatron.ietf.org; Sun, 05 Aug 2007 19:23:17 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IHpRN-0003vT-H4 for nea@ietf.org; Sun, 05 Aug 2007 19:23:17 -0400 Received: from elasmtp-masked.atl.sa.earthlink.net ([209.86.89.68]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IHpRN-0006Kr-5W for nea@ietf.org; Sun, 05 Aug 2007 19:23:17 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=XbDqV2GhcdCo2HY6obnQEl3vBeVHVNcnXs/IMavOwJjLnmY2k0LG458gel5DFMY6; 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-masked.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IHpRL-0001kY-04; Sun, 05 Aug 2007 19:23:15 -0400 Message-ID: <002f01c7d7b7$9b0e6f70$174f7d40@home.glassey.com> From: "todd glassey" To: "Leif Johansson" , "Mike Fratto" References: <46A4FE22.8020808@it.su.se> <46A534B2.9060404@it.su.se> <200708021102.53553.stefan.winter@restena.lu> <002f01c7d510$222b3b00$6501a8c0@tsg1> <46B4DC13.4030601@it.su.se> Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr Date: Sun, 5 Aug 2007 16:07:30 -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: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec7908f6488c5215adff86aaeaf220a019fb350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.125.79.23 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 - all... After re-reading the charter I want to propose before we go too much farther that we come to some conclusions about where the charter will go, so while we are building the lower levels of this animal, we dont build Legs where Arms are supposed to go. Todd ----- Original Message ----- From: "Leif Johansson" To: "Mike Fratto" Cc: "TS Glassey" ; ; "Paul Sangster" Sent: Saturday, August 04, 2007 1:05 PM Subject: Re: [Nea] 03 comments - IDS as Posture Collecotr > Mike Fratto wrote: >> Why not just clarify the language to indicate a "Host Based IDS" >> instead of "IDS"? >> > I agree. I do believe NEA will eventually have to revisit this > stuff but as Stephen Hanna pointed out it is outside the > charter for now. > > Cheers Leif > _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Aug 06 16:33: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 1II9GX-0007vT-8I; Mon, 06 Aug 2007 16:33:25 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1II9GW-0007vJ-9Y for nea-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 16:33:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1II9GV-0007vB-V0 for nea@ietf.org; Mon, 06 Aug 2007 16:33:24 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1II9GV-0004Hs-L0 for nea@ietf.org; Mon, 06 Aug 2007 16:33:23 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 06 Aug 2007 16:33:23 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CAJ8it0ZAZnme/2dsb2JhbAA X-IronPort-AV: i="4.19,225,1183348800"; d="scan'208"; a="67229526:sNHT38278112" 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 l76KXNFI015112; Mon, 6 Aug 2007 16:33:23 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l76KX6jS012949; Mon, 6 Aug 2007 20:33:22 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Aug 2007 16:33:13 -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: Mon, 6 Aug 2007 16:33:12 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: REMINDER: NEA WG Last Call for comments on draft-ietf-nea-requirements-03.txt due Friday August 10 Thread-Index: AcfFV9ciT62KTbdtRUWiyMdbQAQskATEBleA From: "Susan Thomson \(sethomso\)" To: X-OriginalArrivalTime: 06 Aug 2007 20:33:13.0452 (UTC) FILETIME=[02DC82C0:01C7D869] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1382; t=1186432403; x=1187296403; 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:=20REMINDER=3A=20=20NEA=20WG=20Last=20Call=20for=20comments=20on =20draft-ietf-nea-requirements-03.txt=20due=20Friday=20August=2010 |Sender:=20 |To:=20; bh=bq1evO/y8nrhYUza0nEZopLfAeCmkfg2Xq/InsgbItw=; b=I/WG1+B7a2F0V70YJQBWOn4qH/LGATMqSK8ZTSKNvd/OXZrZ5OlAod1MB/35eJT4i3YYzsnH /b5QFaAzkuBl2gpw+I1esCXXja3b/u6L6d7KaVnApNs9IRdIRigMNtI/; 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: 52e1467c2184c31006318542db5614d5 Cc: Tim Polk Subject: [Nea] REMINDER: NEA WG Last Call for comments on draft-ietf-nea-requirements-03.txt due Friday August 10 X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org This is a reminder that the WG Last Call review period for the NEA requirements draft ends this week on Friday, August 10. All NEA WG members are requested to review this document thoroughly and provide comments to the NEA mailing list at this time. See original announcement with pointer to requirements draft below. Thanks Susan=20 -----Original Message----- From: Susan Thomson (sethomso)=20 Sent: Friday, July 13, 2007 10:12 AM To: nea@ietf.org Cc: Stephen Hanna; Tim Polk Subject: NEA WG Last Call for comments on draft-ietf-nea-requirements-03.txt 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 Aug 06 17:56: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 1IIAYw-0007xW-AD; Mon, 06 Aug 2007 17:56:30 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IIAYv-0007tp-CA for nea-confirm+ok@megatron.ietf.org; Mon, 06 Aug 2007 17:56:29 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIAYu-0007rW-Uz for nea@ietf.org; Mon, 06 Aug 2007 17:56:29 -0400 Received: from elasmtp-masked.atl.sa.earthlink.net ([209.86.89.68]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIAYu-00071J-Bf for nea@ietf.org; Mon, 06 Aug 2007 17:56:28 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Oc1zH3wbTGGkbYlLcqR864FBobusP3Nlm35koKwo9sd1MWMLAZfRzm1bDLOpWqbK; 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-masked.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IIAYr-0007yW-G5; Mon, 06 Aug 2007 17:56:25 -0400 Message-ID: <026001c7d874$a618fd50$174f7d40@home.glassey.com> From: "todd glassey" To: "Susan Thomson \(sethomso\)" , References: Subject: Re: [Nea] REMINDER: NEA WG Last Call for comments ondraft-ietf-nea-requirements-03.txt due Friday August 10 Date: Mon, 6 Aug 2007 14:56:25 -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: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79df20563fb49d5826d6270d1aaa02cf9b350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.125.79.23 X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: Tim Polk X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Susan - Dr. Tim: within the scope of the charter the document seems OK - it may have a number of process or scenario specific goochies in it but generally it seems fine. The larger problem is the issue of end-use and ultimate use models which don't exist and are not in the document making this yet another of those "use me anyway you want to" type affairs, and that makes auditing these technologies painful. I suggest that several very specific end-use models are put in place before any more work on NEA is done and the implementation docs all play to them. Without that this is yet another wondrous goodie in search of a problem to solve and we have too many of those now anyway. Todd ----- Original Message ----- From: "Susan Thomson (sethomso)" To: Cc: "Tim Polk" Sent: Monday, August 06, 2007 1:33 PM Subject: [Nea] REMINDER: NEA WG Last Call for comments ondraft-ietf-nea-requirements-03.txt due Friday August 10 This is a reminder that the WG Last Call review period for the NEA requirements draft ends this week on Friday, August 10. All NEA WG members are requested to review this document thoroughly and provide comments to the NEA mailing list at this time. See original announcement with pointer to requirements draft below. Thanks Susan -----Original Message----- From: Susan Thomson (sethomso) Sent: Friday, July 13, 2007 10:12 AM To: nea@ietf.org Cc: Stephen Hanna; Tim Polk Subject: NEA WG Last Call for comments on draft-ietf-nea-requirements-03.txt 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 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Aug 09 18:33:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJGYu-00058m-IT; Thu, 09 Aug 2007 18:33:01 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IJFXP-0004rK-Ip for nea-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 17:27:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJFXP-0004q4-8v for nea@ietf.org; Thu, 09 Aug 2007 17:27:23 -0400 Received: from rimp1.nist.gov ([129.6.16.226] helo=smtp.nist.gov) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJFXN-0005tv-MG for nea@ietf.org; Thu, 09 Aug 2007 17:27:23 -0400 Received: from [192.168.15.166] (bethany.ncsl.nist.gov [129.6.52.15]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id l79LREYt017634; Thu, 9 Aug 2007 17:27:14 -0400 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <891FCE87-9592-4658-9FA1-95A0DB756AD5@nist.gov> Content-Transfer-Encoding: 7bit From: Tim Polk Date: Thu, 9 Aug 2007 17:27:15 -0400 To: nea@ietf.org X-Mailer: Apple Mail (2.752.2) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov X-Spam-Score: 0.0 (/) X-Scan-Signature: e472ca43d56132790a46d9eefd95f0a5 X-Mailman-Approved-At: Thu, 09 Aug 2007 18:32:59 -0400 Subject: [Nea] comments on draft-ietf-nea-requirements-03 X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Folks, I have a number of comments on the nea-requirements draft. Overall, I believe this is a strong document but I did have a number of issues/ questions. Many are purely editorial, including a few fussy writing quirks of mine, but there are some technical issues as well. The issues are presented in the order I encountered them in the document... Section 1.0 Overview One nit in the last paragraph. Security Considerations are last in the document, but the text implies that they precede the requirements for protocols. I would prefer to see this text parallel the actual document structure. Section 2.0 Terminology Numerous terms are defined in terms of Posture Collectors and Posture Validators, but these terms are not defined until section 5. Component - I think this definition is weak, particularly when you consider the use of Posture Collector. Section 4.0 Problem Statement Editorial nit: The first paragraph of this section should probably be separated into two paragraphs. The first sentence presents an idea that applies to all remaining paragraphs. The remaining sentences present the first of the "several purposes". Bigger Editorial nit: Upon reading the problem statement, I found it difficult to determine how many different purposes were being presented. Clearly text as each distinct purpose is introduced might be helpful. I interpreted the text as defining five purposes: (1) facilitate endpoint compliance [described in the first three paragraphs]; (2) re-assessment [described in the fourth paragraph]; (3) verify asset information [fifth paragraph]; (4) provide posture assessment for network connection [first sentence of the sixth paragraph]; and (5) provide posture assessment for application access [second sentence of the sixth paragraph]. Is this correct? Perhaps the sixth paragraph should become two paragraphs to more clearly delineate there are two purposes. If these are variants, we need an introductory sentence. 5.1.1.1 Posture Collector paragraph 2, sentence 3: The example given for a dynamic identifier is "assigned by the Posture Broker client upon registration". The example for static identifier is "provided during registration". What is the difference? Provided by whom/what? Perhaps the static identifier example should be "provided upon installation"? 5.1.1.2 Posture Broker Client This is a nit, but I believe that the posture broker client must generate error messages when no posture collector exists on the system to handle a particular attribute request. Perhaps this is implied elsewhere, but I think it is worth stating... Question 1: Section 9.2 introduces the concept of interrogating an endpoint to determine the OS, etc. Are these types of global information requests handled by the posture collector or the posture broker client? I couldn't sort it out from the text, and I believe this is an important issue. Question 2: Does the WG envision a set of result attributes that are mandatory to support for a posture broker client? This is implied by the fourth bullet... 5.2.2 Posture Broker Protocol The PB protocol does not include a requirement for cryptographic protection of posture attributes, since this can be handled by the PA protocol when they are transmitted between the posture collector and posture validator. However, the global assessment decisions are transmitted from PB Server to PB Client... and there is no discussion of protecting its own information. Has the working group considered whether this information needs protecting, or is this assumed to be the role of the PT protocol? 5.3.1, second bullet Editorial nit: The second sentence has a lot of clauses, and it is easy to lose the thread. It might be clearer if it was reworded to explicitly state the two cases. I would suggest something like: These attributes consist of either (a) NEA Server provided attributes (state) describing a prior evaluation (e.g. opaque to endpoint, signed, time stamped items stating specific results) or (b) NEA Client identity information used by the NEA Server to locate state about prior decisions (e.g. system-bound cookie). The text above assumes that these are the only types of assertion attributes. If that may not be the case, then we should state them as examples: Examples of assertion attributes include a) NEA Server provided attributes (state) describing a prior evaluation (e.g. opaque to endpoint, signed, time stamped items stating specific results) and (b) NEA Client identity information used by the NEA Server to locate state about prior decisions (e.g. system-bound cookie). Section 6. The example seems to assume that the OS is known. Stating that up front would be helpful. Figure 2 and the text in 6.1.1.2 should be tightly coupled. The text contains 13 numbered steps, but the figure has either 14 or 17 steps (depending on how I count the flows between the pt client and pt broker server). Section 7.1 Requirement C-1 Are updates to previously reported posture information actually part of the same dialog? This would seem to be a separate protocol run to me. IMHO, sentences 1 & 2 seem to specify a different requirement than sentences 3 & 4. Requirement C-3 Why is this a SHOULD instead of a MUST? This document includes scenarios initiaited by the server and by the client. Isn't is a requirement for the NEA protocols to support both? 7.3 Requirement PB-4 If the posture broker needs to protect global assessment information (see comments on 5.2.2), then MAY is too weak. MUST or possibly MAY would be needed... 8.1.2 The last sentence in this section seems to establish a requirement for the NEA protocols. This material needs to be presented earlier and represented as a section 7 requirement. Section 9.2, next to last paragraph: "For example, an enterprise might ask about the OS version in the initial message dialog and after learning the system is a Linux system, ask for a different/smaller set of attributes specific to Linux then it would if the endpoint was a Windows system. " This text answered a nagging question for me, when I encountered it. While I was glad to learn how the wg intended to address the OS identification problem, page 48 was a little too late. I believe the possibility of a bootstrapping ought to be addressed earlier, and we should clearly state which component (PB Client or PC?) resolves this type of question... Thanks, Tim Polk _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Aug 09 19:25:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJHNE-0001Rw-Ng; Thu, 09 Aug 2007 19:25:00 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IJHNA-0001Qw-RQ for nea-confirm+ok@megatron.ietf.org; Thu, 09 Aug 2007 19:24:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJHNA-0001Qn-G4 for nea@ietf.org; Thu, 09 Aug 2007 19:24:56 -0400 Received: from elasmtp-masked.atl.sa.earthlink.net ([209.86.89.68]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJHN9-0003YF-MA for nea@ietf.org; Thu, 09 Aug 2007 19:24:56 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=EMiYx1nHjhbUmEJwJzzMj/WMW6/KgksE4rz61Cv9+qq7IarnmGDBdbuC0+ojtZjS; h=Received:Message-ID:From:To: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-masked.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IJHN9-00059P-0i; Thu, 09 Aug 2007 19:24:55 -0400 Message-ID: <017f01c7dadc$7e792f80$174f7d40@home.glassey.com> From: "todd glassey" To: "Tim Polk" , References: <891FCE87-9592-4658-9FA1-95A0DB756AD5@nist.gov> Subject: Re: [Nea] comments on draft-ietf-nea-requirements-03 Date: Thu, 9 Aug 2007 16:24:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response 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: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79808be261e51663d570683b24ca53d207350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.125.79.23 X-Spam-Score: 0.0 (/) X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e 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 ----- Original Message ----- From: "Tim Polk" To: Sent: Thursday, August 09, 2007 2:27 PM Subject: [Nea] comments on draft-ietf-nea-requirements-03 > Folks, > > I have a number of comments on the nea-requirements draft. Overall, I > believe this is a strong document but I did have a number of issues/ > questions. > Many are purely editorial, including a few fussy writing quirks of mine, > but there are some technical issues as well. > > The issues are presented in the order I encountered them in the > document... > > Section 1.0 Overview > > One nit in the last paragraph. Security Considerations are last in > the document, but the text implies that they precede the requirements > for protocols. I would prefer to see this text parallel the actual > document structure. Violates the RFC document format template. If this is OK then its OK, but the Security Considerations are where they are based on the templates design. > > Section 2.0 Terminology > > Numerous terms are defined in terms of Posture Collectors and Posture > Validators, but these terms are not defined until section 5. Agreed but here again - this is a writing style issue. > > Component - I think this definition is weak, particularly when you > consider the use of Posture Collector. > > Section 4.0 Problem Statement > > Editorial nit: The first paragraph of this section should probably be > separated into two paragraphs. The first sentence presents an idea > that applies to all remaining paragraphs. The remaining sentences > present the first of the "several purposes". > > Bigger Editorial nit: Upon reading the problem statement, I found it > difficult to determine how many different purposes were being presented. > Clearly text as each distinct purpose is introduced might be helpful. > > I interpreted the text as defining five purposes: > (1) facilitate endpoint compliance [described in the first three > paragraphs]; > (2) re-assessment [described in the fourth paragraph]; > (3) verify asset information [fifth paragraph]; > (4) provide posture assessment for network connection [first sentence > of the sixth paragraph]; and > (5) provide posture assessment for application access [second sentence > of the sixth paragraph]. > > Is this correct? Perhaps the sixth paragraph should become two > paragraphs to more clearly delineate there are two purposes. If these > are variants, we need an introductory sentence. > > 5.1.1.1 Posture Collector > > paragraph 2, sentence 3: The example given for a dynamic identifier > is "assigned by the Posture Broker client upon registration". The > example for static identifier is "provided during registration". > What is the difference? Provided by whom/what? Perhaps the static > identifier example should be "provided upon installation"? > > 5.1.1.2 Posture Broker Client > > This is a nit, but I believe that the posture broker client must > generate error messages when no posture collector exists on the > system to handle a particular attribute request. Perhaps this is > implied elsewhere, but I think it is worth stating... > > Question 1: Section 9.2 introduces the concept of interrogating an > endpoint to determine the OS, etc. Are these types of global > information requests handled by the posture collector or the > posture broker client? I couldn't sort it out from the text, and > I believe this is an important issue. > > Question 2: Does the WG envision a set of result attributes that > are mandatory to support for a posture broker client? This is > implied by the fourth bullet... > > 5.2.2 Posture Broker Protocol > > The PB protocol does not include a requirement for cryptographic > protection of posture attributes, since this can be handled by the > PA protocol when they are transmitted between the posture collector > and posture validator. However, the global assessment decisions are > transmitted from PB Server to PB Client... and there is no discussion > of protecting its own information. Has the working group considered > whether this information needs protecting, or is this assumed to be > the role of the PT protocol? > > 5.3.1, second bullet > > Editorial nit: The second sentence has a lot of clauses, and it is > easy to lose the thread. It might be clearer if it was reworded to > explicitly state the two cases. I would suggest something like: > > These attributes consist of either (a) NEA Server provided attributes > (state) describing a prior evaluation (e.g. opaque to > endpoint, signed, time stamped items stating specific results) > or (b) NEA Client identity information used by > the NEA Server to locate state about prior decisions (e.g. > system-bound cookie). > > The text above assumes that these are the only types of assertion > attributes. If that may not be the case, then we should state them > as examples: > > Examples of assertion attributes include a) NEA Server provided > attributes (state) describing a prior evaluation (e.g. opaque to > endpoint, signed, time stamped items stating specific results) > and (b) NEA Client identity information used by > the NEA Server to locate state about prior decisions (e.g. > system-bound cookie). > > Section 6. > > The example seems to assume that the OS is known. Stating that up > front would be helpful. > > Figure 2 and the text in 6.1.1.2 should be tightly coupled. The text > contains 13 numbered steps, but the figure has either 14 or 17 > steps (depending on how I count the flows between the pt client and > pt broker server). > > Section 7.1 > > Requirement C-1 > > Are updates to previously reported posture information actually > part of the same dialog? This would seem to be a separate protocol > run to me. IMHO, sentences 1 & 2 seem to specify a different > requirement than sentences 3 & 4. > > Requirement C-3 > > Why is this a SHOULD instead of a MUST? This document includes > scenarios initiaited by the server and by the client. Isn't is a > requirement for the NEA protocols to support both? > > 7.3 > > Requirement PB-4 > > If the posture broker needs to protect global assessment information > (see comments on 5.2.2), then MAY is too weak. MUST or possibly MAY > would be needed... > > 8.1.2 > > The last sentence in this section seems to establish a requirement for > the NEA protocols. This material needs to be presented earlier and > represented as a section 7 requirement. > > Section 9.2, next to last paragraph: > > "For example, an enterprise might ask about the OS > version in the initial message dialog and after learning the > system is a Linux system, ask for a different/smaller set of > attributes specific to Linux then it would if the endpoint was a > Windows system. " > > This text answered a nagging question for me, when I encountered it. > While I was glad to learn how the wg intended to address the OS > identification problem, page 48 was a little too late. I believe > the possibility of a bootstrapping ought to be addressed earlier, and we > should clearly state which component (PB Client or PC?) resolves > this type of question... > > Thanks, > > Tim Polk > > > _______________________________________________ > 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 Aug 10 13:45:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJYXy-0000Ft-S0; Fri, 10 Aug 2007 13:45:14 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IJYXy-0000Bp-2m for nea-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 13:45:14 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IJYXx-00005F-CU for nea@ietf.org; Fri, 10 Aug 2007 13:45:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJYWH-0005Fd-UD for nea@ietf.org; Fri, 10 Aug 2007 13:43:29 -0400 Received: from sccrmhc15.comcast.net ([204.127.200.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJYWG-0003IS-MS for nea@ietf.org; Fri, 10 Aug 2007 13:43:29 -0400 Received: from hp (c-69-140-232-168.hsd1.md.comcast.net[69.140.232.168]) by comcast.net (sccrmhc15) with SMTP id <2007081017432801500pe8fie>; Fri, 10 Aug 2007 17:43:28 +0000 From: "Chris Salter" To: Date: Fri, 10 Aug 2007 13:43:26 -0400 Message-ID: <002a01c7db75$f4f63060$9a00a8c0@HP> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfbdfTXIaYZH7VITzOfX9PmEhc9cA== X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 X-TMDA-Confirmed: Fri, 10 Aug 2007 13:45:13 -0400 Subject: [Nea] comments on requirements X-BeenThere: nea@ietf.org X-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="===============1743201084==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============1743201084== Content-Type: multipart/alternative; boundary="----=_NextPart_000_002B_01C7DB54.6DE49060" This is a multi-part message in MIME format. ------=_NextPart_000_002B_01C7DB54.6DE49060 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit We thought that overall the document was very clear and well written and we have no strong criticisms of the requirements. We do have one concern, however. As we were reviewing, one thing we tried to keep in our minds is what would be needed in order to provide maximal interoperability between vendors. To us, this would mean something along the lines of being able to support a variety of operating systems on our network, being able to use a different NEA client for each OS, and having them all talk to the same NEA server. We would like to be able to use an access policy such as "Must have a firewall turned on, an anti-virus program running, and signatures must have been updated within the last 24 hours" without specifying which firewall or antivirus program the clients must use. It seems to us that the use of a standard PA protocol, combined with a set of basic, standardized posture attributes that every NEA client and server understands, will make it possible to use a generic policy as described above. The use of a standard PB protocol that every NEA client and server understands will allow each client to package its integrity measurements in a format that the server will understand, parse and distribute responses from the server, and vice versa. The NEA document defined these protocols clearly, and we're happy to see the emphasis on standardizing them. Our concern is the lack of emphasis on standardizing PT. The document's scope section says that, when PA and PB are used with standard lower layer protocols, they provide interoperability. This may be true, but what lower layer protocols will be used? Even if an EAP method for transport of measurements is standardized and supported by all NEA components, a client and server must additionally support the same tunneled EAP method for authentication in order to be interoperable. There are examples today of different vendors who use the same access protocol (802.1x/RADIUS), but different tunneled EAP methods, and thus cannot interoperate. We would like to see language clearly stating that standardization of both an authentication protocol and a measurement transport protocol is required for true interoperability. Lauren Giroux Chris Salter ------=_NextPart_000_002B_01C7DB54.6DE49060 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We thought that overall the document was very clear and well = written and we have no strong criticisms of the requirements. We do have one = concern, however.

 

As we were reviewing, one thing we tried to = keep in our minds is what would be needed in order to provide maximal = interoperability between vendors.  To us, this would mean something along the lines = of being able to support a variety of operating systems on our network, = being able to use a different NEA client for each OS, and having them all talk to = the same NEA server.  We would like to be able to use an access policy such = as "Must have a firewall turned on, an anti-virus program running, and signatures must have been updated within the last 24 = hours" without specifying which firewall or antivirus program the clients must = use.

 

It seems to us that the use of a standard PA = protocol, combined with a set of basic, standardized posture attributes that every = NEA client and server understands, will make it possible to use a generic = policy as described above.  The use of a standard PB protocol that every NEA = client and server understands will allow each client to package its integrity measurements in a format that the server will understand, parse and = distribute responses from the server, and vice versa.  =

 

The NEA document defined these protocols = clearly, and we’re happy to see the emphasis on standardizing them.  Our = concern is the lack of emphasis on standardizing PT.  The document’s = scope section says that, when PA and PB are used with standard lower layer = protocols, they provide interoperability.  This may be true, but what lower = layer protocols will be used?  

 

Even if an EAP method for transport of measurements is = standardized and supported by all NEA components, a client and server must additionally = support the same tunneled EAP method for authentication in order to be = interoperable. There are examples today of different vendors who use the same access = protocol (802.1x/RADIUS), but different tunneled EAP methods, and thus cannot interoperate.  We would like to see language clearly stating that standardization of both an authentication protocol and a measurement = transport protocol is required for true = interoperability.

 

Lauren Giroux

Chris Salter

------=_NextPart_000_002B_01C7DB54.6DE49060-- --===============1743201084== 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 --===============1743201084==-- From nea-bounces@ietf.org Fri Aug 10 13:49: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 1IJYcR-0000xa-UZ; Fri, 10 Aug 2007 13:49:51 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IJYFk-0003Pv-9v for nea-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 13:26:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJYFj-0003OZ-IV for nea@ietf.org; Fri, 10 Aug 2007 13:26:23 -0400 Received: from rimp1.nist.gov ([129.6.16.226] helo=smtp.nist.gov) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJYFh-0002wK-Ij for nea@ietf.org; Fri, 10 Aug 2007 13:26:23 -0400 Received: from [192.168.15.166] (bethany.ncsl.nist.gov [129.6.52.15]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id l7AHQBxd003440; Fri, 10 Aug 2007 13:26:11 -0400 In-Reply-To: <017f01c7dadc$7e792f80$174f7d40@home.glassey.com> References: <891FCE87-9592-4658-9FA1-95A0DB756AD5@nist.gov> <017f01c7dadc$7e792f80$174f7d40@home.glassey.com> Mime-Version: 1.0 (Apple Message framework v752.2) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tim Polk Subject: Re: [Nea] comments on draft-ietf-nea-requirements-03 Date: Fri, 10 Aug 2007 13:26:09 -0400 To: todd glassey X-Mailer: Apple Mail (2.752.2) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 X-Mailman-Approved-At: Fri, 10 Aug 2007 13:49:50 -0400 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Todd, On Aug 9, 2007, at 7:24 PM, todd glassey wrote: > > ----- Original Message ----- From: "Tim Polk" > To: > Sent: Thursday, August 09, 2007 2:27 PM > Subject: [Nea] comments on draft-ietf-nea-requirements-03 > > >> Folks, >> >> I have a number of comments on the nea-requirements draft. >> Overall, I >> believe this is a strong document but I did have a number of >> issues/ questions. >> Many are purely editorial, including a few fussy writing quirks of >> mine, >> but there are some technical issues as well. >> >> The issues are presented in the order I encountered them in the >> document... >> >> Section 1.0 Overview >> >> One nit in the last paragraph. Security Considerations are last in >> the document, but the text implies that they precede the requirements >> for protocols. I would prefer to see this text parallel the actual >> document structure. > > Violates the RFC document format template. If this is OK then its > OK, but the Security Considerations are where they are based on the > templates design. > Thanks for pointing this out, since I was unintentionally vague here. I am not asking for any change in document structure, or departures from the normal RFC structure. I just want the front matter to parallel the document structure as it exists... [rest of quoted text deleted.] Thanks, Tim _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Aug 10 14:19: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 1IJZ5Y-0002iK-BW; Fri, 10 Aug 2007 14:19:56 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IJZ5X-0002i7-Rb for nea-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 14:19:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJZ5X-0002hz-Gl for nea@ietf.org; Fri, 10 Aug 2007 14:19:55 -0400 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJZ5X-0002KE-01 for nea@ietf.org; Fri, 10 Aug 2007 14:19:55 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=DjomhzUwa2SVSvUL4ww4ezbiUoZ9hP9eNGsVicN5oR79jPpMY+RPxvzpqFcWxBnF; 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-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IJZ5W-0007oX-95; Fri, 10 Aug 2007 14:19:54 -0400 Message-ID: <020101c7db7b$0da31380$174f7d40@home.glassey.com> From: "todd glassey" To: "Tim Polk" References: <891FCE87-9592-4658-9FA1-95A0DB756AD5@nist.gov> <017f01c7dadc$7e792f80$174f7d40@home.glassey.com> Subject: Re: [Nea] comments on draft-ietf-nea-requirements-03 Date: Fri, 10 Aug 2007 11:14:20 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response 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: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec794476414ac6333c4289799e431a4950a1350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.125.79.23 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Actually Tim you were right in noticing that the IETF Template is the culprit and that NEA and many security specific standards need those sections "up front" as it were. I just wanted to point out that 'one size doesn't fit all' per se. Perhaps also we should think of the Notation Style that the Court use when they allow Terms of Art (TOA) to be defined in their filings. This is neither overly complex nor painful, its just a minor style rule that says that any and all TOA's need to be defined in their first use in any document, and that any and all external references to TOA's also need to be defined PRIOR to their use in any standards process docs or IETF operations docs. This type of notation style would bring the IETF documents in-line with other standards processes and define one of the key tasks that the editor-service-provider is to render to the IETF for their booty. T. ----- Original Message ----- From: "Tim Polk" To: "todd glassey" Cc: Sent: Friday, August 10, 2007 10:26 AM Subject: Re: [Nea] comments on draft-ietf-nea-requirements-03 > Todd, > > On Aug 9, 2007, at 7:24 PM, todd glassey wrote: > >> >> ----- Original Message ----- From: "Tim Polk" >> To: >> Sent: Thursday, August 09, 2007 2:27 PM >> Subject: [Nea] comments on draft-ietf-nea-requirements-03 >> >> >>> Folks, >>> >>> I have a number of comments on the nea-requirements draft. Overall, I >>> believe this is a strong document but I did have a number of issues/ >>> questions. >>> Many are purely editorial, including a few fussy writing quirks of >>> mine, >>> but there are some technical issues as well. >>> >>> The issues are presented in the order I encountered them in the >>> document... >>> >>> Section 1.0 Overview >>> >>> One nit in the last paragraph. Security Considerations are last in >>> the document, but the text implies that they precede the requirements >>> for protocols. I would prefer to see this text parallel the actual >>> document structure. >> >> Violates the RFC document format template. If this is OK then its OK, >> but the Security Considerations are where they are based on the >> templates design. >> > > Thanks for pointing this out, since I was unintentionally vague here. I > am not asking > for any change in document structure, or departures from the normal RFC > structure. > I just want the front matter to parallel the document structure as it > exists... > > [rest of quoted text deleted.] > > Thanks, > > Tim _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Aug 10 14:19: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 1IJZ5Z-0002jG-JA; Fri, 10 Aug 2007 14:19:57 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IJZ5Y-0002iN-EW for nea-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 14:19:56 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJZ5Y-0002iC-25 for nea@ietf.org; Fri, 10 Aug 2007 14:19:56 -0400 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJZ5X-0002KF-1E for nea@ietf.org; Fri, 10 Aug 2007 14:19:55 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=EsPdj6bN1DzgMAKDEb6A9rdsFXXmvAd8t3s5HDPTvkVIegEITW7nZ/FkVJhJ5tKX; h=Received:Message-ID:From:To: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-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IJZ5W-0007oX-O4; Fri, 10 Aug 2007 14:19:54 -0400 Message-ID: <020201c7db7b$0deaa3d0$174f7d40@home.glassey.com> From: "todd glassey" To: "Chris Salter" , References: <002a01c7db75$f4f63060$9a00a8c0@HP> Subject: Re: [Nea] comments on requirements Date: Fri, 10 Aug 2007 11:19: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: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec794476414ac6333c42d34db3a9a047c841350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.125.79.23 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5b943e80df8c8cad631fd60298783617 Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1945292039==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============1945292039== Content-Type: multipart/alternative; boundary="----=_NextPart_000_01FE_01C7DB40.5FBD4D60" This is a multi-part message in MIME format. ------=_NextPart_000_01FE_01C7DB40.5FBD4D60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ----- Original Message -----=20 From: Chris Salter=20 To: nea@ietf.org=20 Sent: Friday, August 10, 2007 10:43 AM Subject: [Nea] comments on requirements We thought that overall the document was very clear and well written = and we have no strong criticisms of the requirements. We do have one = concern, however. =20 As we were reviewing, one thing we tried to keep in our minds is what = would be needed in order to provide maximal interoperability between = vendors. To us, this would mean something along the lines of being able = to support a variety of operating systems on our network, being able to = use a different NEA client for each OS, and having them all talk to the = same NEA server. =20 You are of course speaking of different vendor's NEA Client's = interoperating with different vendors NEA Servers... and that seems to = be the whole point of doing a standard, so I dont get how this was = missed. We would like to be able to use an access policy such as "Must have a = firewall turned on, an anti-virus program running, and signatures must = have been updated within the last 24 hours" without specifying which = firewall or antivirus program the clients must use. The define those objects as 'RESOURCES' and allow under policy the NEA = environment to create policy matrices that indicate acceptable policy = and control rules are implemented at runtime by those vendor's NEA = Client's. You will also need a uniform RESOURCE definition process, and = one for resource lookup... I suggested this with a PKI negotiation type sub-protocol to layer other = event or result-driven protocols on top of once several years ago but it = went no where. The key was to create a POLICY LANGUAGE and OBJECTS that = can be selected through that policy language and its implementing nodes. =20 It seems to us that the use of a standard PA protocol, combined with a = set of basic, standardized posture attributes that every NEA client and = server understands, will make it possible to use a generic policy as = described above. The use of a standard PB protocol that every NEA = client and server understands will allow each client to package its = integrity measurements in a format that the server will understand, = parse and distribute responses from the server, and vice versa. =20 =20 The NEA document defined these protocols clearly, and we're happy to = see the emphasis on standardizing them. Our concern is the lack of = emphasis on standardizing PT. The document's scope section says that, = when PA and PB are used with standard lower layer protocols, they = provide interoperability. This may be true, but what lower layer = protocols will be used? =20 The end-use models are once again key to this. Without specific use = models in place this is still a solution in search of a problem...=20 =20 Even if an EAP method for transport of measurements is standardized = and supported by all NEA components, a client and server must = additionally support the same tunneled EAP method for authentication in = order to be interoperable. There are examples today of different vendors = who use the same access protocol (802.1x/RADIUS), but different tunneled = EAP methods, and thus cannot interoperate. We would like to see = language clearly stating that standardization of both an authentication = protocol and a measurement transport protocol is required for true = interoperability. =20 Lauren Giroux Chris Salter -------------------------------------------------------------------------= ----- _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea ------=_NextPart_000_01FE_01C7DB40.5FBD4D60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
----- Original Message -----
From:=20 Chris=20 Salter
Sent: Friday, August 10, 2007 = 10:43=20 AM
Subject: [Nea] comments on=20 requirements

We thought that overall the document was = very clear=20 and well written and we have no strong criticisms of the requirements. = We do=20 have one concern, however.

 

As we were reviewing, one thing we tried to = keep in=20 our minds is what would be needed in order to provide maximal = interoperability=20 between vendors.  To us, this would mean something along the = lines of=20 being able to support a variety of operating systems on our network, = being=20 able to use a different NEA client for each OS, and having them all = talk to=20 the same NEA server. 

 

You are of course speaking of different = vendor's NEA=20 Client's interoperating with different vendors NEA Servers... and that = seems to=20 be the whole point of doing a standard, so I dont get how this was=20 missed.

 

 

We would like to be able to = use an access=20 policy such as "Must have a firewall turned on, an anti-virus program = running,=20 and signatures must have been updated within the last 24 = hours" without=20 specifying which firewall or antivirus program the clients must=20 use.

 

The define those = objects as=20 'RESOURCES' and allow under policy the NEA environment to create policy = matrices=20 that indicate acceptable policy and control rules are implemented at = runtime by=20 those vendor's NEA Client's. You will also need a uniform RESOURCE = definition=20 process, and one for resource lookup...

 

I suggested this with a PKI = negotiation=20 type sub-protocol to layer other event or result-driven protocols on top = of once=20 several years ago but it went no where. The key was to create a POLICY = LANGUAGE=20 and OBJECTS that can be selected through that policy language and its=20 implementing nodes.

 

 

It seems to us that the use = of a standard=20 PA protocol, combined with a set of basic, standardized posture = attributes=20 that every NEA client and server understands, will make it possible to = use a=20 generic policy as described above.  The use of a standard PB = protocol=20 that every NEA client and server understands will allow each client to = package=20 its integrity measurements in a format that the server will = understand, parse=20 and distribute responses from the server, and vice versa. =20

 

The NEA document defined = these protocols=20 clearly, and we=92re happy to see the emphasis on standardizing = them.  Our=20 concern is the lack of emphasis on standardizing PT.  The = document=92s=20 scope section says that, when PA and PB are used with standard lower = layer=20 protocols, they provide interoperability.  This may be true, but = what=20 lower layer protocols will be used?  

 

The end-use models are once = again key to=20 this. Without specific use models in place this is still a solution in = search of=20 a problem...

 

Even if an EAP method for transport of = measurements is=20 standardized and supported by all NEA components, a client and server = must=20 additionally support the same tunneled EAP method for authentication = in order=20 to be interoperable. There are examples today of different vendors who = use the=20 same access protocol (802.1x/RADIUS), but different tunneled EAP = methods, and=20 thus cannot interoperate.  We would like to see language clearly = stating=20 that standardization of both an authentication protocol and a = measurement=20 transport protocol is required for true=20 interoperability.

 

Lauren=20 Giroux

Chris=20 Salter

_______________________________________________
Nea mailing=20 = list
Nea@ietf.org
https://www1.ietf.org/mailman/listinfo/nea
------=_NextPart_000_01FE_01C7DB40.5FBD4D60-- --===============1945292039== 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 --===============1945292039==-- From nea-bounces@ietf.org Fri Aug 10 15:18: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 1IJa0H-00070a-6l; Fri, 10 Aug 2007 15:18:33 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IJa0G-00070U-1l for nea-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 15:18:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJa0F-00070M-OB for nea@ietf.org; Fri, 10 Aug 2007 15:18:31 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJa0E-0005G4-5H for nea@ietf.org; Fri, 10 Aug 2007 15:18:31 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 10 Aug 2007 12:18:29 -0700 X-IronPort-AV: i="4.19,245,1183359600"; d="scan'208"; a="8179363:sNHT34965120" 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 l7AJITR1004289; Fri, 10 Aug 2007 12:18:29 -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 l7AJIPFA019900; Fri, 10 Aug 2007 19:18:29 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); Fri, 10 Aug 2007 12:18:26 -0700 Received: from 171.69.75.24 ([171.69.75.24]) by xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) with Microsoft Exchange Server HTTP-DAV ; Fri, 10 Aug 2007 19:18:26 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Fri, 10 Aug 2007 12:18:25 -0700 Subject: Re: [Nea] comments on draft-ietf-nea-requirements-03 From: Kaushik Narayan To: Tim Polk , Message-ID: Thread-Topic: [Nea] comments on draft-ietf-nea-requirements-03 Thread-Index: Acfbgzkwd87z8kd2EdygrAAX8tamGQ== In-Reply-To: <891FCE87-9592-4658-9FA1-95A0DB756AD5@nist.gov> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 10 Aug 2007 19:18:26.0992 (UTC) FILETIME=[3A600B00:01C7DB83] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=13235; t=1186773509; x=1187637509; 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]=20comments=20on=20draft-ietf-nea-requirements-0 3 |Sender:=20; bh=Dq6ZPpCeW/2rd06NMVHP7gw/fBEa+mGc14XNSpiHFKs=; b=DdYe/gYhJqDeikc4HhdiHP1yXQDPtEGU7o+uV62WItJqpLikXHTdSoU/eSypy51UEjQXVFcv ia7cvZ6QBAXukICILFvG36SKqG3XWScMJBMtNUYnBVgg9ZEIiYtef1ri; Authentication-Results: sj-dkim-4; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -1.4 (-) X-Scan-Signature: fbe0995f04cc21309ef8614a2838e306 Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Hi Tim, Thanks for your comments. Please find my response inline. On 8/9/07 2:27 PM, "Tim Polk" wrote: > Folks, > > I have a number of comments on the nea-requirements draft. Overall, I > believe this is a strong document but I did have a number of issues/ > questions. > Many are purely editorial, including a few fussy writing quirks of mine, > but there are some technical issues as well. > > The issues are presented in the order I encountered them in the > document... > > Section 1.0 Overview > > One nit in the last paragraph. Security Considerations are last in > the document, but the text implies that they precede the requirements > for protocols. I would prefer to see this text parallel the actual > document structure. > Fair comment. The last sentence in the Overview section needs a bit of an edit to clarify the order. > Section 2.0 Terminology > > Numerous terms are defined in terms of Posture Collectors and Posture > Validators, but these terms are not defined until section 5. > The definitions currently cover all terms expect for the components of the NEA client and NEA server stack defined in the reference model. There might not be sufficient context before Section 2.0 to properly define terms such as Posture Collector, Posture Broker etc. We could certainly try to add these definitions for the sake of completeness. Did you find lack of these definitions in Section 2.0 as effecting the readability of the document. > Component - I think this definition is weak, particularly when you > consider the use of Posture Collector. > Agreed. We do plan to address the definition of Component in the next revision, the ambiguity of the current definition has been pointed out by other reviewers as well. > Section 4.0 Problem Statement > > Editorial nit: The first paragraph of this section should probably be > separated into two paragraphs. The first sentence presents an idea > that applies to all remaining paragraphs. The remaining sentences > present the first of the "several purposes". > > Bigger Editorial nit: Upon reading the problem statement, I found it > difficult to determine how many different purposes were being presented. > Clearly text as each distinct purpose is introduced might be helpful. Good comment. By and large one or more paragraphs try to elaborate on each purpose but there is clearly scope of further clarification. > > I interpreted the text as defining five purposes: > (1) facilitate endpoint compliance [described in the first three > paragraphs]; Paragraphs one & two describe the broader problem of checking endpoint compliance and why it is important for an IT organization. The second part of paragraph two delves into the ability to check compliance while trying to gain network access. Paragraph three talks about a couple of aspects that important to NEA technology but are currently out-of-scope of the document. These are the ability to remediate non-compliant endpoints and the use of network access technology to control access based on the level of compliance. > (2) re-assessment [described in the fourth paragraph]; > (3) verify asset information [fifth paragraph]; This is correct > (4) provide posture assessment for network connection [first sentence > of the sixth paragraph]; and > (5) provide posture assessment for application access [second sentence > of the sixth paragraph]. This is correct. Paragraph six actually tries to elaborate on the types of network access such as Layer2 (wired/wireless) & Layer 3 (IPSec & SSL VPNs). The second part of paragraph six talks about assessment during application access. It is a good suggestion to split the paragraph > > Is this correct? Perhaps the sixth paragraph should become two > paragraphs to more clearly delineate there are two purposes. If these > are variants, we need an introductory sentence. > > 5.1.1.1 Posture Collector > > paragraph 2, sentence 3: The example given for a dynamic identifier > is "assigned by the Posture Broker client upon registration". The > example for static identifier is "provided during registration". > What is the difference? Provided by whom/what? Perhaps the static > identifier example should be "provided upon installation"? You are right. Static identifiers are assigned to specific Posture Collectors prior to the software being installed. The Posture collectors pass up these identifiers to the Posture Broker Client during registration. In case of Dynamic identifiers, they are generated during the registration process. We will update the text to clarify this. > > 5.1.1.2 Posture Broker Client > > This is a nit, but I believe that the posture broker client must > generate error messages when no posture collector exists on the > system to handle a particular attribute request. Perhaps this is > implied elsewhere, but I think it is worth stating... This is implicit and should probably be described in the protocol specification since there are a multitude of PA, PB & PT error conditions that have not been described since this is a requirements document. > > Question 1: Section 9.2 introduces the concept of interrogating an > endpoint to determine the OS, etc. Are these types of global > information requests handled by the posture collector or the > posture broker client? I couldn't sort it out from the text, and > I believe this is an important issue. > The thinking has been that there would be a core/standard schema which would contain attributes such as OS type. Although it is not clearly spelt out the thinking has been that collection of attributes including the OS type would be a PA function and would be handled by a collector. We will add text to the reference model to clarify this. > Question 2: Does the WG envision a set of result attributes that > are mandatory to support for a posture broker client? This is > implied by the fourth bullet... > Yes. The document talks about the global posture assessment attribute which is mandatory to support for posture broker clients and servers. > 5.2.2 Posture Broker Protocol > > The PB protocol does not include a requirement for cryptographic > protection of posture attributes, since this can be handled by the > PA protocol when they are transmitted between the posture collector > and posture validator. However, the global assessment decisions are > transmitted from PB Server to PB Client... and there is no discussion > of protecting its own information. Has the working group considered > whether this information needs protecting, or is this assumed to be > the role of the PT protocol? > The PB protocol does include cryptographic protection but it is not mandatory (the requirement is a MAY). The assumption is that crypto protection provided by the PT protocol would be sufficient for most implementations but implementations may decide to implement crypto protection at the PB layer as well. This is especially relevant when the Posture Transport Server and Posture Broker Server are not co-located and need to communicate over-the-wire. As far as need for protection for the PB attributes, the global assessment decision is an attribute that needs to be both integrity and confidentiality protected and there could additional PB attributes in the future that need protection. > 5.3.1, second bullet > > Editorial nit: The second sentence has a lot of clauses, and it is > easy to lose the thread. It might be clearer if it was reworded to > explicitly state the two cases. I would suggest something like: > > These attributes consist of either (a) NEA Server provided attributes > (state) describing a prior evaluation (e.g. opaque to > endpoint, signed, time stamped items stating specific results) > or (b) NEA Client identity information used by > the NEA Server to locate state about prior decisions (e.g. > system-bound cookie). > > The text above assumes that these are the only types of assertion > attributes. If that may not be the case, then we should state them > as examples: > > Examples of assertion attributes include a) NEA Server provided > attributes (state) describing a prior evaluation (e.g. opaque to > endpoint, signed, time stamped items stating specific results) > and (b) NEA Client identity information used by > the NEA Server to locate state about prior decisions (e.g. > system-bound cookie). Good suggestion. We will edit the text. I agree that the usage of assertion attributes are better stated as examples to allow for additional types of assertions to be included in the future. > > Section 6. > > The example seems to assume that the OS is known. Stating that up > front would be helpful. > > Figure 2 and the text in 6.1.1.2 should be tightly coupled. The text > contains 13 numbered steps, but the figure has either 14 or 17 > steps (depending on how I count the flows between the pt client and > pt broker server). > Figure 2 is common to both examples of initial assessment, i.e. Section 6.1.1 & 6.1.2. We did not intend a co-relation to a specific example and that's why you notice the difference in steps. We will add text before Figure 2 to make this clear. > Section 7.1 > > Requirement C-1 > > Are updates to previously reported posture information actually > part of the same dialog? This would seem to be a separate protocol > run to me. IMHO, sentences 1 & 2 seem to specify a different > requirement than sentences 3 & 4. > The confusion stems from the use of the term dialog since it can cover several transactions. We plan to edit C-1 to essentially clarify that the requirement to support multiple round trips to complete a single assessment. A single assessment could include re-evaluation of the posture after remediation. > Requirement C-3 > > Why is this a SHOULD instead of a MUST? This document includes > scenarios initiaited by the server and by the client. Isn't is a > requirement for the NEA protocols to support both? > This was the issue that was raised on the mailing list by Steve Hanna and discussed during the last IETF meeting. This stems from the fact that the current charter calls for one PT protocol as mandatory to implement whereas we have requirements that a single PT might find difficult to satisfy The requirements in question are A. Ability for PT to run over existing network access protocols such as 802.1x or Ipsec (requirement C-2 re-stated for clarity) B. Ability to perform client or server triggered assessment (requirement C-3) Both these requirements need to be a SHOULD to enable PT protocol selection that can conform to the charter. We plan to edit requirement C-2 in the next revision. > 7.3 > > Requirement PB-4 > > If the posture broker needs to protect global assessment information > (see comments on 5.2.2), then MAY is too weak. MUST or possibly MAY > would be needed... > You mean MUST or SHOULD. This was discussed at the Prague IETF meeting and moved from a SHOULD to a MAY. We certainly open this discussion within the WG. > 8.1.2 > > The last sentence in this section seems to establish a requirement for > the NEA protocols. This material needs to be presented earlier and > represented as a section 7 requirement. > > Section 9.2, next to last paragraph: > > "For example, an enterprise might ask about the OS > version in the initial message dialog and after learning the > system is a Linux system, ask for a different/smaller set of > attributes specific to Linux then it would if the endpoint was a > Windows system. " > > This text answered a nagging question for me, when I encountered it. > While I was glad to learn how the wg intended to address the OS > identification problem, page 48 was a little too late. I believe > the possibility of a bootstrapping ought to be addressed earlier, and we > should clearly state which component (PB Client or PC?) resolves > this type of question... Would this be a requirement or update to the reference model to state that the OS discovery would be handled by the Posture Collector. I am not sure about the motivation to special case the OS type different from any other standard attribute. Regards, kaushik > > Thanks, > > Tim Polk > > > _______________________________________________ > 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 Aug 10 16:53: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 1IJbUY-00089z-Qt; Fri, 10 Aug 2007 16:53:54 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IJbT8-0007pA-Eg for nea-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 16:52:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJbT8-0007p0-4F for nea@ietf.org; Fri, 10 Aug 2007 16:52:26 -0400 Received: from rimp1.nist.gov ([129.6.16.226] helo=smtp.nist.gov) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJbT6-0007EB-Og for nea@ietf.org; Fri, 10 Aug 2007 16:52:26 -0400 Received: from [192.168.15.166] (bethany.ncsl.nist.gov [129.6.52.15]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id l7AKqGbi011793; Fri, 10 Aug 2007 16:52:16 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <90062D95-8D05-41D2-B8E8-2E8CDE7460E8@nist.gov> Content-Transfer-Encoding: 7bit From: Tim Polk Subject: Re: [Nea] comments on draft-ietf-nea-requirements-03 Date: Fri, 10 Aug 2007 16:52:14 -0400 To: Kaushik Narayan X-Mailer: Apple Mail (2.752.2) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov X-Spam-Score: 0.0 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 X-Mailman-Approved-At: Fri, 10 Aug 2007 16:53:53 -0400 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Hi Kaushik, Thanks for the prompt and enlightening response. In general, I am fine with your responses, so I deleted most of the quoted conversation. Responses on the remaining issues are inline. On Aug 10, 2007, at 3:18 PM, Kaushik Narayan wrote: > Hi Tim, > > Thanks for your comments. Please find my response inline. > > > On 8/9/07 2:27 PM, "Tim Polk" wrote: > >> Section 2.0 Terminology >> >> Numerous terms are defined in terms of Posture Collectors and Posture >> Validators, but these terms are not defined until section 5. >> > > > > > The definitions currently cover all terms expect for the components > of the > NEA client and NEA server stack defined in the reference model. > There might > not be sufficient context before Section 2.0 to properly define > terms such > as Posture Collector, Posture Broker etc. We could certainly try to > add > these definitions for the sake of completeness. > > Did you find lack of these definitions in Section 2.0 as effecting the > readability of the document. > Personally, I thought the definitions would be cleaner if the Posture Collector, Posture Broker, and Posture Validator were not addressed in the terminology section. This is a stylistic question, though; the effect on readability was negligible. > > > >> >> 5.1.1.2 Posture Broker Client >> >> Question 2: Does the WG envision a set of result attributes that >> are mandatory to support for a posture broker client? This is >> implied by the fourth bullet... >> > > > > Yes. The document talks about the global posture assessment > attribute which > is mandatory to support for posture broker clients and servers. > > > That makes sense to me, but it doesn't seem to be clearly specified as a requirement. I don't think that is a significant problem, but if the WG has consensus on this maybe we should clearly state it. >> >> >> Section 6. >> >> The example seems to assume that the OS is known. Stating that up >> front would be helpful. >> >> Figure 2 and the text in 6.1.1.2 should be tightly coupled. The text >> contains 13 numbered steps, but the figure has either 14 or 17 >> steps (depending on how I count the flows between the pt client and >> pt broker server). >> > > > > Figure 2 is common to both examples of initial assessment, i.e. > Section > 6.1.1 & 6.1.2. We did not intend a co-relation to a specific > example and > that's why you notice the difference in steps. > > We will add text before Figure 2 to make this clear. > > > If a tight coupling between the figure and examples is not intended, more information may be needed in Figure 2. For example "Pos Req" or a variant of that is the label on five arrows. Those five arrows correspond to (1) Posture validator(s) send PA messages containing the desired attributes to the Posture Broker Server. (2), (3) Posture Broker Server aggregates the PA messages and sends them to the NEA client via the Posture Transport Server. (4) The Posture Transport Client sends the aggregated PA messages to the Posture Broker Client. (5) The Posture Broker Client de-mulitplexes the PA messages and delivers them to the appropriate Posture Collector(s). We are asking a lot from the reader to sort all this out on their own! > > >> 7.3 >> >> Requirement PB-4 >> >> If the posture broker needs to protect global assessment information >> (see comments on 5.2.2), then MAY is too weak. MUST or possibly MAY >> would be needed... >> > > > > You mean MUST or SHOULD. This was discussed at the Prague IETF > meeting and > moved from a SHOULD to a MAY. > > We certainly open this discussion within the WG. > > > No need to reopen discussion on this item. MAY is consistent with the rationale provided for my comment on 5.2.2. I am satisfied that the WG has considered the issue. > >> 8.1.2 >> >> The last sentence in this section seems to establish a requirement >> for >> the NEA protocols. This material needs to be presented earlier and >> represented as a section 7 requirement. >> >> Section 9.2, next to last paragraph: >> >> "For example, an enterprise might ask about the OS >> version in the initial message dialog and after learning the >> system is a Linux system, ask for a different/smaller set of >> attributes specific to Linux then it would if the endpoint was a >> Windows system. " >> >> This text answered a nagging question for me, when I encountered it. >> While I was glad to learn how the wg intended to address the OS >> identification problem, page 48 was a little too late. I believe >> the possibility of a bootstrapping ought to be addressed earlier, >> and we >> should clearly state which component (PB Client or PC?) resolves >> this type of question... > > > > > Would this be a requirement or update to the reference model to > state that > the OS discovery would be handled by the Posture Collector. I am > not sure > about the motivation to special case the OS type different from any > other > standard attribute. > > Regards, > kaushik > > > Once again, I was unintentionally vague.... Interrogating an endpoint with respect to its OS seems inconsistent with the definitions of posture and posture attribute in 2., so I couldn't figure out how the posture validator(s) knew which OS a system ran. Without that knowledge, the posture validator(s) can't know which attributes to request. There are a couple of solutions: (1) request all possibly interesting posture attributes for all recognized OSes, and sort out the results; or (2) interrogate the endpoint and request teh attributes that make sense. From the text in the security considerations, I deduced that discovery may be performed by requesting posture attributes that describe the OS, etc. but that this step was omitted from the example since multiple round trips complicate the base concepts. This also implies the definitions of posture and posture attribute could be expanded... So, maybe it isn't a new requirement, its just an extra clause in the definition of posture. Thanks again, Tim Polk _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Aug 10 18:02:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJcYV-00050s-Cb; Fri, 10 Aug 2007 18:02:03 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IJcYU-0004wP-Cp for nea-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 18:02:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJcYU-0004uv-2d for nea@ietf.org; Fri, 10 Aug 2007 18:02:02 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJcYS-0000QC-K5 for nea@ietf.org; Fri, 10 Aug 2007 18:02:02 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 10 Aug 2007 15:02:00 -0700 X-IronPort-AV: i="4.19,246,1183359600"; d="scan'208"; a="512503648:sNHT54996584" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l7AM1xLb023429; Fri, 10 Aug 2007 15:01:59 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l7AM1sWB001371; Fri, 10 Aug 2007 22:01:59 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); Fri, 10 Aug 2007 15:01:51 -0700 Received: from 171.69.75.24 ([171.69.75.24]) by xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) with Microsoft Exchange Server HTTP-DAV ; Fri, 10 Aug 2007 22:01:51 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Fri, 10 Aug 2007 15:01:50 -0700 Subject: Re: [Nea] comments on draft-ietf-nea-requirements-03 From: Kaushik Narayan To: Tim Polk Message-ID: Thread-Topic: [Nea] comments on draft-ietf-nea-requirements-03 Thread-Index: Acfbmg1sTB+XuEeNEdygrAAX8tamGQ== In-Reply-To: <90062D95-8D05-41D2-B8E8-2E8CDE7460E8@nist.gov> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 10 Aug 2007 22:01:51.0700 (UTC) FILETIME=[0E6FC140:01C7DB9A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5115; t=1186783319; x=1187647319; 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]=20comments=20on=20draft-ietf-nea-requirements-0 3 |Sender:=20; bh=QkdpJrT/03Rqpin3Yv+rbFYvS9roqcVDcJbJIznzN94=; b=Fp8fx/Preyk6WPRxcDfGZN7gpum6PjglTZ6KjYL/LLeZf3t6NdVzOewb9trP1KKk+VHxl2f6 t86X9owwEtytYItif+UPptH/xR2sDEvW9lel33y9DW8si7GNCefs6iYZ; Authentication-Results: sj-dkim-4; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -1.4 (-) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Hi Tim, Please find some responses inline tagged with >> >> Did you find lack of these definitions in Section 2.0 as effecting the >> readability of the document. >> > > Personally, I thought the definitions would be cleaner if the Posture > Collector, > Posture Broker, and Posture Validator were not addressed in the > terminology > section. > > This is a stylistic question, though; the effect on readability was > negligible. > I guess the "not addressed" is typo. We will try to see if we can get meaningful definitions of Posture Broker, Posture Collector etc. prior to the explanation in the reference model. >> >>> >>> 5.1.1.2 Posture Broker Client >>> >>> Question 2: Does the WG envision a set of result attributes that >>> are mandatory to support for a posture broker client? This is >>> implied by the fourth bullet... >>> >> >> >> >> Yes. The document talks about the global posture assessment >> attribute which >> is mandatory to support for posture broker clients and servers. >> >> >> > > That makes sense to me, but it doesn't seem to be clearly specified as a > requirement. I don't think that is a significant problem, but if the > WG has > consensus on this maybe we should clearly state it. We have avoided defining requirements that specify functional behavior of the PA, PB & PT layers. The computation of the global posture assessment decision and delivery of that attribute is a key function of the Posture Broker Server and we will probably emphasize that in the reference model. > >>> >>> >>> Section 6. >>> >>> The example seems to assume that the OS is known. Stating that up >>> front would be helpful. >>> >>> Figure 2 and the text in 6.1.1.2 should be tightly coupled. The text >>> contains 13 numbered steps, but the figure has either 14 or 17 >>> steps (depending on how I count the flows between the pt client and >>> pt broker server). >>> >> >> >> >> Figure 2 is common to both examples of initial assessment, i.e. >> Section >> 6.1.1 & 6.1.2. We did not intend a co-relation to a specific >> example and >> that's why you notice the difference in steps. >> >> We will add text before Figure 2 to make this clear. >> >> >> > > If a tight coupling between the figure and examples is not intended, > more > information may be needed in Figure 2. For example "Pos Req" or a > variant > of that is the label on five arrows. Those five arrows correspond to > > (1) Posture validator(s) send PA messages containing the desired > attributes > to the Posture Broker Server. > (2), (3) Posture Broker Server aggregates the PA messages and sends them > to the NEA client via the Posture Transport Server. > (4) The Posture Transport Client sends the aggregated PA messages to the > Posture Broker Client. > (5) The Posture Broker Client de-mulitplexes the PA messages and > delivers > them to the appropriate Posture Collector(s). > > We are asking a lot from the reader to sort all this out on their own! You are right. We will either update Figure 2 to make it self explanatory or more likely bind the figure to the example in 6.1.1.2. >> >> >> >> Would this be a requirement or update to the reference model to >> state that >> the OS discovery would be handled by the Posture Collector. I am >> not sure >> about the motivation to special case the OS type different from any >> other >> standard attribute. >> >> Regards, >> kaushik >> >> >> > > Once again, I was unintentionally vague.... > > Interrogating an endpoint with respect to its OS seems inconsistent > with the > definitions of posture and posture attribute in 2., so I couldn't > figure out how the > posture validator(s) knew which OS a system ran. Without that > knowledge, the > posture validator(s) can't know which attributes to request. > > There are a couple of solutions: (1) request all possibly interesting > posture > attributes for all recognized OSes, and sort out the results; or (2) > interrogate the > endpoint and request teh attributes that make sense. > > From the text in the security considerations, I deduced that > discovery may be > performed by requesting posture attributes that describe the OS, > etc. but that > this step was omitted from the example since multiple round trips > complicate > the base concepts. This also implies the definitions of posture and > posture > attribute could be expanded... > > So, maybe it isn't a new requirement, its just an extra clause in the > definition > of posture. That's a good suggestion. We will add text to the definition of posture/posture attribute to clarify OS-type as a standard/core attribute. Regards, kaushik > _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Aug 10 18:21:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJcrD-00045x-9b; Fri, 10 Aug 2007 18:21:23 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IJcrC-00043m-Bz for nea-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 18:21:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJcrC-00043N-0T for nea@ietf.org; Fri, 10 Aug 2007 18:21:22 -0400 Received: from smtpb.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJcrA-0000ib-GV for nea@ietf.org; Fri, 10 Aug 2007 18:21:21 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpb.juniper.net with ESMTP; 10 Aug 2007 15:21: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 Date: Fri, 10 Aug 2007 18:21:08 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: More non-substantive comments on nea-requirements-03 Thread-Index: AcfbnL+xjcvSZi7UTVupWehAfjZZCw== From: "Stephen Hanna" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 94962611154c8404498b19f744990308 Subject: [Nea] More non-substantive comments on nea-requirements-03 X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 are some more non-substantive comments on the latest version of the NEA requirements document (-03). Please take these in the constructive manner in which they are intended. Thanks, Steve ------------ In the second paragraph of section 3.2, change "Network" to "network". There's no reason for this word to be capitalized. At the end of the fourth paragraph of section 3.2, change "its policies" to "the company's policies". Otherwise, it's hard to figure out what the word "it" refers to. Throughout the specification, there are MANY places where you insert a hyphen into words that begin with "re". For example, "re-assessment", "re-usable", "re-use", "re-join", "re-activate", etc. There's no reason to have a hyphen in these words. In fact, it's incorrect. Feel free to consult a dictionary on this one. I used Merriam-Webster and the OED. I suggest that you just do a global search and replace changing "re-" to "re". In the first sentence of section 5.1.1, "comprises" should be "comprised". You can say the NEA client "comprises the following components" or "is comprised of the following components". But "comprises of the following components" isn't correct. We should decide whether to use "a NEA" or "an NEA". Right now, the document is about evenly divided. I prefer the former because I often pronounce NEA as "nee-ah" but I know that some people pronounce it as "en-ee-ay". Either way, let's decide and be consistent. In the second sentence of the first paragraph of section 5.1.1.2, I don't think the Posture Broker Client actually de-multiplexes the posture information request from the NEA Server. I think it receives the request from the NEA Server and then de-multiplexes it. There are two steps here and I think we should reflect that in the text. Also, I think it would be more accurate to call the thing received a "PB message" than to call it a "posture information request". It's really a PB message and it may or may not have a posture information request in it. If we do make this change, we should probably make another change later in that sentence: change the text "distributing each request to the corresponding Posture Collector(s)" to "distributing each PA message to the corresponding Posture Collector(s)." This should clarify what request is what. After the bullets at the start of section 5.1.2, I think "The Posture Validator" should be "Posture Validators". There will often be several Posture Validators. In the third paragraph of section 5.1.2.1, I don't think we have any documented requirement for a NEA Server to handle several Posture Validators. So I think the phrase "is required" should be changed to "may need". At the top of page 17, "Results Attribute" should be "Result Attribute" to match the term defined in the Terminology section on page 7. In the third sentence of the first paragraph of section 5.1.2.2, I think you actually want to say the Posture Broker Server "parses the PB messages received from the NEA Client and de-multiplexes into PA messages which it passes to the associated Posture Validators". Why? Because the Posture Broker Server doesn't receive PA messages. It receives PB messages that contain PA messages. In the first bullet at the bottom of page 17, change "register/unregister" to "register and deregister". This removes any ambiguity about whether the slash represents "or" or "and" and replaces "unregister" with a real word. ;-) In the first bullet of section 6, remove the colon. This is a perfectly fine sentence without it. At the end of the second bullet of section 6, change "its" to "the endpoint's". Otherwise, it can be hard to figure out what "its" refers to. The second sentence of the first paragraph in section 6.1 is hard to understand. There are tons of words before you get to the verb. I suggest rephrasing it to say "Endpoints do not qualify for this category of use case if the have been recently assessed and the NEA Client or Server has maintained state (or proof) that the endpoint is compliant and therefore does not need to have its posture evaluated again." I agree with Tim that Figure 2 could use some work. Here are my pet peeves. ;-) The current diagram shows the whole sequence as being started by the event "client requests network access". Actually, the Initial Assessment Use Case can be triggered by the client or the server so I think it would be better to say "endpoint assessment triggered". Another peeve is that the arrows in the diagram have all sorts of different labels, none of which correspond to anything in the terminology section. Oh, well! ASCII art is hard! I think it would be good to add a sentence after Figure 2 to remind people what they're about to see since they have probably spent some time puzzling over Figure 2. Something like "Several Initial Assessment use cases are described in sections 6.1.1 and 6.1.2" should do it. At the end of the first paragraph of section 6.1.1, I think you should remove the word "such". I don't think there's really anything for that word to refer to. The flows in section 6.1.1.2 are not definitive. I suggest replacing the first sentence of section 6.1.1.2 with this: > This section describes typical message flows through the > NEA Reference Model for this use case. Step 4 of section 6.1.1.2 seems to combine a bunch of steps into one. Maybe it would be better to break those out, at least into separate sentences in one step. For instance, you could write: > The Posture Broker Server aggregates the PA messages from > the Posture Validators into a PB message. The Posture Broker > Server passes this message to the Posture Transport Server, > which uses the PT protocol to send the PB message to the > NEA Client on the desktop computer. The first sentence of step 11 of section 6.1.1.2 is a bit confusing. It sounds like it (what?!) is compliant to the Posture Broker Server. I think this problem could be solved by rephrasing the first part of that sentence to this: > The Anti-Virus and Firewall Posture Validators return =20 > attributes to the Posture Broker Server stating that the > desktop computer is compliant, but [...] I don't think we should capitalize Anti-Virus, Firewall, and OS Patch. The fewer capitalized terms the better, especially since these are not terms defined in the Terminology section. Step 12 in section 6.1.1.2 omits the role of the Posture Transport Server and Posture Transport Client. I would add this phrase to the end: "via the Posture Tranport Server and Posture Transport Client". At the end of step 13 in section 6.1.1.2, I think the phrase "potentially while quarantined" is incidental so I recommend that we place a comma before it. In step 14 of section 6.1.1.2, it's not clear what the phrase "upon completion" refers to. I suggest that we change it to say "Upon completion of the remediation instructions". Step 15 of section 6.1.1.2 says that the OS Patch Posture Validator returns a compliant status. Actually, ALL the Posture Validators do so in this reassessment. I think we should say that. Also, I don't think that we should refer to step 11 in step 15. This step replaces step 11 but we don't need to say so. The first sentence of section 6.1.2 says that the reassessment is "possibly caused by a user". I think you mean "possibly at the request of a user". If I'm right that this is the main focus of this comment, please say so. Otherwise, it leaves the reader imagining all the ways that a user might cause a reassessment (many of which are unpleasant to consider and none of which are very relevant to this use case). Step 2 of section 6.1.2.2 says the Posture Broker Client "establishes a session ...". I think this is getting into too many internal details of how the NEA Client works (or might work). Wouldn't it be better and simpler to just say the Posture Broker Client "requests a new assessment" and end the step there? Again in step 3 of section 6.1.2.2, we get into a lot of detail about "causing a new protocol context exchange to be initiated". I don't know what that means and I don't see how it's relevant to PA, PB, or PT. Let's just delete it. In step 4 of section 6.1.2.2, we say the Posture Broker Server "contacts" several Posture Validators. Actually, they may well have been in contact for some time. I think the more relevant statement is that the Posture Broker Server "decides to employ" several Posture Validators for this assessment. In step 8 of section 6.1.2.2, "PA message" should be plural not singular. In step 12 of section 6.1.2.2, "active" should be "activate". In step 13 of section 6.1.2.2, I think it would be clearer to say "the Validators'" instead of "each Validators'". In step 19 of section 6.1.2.2, we should change "his/her" to "her" since we said "her" at the end of section 6.1.2.1. At the end of the first paragraph of section 6.2, I think it would clarify things if we added the words "on the NEA Server". Also, I think we should combine the first and second paragraphs of this section since the second one is just a slight elaboration of the first one. In step 1 of section 6.2.1.2, we don't say where the PB message comes from. I suggest we change "This PB message contains [...]" to "The Posture Broker Client creates a PB message that contains [...]". The second sentence of step 2 of section 6.2.1.2 says that "The Posture Broker Client will create a new session for the re-assessment." I think that the Posture Broker Client may often reuse an existing session and I don't think that makes much difference so I think we should delete this sentence. At the end of step 7 in section 6.2.1.2, we say that The Posture Validator "instructs [the Posture Broker Server] to respond back to the NEA Client." I don't think that's likely to be true. The Posture Broker Server will probably know when it's time to respond back to the NEA client and may wait for other Posture Validators. So I suggest we drop that clause. In the third bullet of section 6.2.1.3, "interact" should be "interacts". In the first sentence of the second paragraph of section 6.2.2.1, "it" should be "them". In the second sentence of that paragraph, "what" should be "which". In the fourth sentence of that paragraph, the word "explaining" (or something similar) is needed after the word "employee". In step 2 of section 6.2.2.2, the word "for" is extraneous. In step 3 of section 6.2.2.2, "become" should be "becomes". In step 8 of section 6.2.2.2, we should simply say "OS Patch Posture Collector" instead of "the Posture Collector responsible for handling OS Patch Request Attribute(s)." Although I like the idea of not implying that each Posture Collector has one function, we have been doing this everywhere else in these examples so we should probably be consistent. In step 15 of section 6.2.2.2, I think it would be clearer to say "along with its PA message" instead of "and its PA message". In step 20 of section 6.2.2.2, "how" should be "now". In step 21 of section 6.2.2.2, "step 13" should be "in step 13". Also, the reusable attributes don't need to be signed and dated. They could be a cookie or other reference to server-side state. Therefore, I suggest that we put "e.g." before the words "signed and dated" to indicate that this is just one way this could be done. The end of step 22 in section 6.2.2.2 is not grammatical. I suggest that we change it to "[...] compliance, it caches those attributes for future use." In step 23 of section 6.2.2.2, "step 9-10" should be "step 9". In the first paragraph of section 7, I think it would be clearer to say "decide whether to make use of that feature" instead of just "decide to make use of that feature". There's really a yes/no decision for the deployer here. In the second paragraph of section 7, we should change "from each" to "for a" since we no longer require all the protocols to provide cryptographic security. For the same reason, we should change "require that a deployer make use of all or even any of them" to "require that a deployer must make use of these protections". In requirement C-5, I suggest that we place "i.e. PT" in parentheses since it's really a parenthetical comment. In requirement PA-5, "Results" should be "Result Attributes" for consistency with the Terminology section. In the first paragraph of section 7.3, the meaning of "to/from" is not clear. This is often true when using a slash to separate two words. I suggest that we remedy the problem be replacing "to/from" with "and" and adding "(in either direction)" at the end of the sentence. In the second paragraph of section 7.3, I think a "patch reference" is a kind of remediation instruction so I suggest that we remove the words "and patch references" from this sentence. In requirement PB-2, I think that "(de)registation" is supposed to mean "registation or deregistation". If I'm right, please change the first phrase/word/ambiguous thing into the second clear phrase. At least, I think the second one is clearer! In PB-3, the phrase "each party" is ambiguous. I think we mean "Posture Collectors and Posture Validators". If I'm right, let's please say so. Also, I think it would be good to add a phrase at the end of this requirement: "while maintaining state associated with the dialog". That should help explain why we need PB-3. In the second sentence of the second paragraph of section 8, the first "it" should be "it is". Later in that sentence is another of those odd and ambiguous slash constructions. Let's change that to "out of date, inactive, or absent". In the next sentence, it's not clear what "be present" means. I suggest we change this to "have this endpoint present". In the first sentence of the next paragraph, "endpoint" should be plural. I think the second sentence of section 8.1 should be worded more firmly. I suggest changing the start of this sentence to "Therefore, there must be an implied distrust [...]" In the next sentence, I think it is clearer (and certainly more grammatical) to say "to not misuse" instead of "not to misuse". Later in that sentence, I think it would be more specific and accurate to say "any remediation instructions provided to the endpoint" instead of "any remediation necessary to join the network". And in the next sentence I think it would be best to insert the word "also" between "The NEA Client" and "normally needs". This is an additional kind of trust. We could tighten up the first sentence of the next paragraph by changing its start from "In between the NEA Client and Server exists a network" to "Between the NEA Client and Server there exists a network". In the second paragraph of section 8.1.1, the last sentence reference to "comparison" mechanisms. I think it would be more accurate and more general to replace that word with the word "evaluation". In the second paragraph of section 8.1.2, the words "or alike" are both ungrammatical and unnecessary. I suggest we delete them. Why unnecessary? Because "e.g" implies this is just a few of many alternatives. In the second sentence of the last paragraph of section 8.1.2, there should be a comma between "network" and "archiving" and another comma after the parenthetical phrase. In the first sentence of section 8.1.3, I suggest putting parentheses around the phrase "including potentially remote systems providing posture validation". This is really a parenthetical comment. Marking it as such will make it easier to understand the sentence. In the first sentence of the second paragraph of section 8.1.3, "their" should be "its" since the referent is "the NEA Server". Later in the paragraph, another phrase should be placed in parentheses: "particularly those that would change the resulting =20 decisions or enforcements". And in the following sentence, "underlying carrier protocols" should be changed to "NEA protocols". The NEA Server really needs to trust all the NEA protocols, not just carrier protocols (which is ambiguous anyway). The first sentence of the next paragraph describes an example that ostensibly "combines aspects of both areas". Which areas? I suggest that we just say "One interesting example is where some [...]". In the last sentence of the second paragraph of section 8.2, I think the word "and" should be replaced with the words "or so that". Otherwise, the word "and" might be interpreted as a logical conjunction instead of as a disjunction, which I think is what's intended. In the first sentence of the second paragraph of section 8.3.1, "themselves" should be replaced with "himself" or "itself" since the referent ("attacker") is singular. In the last sentence of this paragraph, "the passive MITM" should be "a passive MITM" since there's no specific MITM being referred to. In the first sentence of section 8.3.2, it would be clearer and simpler to replace the phrase "an attacker capable of interception of a message" with the phrase "an attacker capable of intercepting a message". Later in that paragraph, we should insert the word "a" before "malware infested machine". And in the last sentence of the paragraph, "introduce a malware" should be changed to "would introduce malware". In the first sentence of the next paragraph, "this change" should be changed "any change to a message" since there's no specific change being referred to. In the fourth sentence of section 8.3.4, "the all of the" should be just "all of the". In the first sentence of the third paragraph of section 9, "specify" should be "specifying". At the end of that paragraph, "their use" should be "endpoint use" and "they" should be "the endpoint". Otherwise, the referents for the pronouns are obscure. In the bullets at the end of section 9.1, replace the slash with the word "and". In the last sentence of the second paragraph of section 9.2, insert the word "a" before the word "system". At the end of the next paragraph, change the word "system" to "systems". In the next paragraph, remove the text "/smaller" since it's not clear that the set of attributes sent by a Linux system will be smaller than the set of attributes sent by a Windows system and there's no reason to get into religious issues here. Also, remove the comma a few words earlier. There's no reason to have it there. In the Acknowledgements section, Alan DeKok's name has a capital letter 'K' at the end. It should not, I think. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Aug 10 18:23:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJcsp-0005cs-1G; Fri, 10 Aug 2007 18:23:03 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IJcsn-0005al-Uu for nea-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 18:23:01 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJcsn-0005aD-Kl for nea@ietf.org; Fri, 10 Aug 2007 18:23:01 -0400 Received: from smtpa.juniper.net ([207.17.137.120]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJcsn-0007lm-C3 for nea@ietf.org; Fri, 10 Aug 2007 18:23:01 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpa.juniper.net with ESMTP; 10 Aug 2007 15:23:01 -0700 X-IronPort-AV: i="4.19,246,1183359600"; d="scan'208"; a="54245172:sNHT30025760" 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, 10 Aug 2007 18:22:49 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NEA requirements and internationalization Thread-Index: AcfbnPv59mjKtttGREmk1tsZE1/VyA== From: "Stephen Hanna" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Nea] NEA requirements and internationalization X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Requirement PA-8 is the only place where we mention string attributes and internationalization issues. I'm not sure there's a special kind of string attribute. I think instead we should probably have a common requirement that says something like "The protocols MUST support encoding any strings intended for display to a user with an encoding standard that supports internationalization." Maybe we should also require that the protocols support language tags for those strings or even that they support language negotiation. Or maybe we should avoid sending user-visible strings! Thanks, Steve _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Aug 10 20:01: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 1IJePj-0004YO-Gu; Fri, 10 Aug 2007 20:01:07 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IJePi-0004YJ-Ps for nea-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 20:01:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJePi-0004YB-GJ for nea@ietf.org; Fri, 10 Aug 2007 20:01:06 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJePh-0002Fw-8Q for nea@ietf.org; Fri, 10 Aug 2007 20:01:06 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 10 Aug 2007 17:01:05 -0700 X-IronPort-AV: i="4.19,246,1183359600"; d="scan'208"; a="198186101:sNHT48348135" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l7B014pK016224 for ; Fri, 10 Aug 2007 17:01:04 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7B00tFW016254 for ; Sat, 11 Aug 2007 00:01:04 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 17:00:13 -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: Fri, 10 Aug 2007 17:00:16 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-nea-requirements-03.txt Thread-Index: AcfbqpkR2RO3Mv6hQ9aJC7GjQxG3nw== From: "Joseph Salowey \(jsalowey\)" To: X-OriginalArrivalTime: 11 Aug 2007 00:00:13.0723 (UTC) FILETIME=[979276B0:01C7DBAA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3125; t=1186790464; x=1187654464; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20Comments=20on=20draft-ietf-nea-requirements-03.txt |Sender:=20; bh=vtlfBbuReMiCtr90moLv4VobmQUxk7ObtE510iO8UQA=; b=CjS+II08PNhObTNCx82v3qEL3JTrAKCdH8Q4jW72+5lLp/kLL+Ne3/A/mETqE3TtAkTE7dpe R6R0QSut8EC2I+scgQvRjb3xJjC/uxfi6Ud4L5GCUmv6xKam347KXgMRQw6E2Kt+i/JVWnQ8iV FpscmxN8ZQe5d73xZEGomIgEM=; Authentication-Results: sj-dkim-1; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Subject: [Nea] 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 In general the document looks pretty good, but I do have a few comments. Comments on Section 2 - I expected to see a term along the lines of "Network Endpoint Assessment Authority." This is the entity who is trusted to perform the endpoint assessment. This is often related to the device owner in that it is either specific entities that are part of the device owner or a third party that has been delegated the authority to perform assessment by the device owner. =20 Comments on Section 3 - Is the case where an device is owned by an individual who contracts out compliance assessment to a third party in scope? Comment on Section 5 Section 5.1.1.1 - The last paragraph is asking the reader to "Recall that this is not a set of requirements for what each Posture Collector implementation must support." Where is the reader recalling this from? Also does this apply to the other sections. Section 5.1.1.1,2,3 - 5.1.1.1 and 5.1.1.3 describe cryptographic protection at the transport, the collector, why wouldn't the broker be able to provide cryptographic protection as well? What are the goals of the cryptographic protection cited? Section 5.2.1 - Is the application of cryptographic protection a matter of policy as in 5.2.3? Section 6 Section 6.1.1.x - In this case it is not clear when network access is given or not, or really what it means to have network access. It is also not clear that the NEA client itself would the component that requests network access.=20 Section 7 - C-5 - It seems that it might be advantageous for the PA and PB protocols to have knowledge of which transport they are running over. This may help in determining which mode from c-10 to run in. =20 - PA-6 - It seems that different posture collectors may use different mechanisms to protect their attributes based on there requirements necessary to protect their data and the type of security relationship their components have. Is it necessary to specify protection at this layer? These different layers of cryptography introduce complexities around key management suggest multiple trust relationships. =20 - PT-6 What does "This MAY occur by leveraging by-products (e.g., keys) supplied by the PB protocol authentication." mean and is it important at this level of requirements. =20 Section 8=20 - Section 8.1 - the discussion of trust left me a bit unsatisfied. There are lots of components (PC,PV,etc.) in the NEA system that have the requirement for a cryptographic basis for trust. This section glosses over trust between components in favor of discussing a NEA Client and NEA Server. Since the document treats these as composed of separate components with apparently their own trust relationships the should be discussed in this section. Section 9=20 - Just a comment that there may be benefit to the endpoint user to have their compliance checked, NEA should be as much about protecting the end point rather than protecting the client. Most of the document seems OK with the respect, but it something to keep in mind.=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Aug 10 23:30:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJhga-0007Dl-5k; Fri, 10 Aug 2007 23:30:44 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IJhgX-0007Dg-Rq for nea-confirm+ok@megatron.ietf.org; Fri, 10 Aug 2007 23:30:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJhgX-0007DX-I5 for nea@ietf.org; Fri, 10 Aug 2007 23:30:41 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IJhgW-0005c4-4A for nea@ietf.org; Fri, 10 Aug 2007 23:30:41 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 10 Aug 2007 20:30:34 -0700 X-IronPort-AV: i="4.19,247,1183359600"; d="scan'208"; a="198256126:sNHT18787209057" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l7B3UYae003890 for ; Fri, 10 Aug 2007 20:30:34 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7B3UQF6001714 for ; Sat, 11 Aug 2007 03:30:34 GMT Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Aug 2007 20:30:28 -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: Fri, 10 Aug 2007 20:30:26 -0700 Message-ID: <08A9A3213527A6428774900A80DBD8D804A1D8FF@xmb-sjc-222.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comments on draft-ietf-nea-requirements-03.txt Thread-Index: Acfbx/VbZjlPjyE8Ql6tTL3YpjY4XA== From: "Nancy Winget \(ncamwing\)" To: X-OriginalArrivalTime: 11 Aug 2007 03:30:28.0708 (UTC) FILETIME=[F6B06A40:01C7DBC7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5071; t=1186803034; x=1187667034; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=ncamwing@cisco.com; z=From:=20=22Nancy=20Winget=20\(ncamwing\)=22=20 |Subject:=20comments=20on=20draft-ietf-nea-requirements-03.txt=20 |Sender:=20; bh=uRRzRlqzBfrNdtFFhcyjrTbRX14weRPcfCyYbVnejg4=; b=Ff1K0HTjwNBOlNoWAAD9wq1LaSYpxURt8BRrhA4HZk1cqLOMJa61xfwTC8oMW6hEFjr56anB 3nl8K+Cn5HfZbP4LJcEXzDJa50vvxzCNh7vWznNCetKRgUZ3YwPQcjTa4dxyQOF0sww82yOm6T hQB91PaMQHaHpE5ozRLrfM3yQ=; Authentication-Results: sj-dkim-1; header.From=ncamwing@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Subject: [Nea] 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 In general the draft is a great improvement over the last revision. I still have a few comments/questions: =20 Section 2 --------- * while the PA, PB and PT are described in Section 5, it would be good to give summary definitions to these here as they are referenced=20 Section 5 ---------- * The Posture Collector as described in 5.1.1.1 states: " Receiving attributes containing remediation instructions on=20 how to update the component(s) on the endpoint. This could=20 require the collector to interact with the user, owner=20 and/or a remediation server." which seems somewhat contradictory or needs further elaboration when relating to the statement in the Posture Broker Client description of 5.1.1.2: " Providing user notification about the global assessment=20 decision and other user messages sent by the NEA Server." If the PB is maintaining a more "global" state, this implies that it may "reassess" and modify the "remediation" as provided by the server. Or what is meant by "global assessment" (as that result could imply different actions versus the collection of "individual assessments" belonging to a particular Posture Collector. * 5.1.1.1 states "...offering cryptographic protection to the attributes returned." - protection from whom? Is it protecting it from the layers within the NEA client (e.g. Protected from the PB and PT) as it is provided by the PA?=20 * 5.1.1.3 what are the threat models addressed in "providing cryptographic protection for the message dialog between the NEA Client and NEA Server"? * Figure 1 is somewhat confusing as the PA, PB and PT are drawn across the client and server, but the descriptions infer that the PA flow from PA to PB to PT and up back up on the other end. While it is understood that the communication "targets" are across, the security implications and considerations must take into account the threats that may occur while the information is flowing through the different nodes. For instance, there may be multiple nodes supporting the "NEA Server" and thus the transport between the Posture Validators and Posture Broker (and Posture Transport Server[s]) must also be described in the security considerations.=20 * 5.1.2.1 (Posture Validator) "Requesting attributes froma Posture Collector".....does this mean that the Posture Collector is uniquely identified within an NEA client? Or does the client determine which PC to route the request to? (this text infers the former, but given the "global assessment" of the Posture Broker, it's not clear. Section 7 ---------- * C-2: a nit, by "after the endpoint has gained normal network"......the intent is really "during the endpoint's session in the network"? =20 * C-4: who are the intermediaries? Since there are multiple Posture Collectors, Validators, Transports, there needs to be clarification on the message flow as the flow say, between a particular Posture Validator to Broker to Transport server are authorized. * C-7, C-9: it would be good to quantify the "scale" and a reasonably expected number of NEA clients and Posture Validators. Is the scale on the order of 100's, 1000's, 10K? * In Section 7.2, there are many requirements for enabling the Posture Validator. Shouldn't there be allowance for the Posture attributes to be sent unsolicited from the Posture Collector to the Validators as well? * PA-6: clarification is needed on the "end-to-end" security across an NEA deployment. The model in Figure 1 abstracts the layers as there may be different deployments, and how the protection is carried out can be dependent on the instatiation of the model. It is not clear why the protection needs to be a hard requirement vs. a "MAY" at this layer. * PA-7: I can see this being true for the server side, but why is this required on the client? * PB-4: "The PB protocol MAY support authentication, integrity and =20 confidentiality protection for the attribute messages it =20 carries between an NEA Client and Server. " What is meant by=20 "NEA Client and Server", is the intent to protect a layer of protection between the brokers? * PT-6: "The PT protocol MUST be capable of supporting mutual =20 authentication between the Posture Transport Client and the =20 Posture Transport Server. This MAY occur by leveraging by-=20 products (e.g., keys) supplied by the PB protocol =20 authentication." I don't see how the PB protocol helps here? Section 8.1: - Components can really mean components within an NEA Client or Server and the "general" network components as well. It is unclear in either 8.1 and 8.1.1 what components are being referred to. It would be better to separate the threat models within the "NEA component" and between an "NEA Client" and "NEA Server" and the rest of the network components (that are not NEA participants). _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Sat Aug 11 13:06:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJuQF-00081e-Fk; Sat, 11 Aug 2007 13:06:43 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IJuQE-00081Y-M6 for nea-confirm+ok@megatron.ietf.org; Sat, 11 Aug 2007 13:06:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJuQE-00081M-AI for nea@ietf.org; Sat, 11 Aug 2007 13:06:42 -0400 Received: from elasmtp-spurfowl.atl.sa.earthlink.net ([209.86.89.66]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJuQD-0003Sv-4J for nea@ietf.org; Sat, 11 Aug 2007 13:06:42 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ecjb4fnFqUgIAskTzHzjNOERaTx/45FZEuhKLLw7DrvlXGXdBLW7eMR64rUIfc7A; h=Received:Message-ID:From:To: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-spurfowl.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IJuQC-0004vE-Cm for nea@ietf.org; Sat, 11 Aug 2007 13:06:40 -0400 Message-ID: <023201c7dc39$fc2a0f90$174f7d40@home.glassey.com> From: "todd glassey" To: References: <08A9A3213527A6428774900A80DBD8D804A1D8FF@xmb-sjc-222.amer.cisco.com> Subject: Re: [Nea] comments on draft-ietf-nea-requirements-03.txt Date: Sat, 11 Aug 2007 10:06:37 -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: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec7971c49581752b403e4865fcbf5a2853bf350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.125.79.23 X-Spam-Score: 0.0 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Nancy and Tim - (and nice post Nancy... :-) CAVEAT and inline Apology... -------------------------------------------- this retort is something I have been biting my tongue on for some months now but its got to be said - This Commentary is not directed at any one person but more the collective. Many as individuals will probably find it directly offensive, so my apologies for offending anyone with this post, but I believe the reality is what it is... NEA is not a new idea... ---------------------------------- I do have one comment and that is about the creation of new terms to represent things which are already in use. This complicates the audit process since now we have to equate the concept of "Posturing" to "Making compliant to a set of policies" and while that may seem cool and neat that we as techies came up with yet another way to explain something already in common use, it causes huge amounts of pain in writing policies and control statements for auditing where the requirement is that someone somewhere is accountable in a legal sense for the system we design and that they are forced to use by some (***idiot***) CIO. Simply put - if NEA is a tool set that will enable the plug-in and qualification of a node being installed into a network fabric, then that capability already exists. So then the NEA method and process is yet another method of skinning that cat, and there is nothing wrong with that, its just that the IETF has a rule about reimplementing the wheel if there are already IETF wheels in existence, and well... that seems to have been ignored here. There are already existing protocols which ... ----------------------------------- Also based on the availability of those other protocols that will and can do these same types of things NEA is being designed to do, there is no new IP being generated here as original genesis no matter what new names we tried to hide that under. A Posture Collector is a gateway or server which aggregates policy compliance information from its collective client nodes either as a repeater or a gateway. So its a Policy Aggregation Gateway... Something that has existed in firewalls now for maybe 20 years. See my point? That means that Prior Art is available for all of this IP and that means that no patents should be enforceable and that the Trust cannot also claim sole ownership of the derivative rights since they already were given out to anyone for anything in prior IETF drafts and publications as well as ones external to the IETF. In fact there are likely infringements on other designs based therein, so actually adopting NEA may have legal ramifications we have not reviewed yet. I find this to be "par for the course" though... ------------------------------------- This isn't an idle comment - its about what is real and what is apparently (IMHO) done in the Standards Org so that a few authors can claim to have created something totally new. I apologize for those words, they are acerbic but how would you describe an initiative to reinvent functions from already existing technology into a new package? A repackaging effort? because that is not what is happening here... people are claiming this is new genesis and it simply isn't. It's this same exact mindset that makes the Patent Enforcement Process a freaking nightmare and if you have never had to deal with that, you just 'don't get it' or the pain and financial burden thereof. That said - once again - I am for stripping out all the new terminology and for use of much more generic terms and process descriptions in the documents. No end-use models make this another IETF fiasco ------------------------------------ But that aside, it is about what I expect out of the IETF... A document set who's content has no specific defined uses or methods of implementing it considered in the design phase. The real problem is that a technology without uses is pure research, and that belongs in the IRTF and not here wasting the valuable time of the Vetting Pool Member's and their Sponsor's money. Sponsors have no idea either... ------------------------------------ What's funny here is that I am also betting that effectively the company's sponsoring this effort really have no idea what they or their agents are doing I am willing to bet. Because this type of effort without a MRD (Marketing Requirements Documentation) would have never gotten out of their internal blue-sky process. Thus documenting the core and fundamental problems with letting people who are averse to actually designing real-world-uses for their tools, play wizard. Sorry - it is what it is - and that means that without specific end-use requirements and a limitation to that, the NEA is really just another wasted IETF effort in my opinion. Now if we could get some specific use models and use criteria set up, and then code the standard to that, NEA would rock. But until then IMHO this is more about a bunch of ego's than standards processes because its tied to a bunch of whiney voices all crying "my vision is right"... ----- Original Message ----- From: "Nancy Winget (ncamwing)" To: Sent: Friday, August 10, 2007 8:30 PM Subject: [Nea] comments on draft-ietf-nea-requirements-03.txt In general the draft is a great improvement over the last revision. I still have a few comments/questions: Section 2 --------- * while the PA, PB and PT are described in Section 5, it would be good to give summary definitions to these here as they are referenced Section 5 ---------- * The Posture Collector as described in 5.1.1.1 states: " Receiving attributes containing remediation instructions on how to update the component(s) on the endpoint. This could require the collector to interact with the user, owner and/or a remediation server." which seems somewhat contradictory or needs further elaboration when relating to the statement in the Posture Broker Client description of 5.1.1.2: " Providing user notification about the global assessment decision and other user messages sent by the NEA Server." If the PB is maintaining a more "global" state, this implies that it may "reassess" and modify the "remediation" as provided by the server. Or what is meant by "global assessment" (as that result could imply different actions versus the collection of "individual assessments" belonging to a particular Posture Collector. * 5.1.1.1 states "...offering cryptographic protection to the attributes returned." - protection from whom? Is it protecting it from the layers within the NEA client (e.g. Protected from the PB and PT) as it is provided by the PA? * 5.1.1.3 what are the threat models addressed in "providing cryptographic protection for the message dialog between the NEA Client and NEA Server"? * Figure 1 is somewhat confusing as the PA, PB and PT are drawn across the client and server, but the descriptions infer that the PA flow from PA to PB to PT and up back up on the other end. While it is understood that the communication "targets" are across, the security implications and considerations must take into account the threats that may occur while the information is flowing through the different nodes. For instance, there may be multiple nodes supporting the "NEA Server" and thus the transport between the Posture Validators and Posture Broker (and Posture Transport Server[s]) must also be described in the security considerations. * 5.1.2.1 (Posture Validator) "Requesting attributes froma Posture Collector".....does this mean that the Posture Collector is uniquely identified within an NEA client? Or does the client determine which PC to route the request to? (this text infers the former, but given the "global assessment" of the Posture Broker, it's not clear. Section 7 ---------- * C-2: a nit, by "after the endpoint has gained normal network"......the intent is really "during the endpoint's session in the network"? * C-4: who are the intermediaries? Since there are multiple Posture Collectors, Validators, Transports, there needs to be clarification on the message flow as the flow say, between a particular Posture Validator to Broker to Transport server are authorized. * C-7, C-9: it would be good to quantify the "scale" and a reasonably expected number of NEA clients and Posture Validators. Is the scale on the order of 100's, 1000's, 10K? * In Section 7.2, there are many requirements for enabling the Posture Validator. Shouldn't there be allowance for the Posture attributes to be sent unsolicited from the Posture Collector to the Validators as well? * PA-6: clarification is needed on the "end-to-end" security across an NEA deployment. The model in Figure 1 abstracts the layers as there may be different deployments, and how the protection is carried out can be dependent on the instatiation of the model. It is not clear why the protection needs to be a hard requirement vs. a "MAY" at this layer. * PA-7: I can see this being true for the server side, but why is this required on the client? * PB-4: "The PB protocol MAY support authentication, integrity and confidentiality protection for the attribute messages it carries between an NEA Client and Server. " What is meant by "NEA Client and Server", is the intent to protect a layer of protection between the brokers? * PT-6: "The PT protocol MUST be capable of supporting mutual authentication between the Posture Transport Client and the Posture Transport Server. This MAY occur by leveraging by- products (e.g., keys) supplied by the PB protocol authentication." I don't see how the PB protocol helps here? Section 8.1: - Components can really mean components within an NEA Client or Server and the "general" network components as well. It is unclear in either 8.1 and 8.1.1 what components are being referred to. It would be better to separate the threat models within the "NEA component" and between an "NEA Client" and "NEA Server" and the rest of the network components (that are not NEA participants). _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Sun Aug 12 09: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 1IKDO5-0007uY-13; Sun, 12 Aug 2007 09:21:45 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IKDO3-0007uT-HN for nea-confirm+ok@megatron.ietf.org; Sun, 12 Aug 2007 09:21:43 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKDO3-0007uK-7T for nea@ietf.org; Sun, 12 Aug 2007 09:21:43 -0400 Received: from www.deployingradius.com ([216.240.42.17] helo=deployingradius.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKDO2-0006c2-Oo for nea@ietf.org; Sun, 12 Aug 2007 09:21:43 -0400 Received: from [192.168.1.102] (ottawa-hs-209-217-66-6.d-ip.magma.ca [209.217.66.6]) by deployingradius.com (Postfix) with ESMTP id 51713A7161; Sun, 12 Aug 2007 06:21:40 -0700 (PDT) Message-ID: <46BF095D.9090305@deployingradius.com> Date: Sun, 12 Aug 2007 09:21:33 -0400 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Stephen Hanna Subject: Re: [Nea] NEA requirements and internationalization 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: 9466e0365fc95844abaf7c3f15a05c7d 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 Stephen Hanna wrote: > I think instead we should probably have a common > requirement that says something like "The protocols > MUST support encoding any strings intended for display > to a user with an encoding standard that supports > internationalization." Maybe we should also require > that the protocols support language tags for those > strings or even that they support language negotiation. Tags, yes. Negotiation, no. Each user on an end host in NEA will understand at least one language, which can be configured statically when the NEA client is configured. The server can remember those associations. > Or maybe we should avoid sending user-visible strings! I strongly recommend sending user-visible strings, much as that may cause protocol problems. Many existing access protocols have provisions for sending user-visible strings, but implementations don't use them. When people are denied network access, they get a message that says "failed", rather than anything informative. This lack of information causes many headaches for both users and administrators. I would say thet the protocol MUST have provisions for sending messages that are intended to be displayed to the user. Alan DeKok. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Sun Aug 12 10: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 1IKEMt-0007sN-8v; Sun, 12 Aug 2007 10:24:35 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IKEMs-0007sG-0V for nea-confirm+ok@megatron.ietf.org; Sun, 12 Aug 2007 10:24:34 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKEMr-0007s8-Ms for nea@ietf.org; Sun, 12 Aug 2007 10:24:33 -0400 Received: from www.deployingradius.com ([216.240.42.17] helo=deployingradius.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKEMq-0007q5-Q0 for nea@ietf.org; Sun, 12 Aug 2007 10:24:33 -0400 Received: from [192.168.1.102] (ottawa-hs-209-217-66-6.d-ip.magma.ca [209.217.66.6]) by deployingradius.com (Postfix) with ESMTP id 60C50A7161; Sun, 12 Aug 2007 07:24:27 -0700 (PDT) Message-ID: <46BF1815.4080702@deployingradius.com> Date: Sun, 12 Aug 2007 10:24:21 -0400 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: todd glassey Subject: Re: [Nea] comments on draft-ietf-nea-requirements-03.txt References: <08A9A3213527A6428774900A80DBD8D804A1D8FF@xmb-sjc-222.amer.cisco.com> <023201c7dc39$fc2a0f90$174f7d40@home.glassey.com> In-Reply-To: <023201c7dc39$fc2a0f90$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: 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 todd glassey wrote: > NEA is not a new idea... > There are already existing protocols which ... Yes. > That said - once again - I am for stripping out all the new terminology and > for use of much more generic terms and process descriptions in the > documents. I agree. > No end-use models make this another IETF fiasco I'm not sure I agree. Similar protocols have been deployed before, with similar use models. Much of NEA is simply aggregating and standardizing the previous ad-hoc collection of methods. > ... Because this type of effort without a MRD > (Marketing Requirements Documentation) would have never gotten out of their > internal blue-sky process. There are other corporate objectives. Excessive complexity in a standard is a way to make it difficult for certain players to compete. This kind of thing doesn't happen in the IETF, of course... > Sorry - it is what it is - and that means that without specific end-use > requirements and a limitation to that, the NEA is really just another > wasted IETF effort in my opinion. The IETF has a good track record of standardizing things that other people invented. It has a much worse track record of creating brand-new standards. Alan DeKok. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Sun Aug 12 12:30:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKGKH-0006Un-62; Sun, 12 Aug 2007 12:30:01 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IKGKG-0006UY-3N for nea-confirm+ok@megatron.ietf.org; Sun, 12 Aug 2007 12:30:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKGKF-0006UQ-PJ for nea@ietf.org; Sun, 12 Aug 2007 12:29:59 -0400 Received: from elasmtp-dupuy.atl.sa.earthlink.net ([209.86.89.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKGKF-0003HP-Bx for nea@ietf.org; Sun, 12 Aug 2007 12:29:59 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=nqSOEZBKxjW9VVkqkvdtqQ1bphd84S0VxWZkD5rXyzO50O7oxiTpcrICw8iNryMF; 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 [24.23.176.93] (helo=tsg1) by elasmtp-dupuy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IKGK9-0005zL-Oh; Sun, 12 Aug 2007 12:29:53 -0400 Message-ID: <001601c7dcfe$03366990$6501a8c0@tsg1> From: "TS Glassey" To: "Alan DeKok" , "Stephen Hanna" References: <46BF095D.9090305@deployingradius.com> Subject: Re: [Nea] NEA requirements and internationalization Date: Sun, 12 Aug 2007 09:16:53 -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: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79adb20877213d426fb0d22d2db802a248350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.23.176.93 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org ----- Original Message ----- From: "Alan DeKok" To: "Stephen Hanna" Cc: Sent: Sunday, August 12, 2007 6:21 AM Subject: Re: [Nea] NEA requirements and internationalization > Stephen Hanna wrote: >> I think instead we should probably have a common >> requirement that says something like "The protocols >> MUST support encoding any strings intended for display >> to a user with an encoding standard that supports >> internationalization." Maybe we should also require >> that the protocols support language tags for those >> strings or even that they support language negotiation. > > Tags, yes. Negotiation, no. Each user on an end host in NEA will > understand at least one language, which can be configured statically > when the NEA client is configured. The server can remember those > associations. This means that the NEA Client must be interactively configured? > >> Or maybe we should avoid sending user-visible strings! > > I strongly recommend sending user-visible strings, much as that may > cause protocol problems. Many existing access protocols have provisions > for sending user-visible strings, but implementations don't use them. > When people are denied network access, they get a message that says > "failed", rather than anything informative. I dont... From a security sense this may invalidate the use of NEA in many instances including probably all of the ones you are shooting for. > > This lack of information causes many headaches for both users and > administrators. The sending of plain-text anywhere is a no-no from a security standpoint. > > I would say thet the protocol MUST have provisions for sending > messages that are intended to be displayed to the user. That implies that the system is up and running and that some instance of a shell or UI is open so that this messaging can take place. If the session is not open then a listener would need to be built for these messages. > > 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 Sun Aug 12 12:41:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKGV7-0006br-S5; Sun, 12 Aug 2007 12:41:13 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IKGV6-0006bk-I8 for nea-confirm+ok@megatron.ietf.org; Sun, 12 Aug 2007 12:41:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKGV6-0006bc-8K for nea@ietf.org; Sun, 12 Aug 2007 12:41:12 -0400 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKGV5-00081m-Iw for nea@ietf.org; Sun, 12 Aug 2007 12:41:12 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=K6ZJzANbNe6xFhW3LViVRvb8Bl0Mw+48L89ZwI/8WTPZSpRYAQQhGKXwm/3UPpiY; 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 [24.23.176.93] (helo=tsg1) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IKGUz-00083s-RE; Sun, 12 Aug 2007 12:41:06 -0400 Message-ID: <001701c7dcff$93e04c30$6501a8c0@tsg1> From: "TS Glassey" To: "Alan DeKok" References: <08A9A3213527A6428774900A80DBD8D804A1D8FF@xmb-sjc-222.amer.cisco.com> <023201c7dc39$fc2a0f90$174f7d40@home.glassey.com> <46BF1815.4080702@deployingradius.com> Subject: Re: [Nea] comments on draft-ietf-nea-requirements-03.txt Date: Sun, 12 Aug 2007 09:40:58 -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: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79615a85569f087ce88ab86ecfd4c22b01350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.23.176.93 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 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 Alan - I agree with most of what you were retorting, its more of an issue of using the NEA Effort to integrate a number of functions which were desinged for other protocols, into a homogenious infrastructure where the policy and stateful qualification of infrastructure components (including end-nodes and servers) is documented and controlled. There is NOTHING wrong with that goal - its a powerful one, the issue is how its achieved, and what each of the key operating goals of the NEA charter requires. If the goals are: 1) To allow for the qualification (from a stateful policy-centric manner) the 'admissibility' of a node into a secured or policy controlled network 2) To manage ongoing connectivity/entitlement rights from an already qualified node these are somewhat different tasks. One is based on qualifying a node and assigning it entitlement with regard to servers, routing, and access to the outside world, and the other (2) is a process which uses a subset of the qualifying tools used in (1) as part of an ongoing 'certification' process. The idea that NEA could detect an infected system is a specific implementation of a stateful security policy, and as such its not the real focus, the policy control framework and its implementing layers are. To that end the architecture of NEA needs to address the 'pre-installed systems' and their qualification at the level of the DHCP service probably and then later at the OS layer. That said I see the vision of the collector and policy aggregator's (local status nodes) but I dont see the language focusing on that per se. I main be missing the whole picture but I doubt it. That said, NEA as a WG can justify aggregating a set of predefined services as primatives from other WG's and other IETF initiatives, but this coming up with new nomenclature to describe something that has been done before a number of times seems like a waste to me... and I just dont get why its better for the key architect's here to redesign wheel's which already exist under the banner of NEA... Please forgive my acerbic response earlier but it is what it is. NEA is a good idea, redefining existing systems and frameworks with totally new nomencalture where it is not warranted, is not, and that is what my perception of what is going on here in NEA land is. We can use DHCP terms to define the client's and we can use PKIX policy terms to define the controlling messaging processes easily and that will eliminate the need to reinvent that wheel and will make those other IETF standards stronger IMHO. just my 2 cents. Todd ----- Original Message ----- From: "Alan DeKok" To: "todd glassey" Cc: Sent: Sunday, August 12, 2007 7:24 AM Subject: Re: [Nea] comments on draft-ietf-nea-requirements-03.txt > todd glassey wrote: >> NEA is not a new idea... >> There are already existing protocols which ... > > Yes. > >> That said - once again - I am for stripping out all the new terminology >> and >> for use of much more generic terms and process descriptions in the >> documents. > > I agree. > >> No end-use models make this another IETF fiasco > > I'm not sure I agree. Similar protocols have been deployed before, > with similar use models. Much of NEA is simply aggregating and > standardizing the previous ad-hoc collection of methods. > >> ... Because this type of effort without a MRD >> (Marketing Requirements Documentation) would have never gotten out of >> their >> internal blue-sky process. > > There are other corporate objectives. Excessive complexity in a > standard is a way to make it difficult for certain players to compete. > This kind of thing doesn't happen in the IETF, of course... > >> Sorry - it is what it is - and that means that without specific end-use >> requirements and a limitation to that, the NEA is really just another >> wasted IETF effort in my opinion. > > The IETF has a good track record of standardizing things that other > people invented. It has a much worse track record of creating brand-new > standards. > > Alan DeKok. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Sun Aug 12 12:55: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 1IKGjC-0007Sq-KY; Sun, 12 Aug 2007 12:55:46 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IKGjB-0007Si-DY for nea-confirm+ok@megatron.ietf.org; Sun, 12 Aug 2007 12:55:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKGjB-0007Sa-49 for nea@ietf.org; Sun, 12 Aug 2007 12:55:45 -0400 Received: from www.deployingradius.com ([216.240.42.17] helo=deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKGj9-0008K2-AU for nea@ietf.org; Sun, 12 Aug 2007 12:55:45 -0400 Received: from [192.168.1.102] (ottawa-hs-209-217-66-6.d-ip.magma.ca [209.217.66.6]) by deployingradius.com (Postfix) with ESMTP id 79E77A7161; Sun, 12 Aug 2007 09:55:38 -0700 (PDT) Message-ID: <46BF3B85.3030208@deployingradius.com> Date: Sun, 12 Aug 2007 12:55:33 -0400 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: TS Glassey Subject: Re: [Nea] NEA requirements and internationalization References: <46BF095D.9090305@deployingradius.com> <001601c7dcfe$03366990$6501a8c0@tsg1> In-Reply-To: <001601c7dcfe$03366990$6501a8c0@tsg1> 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: 4adaf050708fb13be3316a9eee889caa Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org TS Glassey wrote: >> Tags, yes. Negotiation, no. Each user on an end host in NEA will >> understand at least one language, which can be configured statically >> when the NEA client is configured. The server can remember those >> associations. > > This means that the NEA Client must be interactively configured? MAY, rather than MUST. Many sites will have a site-wide configuration saying "language used by everyone here." >> I strongly recommend sending user-visible strings, much as that may >> cause protocol problems. Many existing access protocols have provisions >> for sending user-visible strings, but implementations don't use them. >> When people are denied network access, they get a message that says >> "failed", rather than anything informative. > > I dont... From a security sense this may invalidate the use of NEA in > many instances including probably all of the ones you are shooting for. I'm not sure what you mean by that. I would like the ability for administrators to push messages to end users via NEA. This involves the *capability* to transport internationalized strings in NEA. However, those strings are informative to the end user, and opaque to the rest of NEA. > The sending of plain-text anywhere is a no-no from a security standpoint. I can understand this on the wide open net. For the chartered purpose (enterprises), I don't see why it's a problem. If you trust the NEA system enough to install the client, displaying text strings has minimal additional security impact. If you don't trust the NEA system, you won't get network access, and you won't see any strings transported in NEA. > That implies that the system is up and running and that some instance of > a shell or UI is open so that this messaging can take place. If the > session is not open then a listener would need to be built for these > messages. No. They can be thrown away. Many PPP implementations have done this for years. It's annoying, but widely accepted practice. Alan DeKok. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Sun Aug 12 13:03: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 1IKGqq-00052U-CZ; Sun, 12 Aug 2007 13:03:40 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IKGqo-00050E-Ng for nea-confirm+ok@megatron.ietf.org; Sun, 12 Aug 2007 13:03:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKGqo-0004yK-CM for nea@ietf.org; Sun, 12 Aug 2007 13:03:38 -0400 Received: from www.deployingradius.com ([216.240.42.17] helo=deployingradius.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKGqn-00044t-JE for nea@ietf.org; Sun, 12 Aug 2007 13:03:38 -0400 Received: from [192.168.1.102] (ottawa-hs-209-217-66-6.d-ip.magma.ca [209.217.66.6]) by deployingradius.com (Postfix) with ESMTP id 48C84A7161; Sun, 12 Aug 2007 10:03:34 -0700 (PDT) Message-ID: <46BF3D60.2090900@deployingradius.com> Date: Sun, 12 Aug 2007 13:03:28 -0400 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: TS Glassey Subject: Re: [Nea] comments on draft-ietf-nea-requirements-03.txt References: <08A9A3213527A6428774900A80DBD8D804A1D8FF@xmb-sjc-222.amer.cisco.com> <023201c7dc39$fc2a0f90$174f7d40@home.glassey.com> <46BF1815.4080702@deployingradius.com> <001701c7dcff$93e04c30$6501a8c0@tsg1> In-Reply-To: <001701c7dcff$93e04c30$6501a8c0@tsg1> 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: 7aafa0432175920a4b3e118e16c5cb64 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 TS Glassey wrote: > If the goals are: > > 1) To allow for the qualification (from a stateful policy-centric > manner) the 'admissibility' of a node into a secured or policy > controlled network > > 2) To manage ongoing connectivity/entitlement rights from an > already qualified node > > these are somewhat different tasks. I think they're the same task. Let me rephrase both goals into one statement: In order to achieve a certain level of network access, a node has to satisfy certain criteria. This satisfies goals (1) and (2) above. > One is based on qualifying a node > and assigning it entitlement with regard to servers, routing, and access > to the outside world, and the other (2) is a process which uses a subset > of the qualifying tools used in (1) as part of an ongoing > 'certification' process. I don't understand "ongoing". If a device does nothing, there are few reasons to re-certify it (other than changes in server policy). If a device requests different levels of access, it must be validated before being granted that access. We do this today. My laptop has a WEP key and/or an 802.1x id for wireless access. But I *still* have to enter a username && password to send email. And once if I send PGP signed email, I have a *different* set of criteria I have to meet before the message will be signed. > The idea that NEA could detect an infected > system is a specific implementation of a stateful security policy, and > as such its not the real focus, the policy control framework and its > implementing layers are. Yes. > Please forgive my acerbic response earlier but it is what it is. NEA is > a good idea, redefining existing systems and frameworks with totally new > nomencalture where it is not warranted, is not, and that is what my > perception of what is going on here in NEA land is. We can use DHCP > terms to define the client's and we can use PKIX policy terms to define > the controlling messaging processes easily and that will eliminate the > need to reinvent that wheel and will make those other IETF standards > stronger IMHO. I agree. Alan DeKok. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Sun Aug 12 14:44:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKIQ5-00071b-KK; Sun, 12 Aug 2007 14:44:09 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IKIQ5-00071V-Ax for nea-confirm+ok@megatron.ietf.org; Sun, 12 Aug 2007 14:44:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKIQ4-00071L-Q4 for nea@ietf.org; Sun, 12 Aug 2007 14:44:08 -0400 Received: from elasmtp-junco.atl.sa.earthlink.net ([209.86.89.63]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKIQ4-0002Jg-2x for nea@ietf.org; Sun, 12 Aug 2007 14:44:08 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=ThTD/oCoo9oM/M0xiCx4UgRwP+NuLRoU96B7C1X69b0wOvDwNgzgDMKgyfsMqch9; 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 [24.23.176.93] (helo=tsg1) by elasmtp-junco.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IKIQ2-0006wp-1E; Sun, 12 Aug 2007 14:44:06 -0400 Message-ID: <003401c7dd10$c3417290$6501a8c0@tsg1> From: "TS Glassey" To: "Alan DeKok" References: <46BF095D.9090305@deployingradius.com> <001601c7dcfe$03366990$6501a8c0@tsg1> <46BF3B85.3030208@deployingradius.com> Subject: Re: [Nea] NEA requirements and internationalization Date: Sun, 12 Aug 2007 11:31: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: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79295918915614e72966609a3a23b6f765350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.23.176.93 X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org ----- Original Message ----- From: "Alan DeKok" To: "TS Glassey" Cc: "Stephen Hanna" ; Sent: Sunday, August 12, 2007 9:55 AM Subject: Re: [Nea] NEA requirements and internationalization > TS Glassey wrote: >>> Tags, yes. Negotiation, no. Each user on an end host in NEA will >>> understand at least one language, which can be configured statically >>> when the NEA client is configured. The server can remember those >>> associations. >> >> This means that the NEA Client must be interactively configured? > > MAY, rather than MUST. Many sites will have a site-wide configuration > saying "language used by everyone here." So then you are suggesting that as part of the entitlement-enablement process that the client is interactively configured. Do you mean somewhat like setting up a PXE boot process? and does that mean that the basic client is BIOS level? - that's not a bad idea too. Intel's super BIOS has plenty of room in it and is available for additions like that too, so I could see NEA as something that HW manufacturers would want to include into their boot-processes. That also gives you a capability for routers and other infrastructure as well as appliances. > >>> I strongly recommend sending user-visible strings, much as that may >>> cause protocol problems. Many existing access protocols have provisions >>> for sending user-visible strings, but implementations don't use them. >>> When people are denied network access, they get a message that says >>> "failed", rather than anything informative. >> >> I dont... From a security sense this may invalidate the use of NEA in >> many instances including probably all of the ones you are shooting for. > > I'm not sure what you mean by that. What I am saying is that based on new requirements from the Courts (as of May 4th 2007) in the US there are now five specific tests for ESI (Electronicially Stored Information) into the Court's as evidence, and what that means is that in any system that 'may produce content that may come to be reviewed as evidence' will need to meet these new requirements. What that means to us, is that if we are designing technologies to meet specific control requirements, there are now new constraints on those systems which would come to be used in officia capacities. The justification for this is not worth arguling here but offlist if you want I can explain in detail which pieces of law constrain this claim per. BTW - I would involve Jorge, the IETF's Counsel in that offlizt discussion so that there was a 'IETF voice' there as well. And while Jorge may say that the civil courts have not affirmed my assertion, he cannot deny that I am before the US Appellate and that I do have a motion to affirm Judge Grimm's ruling as a basic rule for all courts in the US. My take is while I may lose my appeal, that they will affirm the Grimm ruling as it it the only chance the Courts have to keep functioning. That said, since there are new 'requirements' in operating official systems, NEA should address those too... and that said, passing plain-text about is a no-no > > I would like the ability for administrators to push messages to end > users via NEA. This involves the *capability* to transport > internationalized strings in NEA. However, those strings are > informative to the end user, and opaque to the rest of NEA. So do a table of messages based on the entitlement models supported and then publish UTF-8 strings of them in whatever language you want to support. > >> The sending of plain-text anywhere is a no-no from a security standpoint. > > I can understand this on the wide open net. For the chartered purpose > (enterprises), I don't see why it's a problem. Integrity of the Audit Process running inside the "Entity". Think of your average University for instance. How many would-be hackers are inside the Entity then. > > If you trust the NEA system enough to install the client, displaying > text strings has minimal additional security impact. If you don't trust > the NEA system, you won't get network access, and you won't see any > strings transported in NEA. > >> That implies that the system is up and running and that some instance of >> a shell or UI is open so that this messaging can take place. If the >> session is not open then a listener would need to be built for these >> messages. > > No. They can be thrown away. Many PPP implementations have done this > for years. It's annoying, but widely accepted practice. Depending what type of auditing and integrity of process model NEA is to support. > > Alan DeKok. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Sun Aug 12 21:38: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 1IKOtG-0008Uj-R5; Sun, 12 Aug 2007 21:38:42 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IKOtG-0008SK-Da for nea-confirm+ok@megatron.ietf.org; Sun, 12 Aug 2007 21:38:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKOtG-0008Rj-41 for nea@ietf.org; Sun, 12 Aug 2007 21:38:42 -0400 Received: from www.deployingradius.com ([216.240.42.17] helo=deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKOtE-00063O-2W for nea@ietf.org; Sun, 12 Aug 2007 21:38:41 -0400 Received: from [192.168.1.102] (ottawa-hs-209-217-66-6.d-ip.magma.ca [209.217.66.6]) by deployingradius.com (Postfix) with ESMTP id 8E901A7161; Sun, 12 Aug 2007 18:38:33 -0700 (PDT) Message-ID: <46BFB615.4090208@deployingradius.com> Date: Sun, 12 Aug 2007 21:38:29 -0400 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: TS Glassey Subject: Re: [Nea] NEA requirements and internationalization References: <46BF095D.9090305@deployingradius.com> <001601c7dcfe$03366990$6501a8c0@tsg1> <46BF3B85.3030208@deployingradius.com> <003401c7dd10$c3417290$6501a8c0@tsg1> In-Reply-To: <003401c7dd10$c3417290$6501a8c0@tsg1> 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: 0fa76816851382eb71b0a882ccdc29ac Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org TS Glassey wrote: >> MAY, rather than MUST. Many sites will have a site-wide configuration >> saying "language used by everyone here." > > So then you are suggesting that as part of the entitlement-enablement > process that the client is interactively configured. MAY be interactively configured. Or, as many administrators do, th process may be scripted. > What I am saying is that based on new requirements from the Courts (as > of May 4th 2007) in the US there are now five specific tests for ESI > (Electronicially Stored Information) into the Court's as evidence, and > what that means is that in any system that 'may produce content that may > come to be reviewed as evidence' will need to meet these new requirements. > > What that means to us, is that if we are designing technologies to meet > specific control requirements, there are now new constraints on those > systems which would come to be used in officia capacities. NEA is working on protocol level requirements and design. Logging, UI, and legal issues are (IMHO) out of scope. An NEA requirement that systems MAY transport user-visible strings is fine. However, certain implementations in certain jurisdictions MAY have additional requirements on what is done with those strings. If we design NEA for the lowest-common legal denominator, then we will have a system that does nothing. > That said, since there are new 'requirements' in operating official > systems, NEA should address those too... and that said, passing > plain-text about is a no-no I'm a little at a loss to see how we can design an access protocol that doesn't tell the user whether or not they've been granted access, or even if they've been denied. A list of canned status/error messages isn't good enough, as experience has shown. >> I would like the ability for administrators to push messages to end >> users via NEA. This involves the *capability* to transport >> internationalized strings in NEA. However, those strings are >> informative to the end user, and opaque to the rest of NEA. > > So do a table of messages based on the entitlement models supported and > then publish UTF-8 strings of them in whatever language you want to > support. Can we enumerate *enough* possible messages to be useful? I doubt it. >> I can understand this on the wide open net. For the chartered purpose >> (enterprises), I don't see why it's a problem. > > Integrity of the Audit Process running inside the "Entity". Think of > your average University for instance. How many would-be hackers are > inside the Entity then. Charter. We have it. We should focus on it. Universities are out of scope. Issues with deploying NEA inside of Universities are out of scope. If certain designs work in an enterprise, but not in a university, then issues with the university deployment are irrelevant. They are canards, and out of scope. >> [ re: informational messages ] >> No. They can be thrown away. Many PPP implementations have done this >> for years. It's annoying, but widely accepted practice. > > Depending what type of auditing and integrity of process model NEA is to > support. I'm not really sure what you mean by that. Informational messages are... informational. They have little definitive meaning. In contrast, messages like "you must upgrade now" are not informational. They impose normative requirements on the user, and should be logged, audited, etc. Alan DeKok. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Aug 13 08:36: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 1IKZ9d-0002ue-Fu; Mon, 13 Aug 2007 08:36:17 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IKZ9b-0002so-Rg for nea-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 08:36:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKZ9b-0002sg-I9 for nea@ietf.org; Mon, 13 Aug 2007 08:36:15 -0400 Received: from smtpa.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKZ9Z-0003al-9Q for nea@ietf.org; Mon, 13 Aug 2007 08:36:15 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpa.juniper.net with ESMTP; 13 Aug 2007 05:36:13 -0700 X-IronPort-AV: i="4.19,254,1183359600"; d="scan'208"; a="56084939:sNHT36565020" 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] NEA requirements and internationalization Date: Mon, 13 Aug 2007 08:35:57 -0400 Message-ID: In-Reply-To: <003401c7dd10$c3417290$6501a8c0@tsg1> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] NEA requirements and internationalization Thread-Index: AcfdEMpytGTomNazRhG+bYMGOKOirgAKt2zg References: <46BF095D.9090305@deployingradius.com> <001601c7dcfe$03366990$6501a8c0@tsg1> <46BF3B85.3030208@deployingradius.com> <003401c7dd10$c3417290$6501a8c0@tsg1> From: "Stephen Hanna" To: "TS Glassey" , "Alan DeKok" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Returning the focusing to internationalization... One easy way to determine the user's preferred language(s) is for the Posture Broker Client to read this information from the operating system or platform (e.g. POSIX locale, Java Locale, Windows Locale) and pass this information to the Posture Broker Server early in the NEA exchange. The Posture Broker Server can then attempt to adapt any human- readable messages to the user's preferences. Posture Broker Clients can provide ways to override the locale info if they want to get really fancy and Posture Broker Servers can ignore this info if they don't support the language(s) requested. But it's a good simple solution. This approach avoids the need for any administrative configuration, maintaining databases of user preferences, etc. It's used in HTTP (RFC 3282 Accept-Language tag) and in the TNC specs. Why not use this technique? Thanks, Steve _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Aug 13 10:15: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 1IKahq-0001aY-Gn; Mon, 13 Aug 2007 10:15:42 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IKahp-0001Wz-Bv for nea-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 10:15:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKahp-0001VP-0a for nea@ietf.org; Mon, 13 Aug 2007 10:15:41 -0400 Received: from www.deployingradius.com ([216.240.42.17] helo=deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKahn-0006C4-Bv for nea@ietf.org; Mon, 13 Aug 2007 10:15:40 -0400 Received: from [192.168.1.102] (ottawa-hs-209-217-66-6.d-ip.magma.ca [209.217.66.6]) by deployingradius.com (Postfix) with ESMTP id 02422A7161; Mon, 13 Aug 2007 07:15:29 -0700 (PDT) Message-ID: <46C0677B.6020705@deployingradius.com> Date: Mon, 13 Aug 2007 10:15:23 -0400 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: Stephen Hanna Subject: Re: [Nea] NEA requirements and internationalization References: <46BF095D.9090305@deployingradius.com> <001601c7dcfe$03366990$6501a8c0@tsg1> <46BF3B85.3030208@deployingradius.com> <003401c7dd10$c3417290$6501a8c0@tsg1> 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: d6b246023072368de71562c0ab503126 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Stephen Hanna wrote: > One easy way to determine the user's preferred language(s) > is for the Posture Broker Client to read this information > from the operating system or platform (e.g. POSIX locale, > Java Locale, Windows Locale) and pass this information to > the Posture Broker Server early in the NEA exchange. The > Posture Broker Server can then attempt to adapt any human- > readable messages to the user's preferences. Sounds good to me. > This approach avoids the need for any administrative > configuration, maintaining databases of user preferences, > etc. It's used in HTTP (RFC 3282 Accept-Language tag) and > in the TNC specs. Why not use this technique? Yes. Let's not re-invent the wheel. Alan DeKok. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Aug 13 10:46: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 1IKbBi-0008Ee-Vb; Mon, 13 Aug 2007 10:46:34 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IKbBh-0008EP-Jw for nea-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 10:46:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKbBh-0008EH-AM for nea@ietf.org; Mon, 13 Aug 2007 10:46:33 -0400 Received: from elasmtp-curtail.atl.sa.earthlink.net ([209.86.89.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKbBf-00078F-Sd for nea@ietf.org; Mon, 13 Aug 2007 10:46:33 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=RDuqStYd1bUobeKwSVxu0MXkpLmVI9m0rBIkowzy4FwcuqsC3U+j8dADod3FZOOk; 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 1IKbBc-0001S0-O6; Mon, 13 Aug 2007 10:46:29 -0400 Message-ID: <02d301c7ddb8$bcfda950$174f7d40@home.glassey.com> From: "todd glassey" To: "Alan DeKok" , "Stephen Hanna" References: <46BF095D.9090305@deployingradius.com> <001601c7dcfe$03366990$6501a8c0@tsg1> <46BF3B85.3030208@deployingradius.com> <003401c7dd10$c3417290$6501a8c0@tsg1> <46C0677B.6020705@deployingradius.com> Subject: Re: [Nea] NEA requirements and internationalization Date: Mon, 13 Aug 2007 07:46:23 -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: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec798fdc70484f5a37bdf0f300ae94fe0674350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.125.79.23 X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org ----- Original Message ----- From: "Alan DeKok" To: "Stephen Hanna" Cc: "TS Glassey" ; Sent: Monday, August 13, 2007 7:15 AM Subject: Re: [Nea] NEA requirements and internationalization > Stephen Hanna wrote: >> One easy way to determine the user's preferred language(s) >> is for the Posture Broker Client to read this information >> from the operating system or platform (e.g. POSIX locale, >> Java Locale, Windows Locale) and pass this information to >> the Posture Broker Server early in the NEA exchange. This works from a mechacanical standpoint ONLY if those systems are operated for use in a particular language-centric model. For instance, in most cases any English Systems will be based on English instances of the OS, but a Japanese Instance of say Solaris could easily be operated out of San Francisco, and in fact many are. That said the UNAME type output from the System is not satisfactory to be the sole determining anchor as to what Jurisdiction and Set of Laws that system is operated under and those while seemingly non-technical, are in fact pretty critical to all concerns. That said the only solution is some form of language and jurisdiction specific handshake between the components... Which is EXACTLY what we proposed to PKIX some years ago... A process for making a determination under what set of rules (language, laws, etc) a connection or event was to be processed. This is still missing from NEA and ALL of the PKIX efforts, and needs to be added IMHO. > > The >> Posture Broker Server can then attempt to adapt any human- >> readable messages to the user's preferences. You mean to the Administrator's preferences right? > > Sounds good to me. > >> This approach avoids the need for any administrative >> configuration, maintaining databases of user preferences, >> etc. It's used in HTTP (RFC 3282 Accept-Language tag) and >> in the TNC specs. Why not use this technique? Because Language is ONLY a part of what the NEA needs to be able to specify, but if language is to be the totality of the scope then fine... 3282's mechanism will work. Its just not expandable to include the other key info that NEA needs to pass as well. > > Yes. Let's not re-invent the wheel. > > Alan DeKok. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Aug 13 10:59:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKbNs-0006yi-Cq; Mon, 13 Aug 2007 10:59:08 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IKbNq-0006yc-UH for nea-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 10:59:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKbNq-0006yU-Km for nea@ietf.org; Mon, 13 Aug 2007 10:59:06 -0400 Received: from smtpb.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKbNp-0007Vc-EH for nea@ietf.org; Mon, 13 Aug 2007 10:59:06 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpb.juniper.net with ESMTP; 13 Aug 2007 07:59:04 -0700 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] NEA requirements and internationalization Date: Mon, 13 Aug 2007 10:58:43 -0400 Message-ID: In-Reply-To: <46C0677B.6020705@deployingradius.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] NEA requirements and internationalization Thread-Index: AcfdtHP55N6lRCL5TKWr/4JiMG14jgABdMbg References: <46BF095D.9090305@deployingradius.com> <001601c7dcfe$03366990$6501a8c0@tsg1> <46BF3B85.3030208@deployingradius.com> <003401c7dd10$c3417290$6501a8c0@tsg1> <46C0677B.6020705@deployingradius.com> From: "Stephen Hanna" To: "Alan DeKok" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Sounds like we're getting close to agreement on how to handle language and internationalization. Since we're still at the requirements stage, we should probably focus on requirements and step back from the details of how things will be done. I propose deleting requirement PA-8 and adding a new common requirement saying "For any strings intended for display to a user, the protocols MUST support adapting these strings to the user's language preferences." Comments? Thanks, Steve=20 -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com]=20 Sent: Monday, August 13, 2007 10:15 AM To: Stephen Hanna Cc: TS Glassey; nea@ietf.org Subject: Re: [Nea] NEA requirements and internationalization Stephen Hanna wrote: > One easy way to determine the user's preferred language(s) > is for the Posture Broker Client to read this information > from the operating system or platform (e.g. POSIX locale, > Java Locale, Windows Locale) and pass this information to > the Posture Broker Server early in the NEA exchange. The > Posture Broker Server can then attempt to adapt any human- > readable messages to the user's preferences. Sounds good to me. > This approach avoids the need for any administrative > configuration, maintaining databases of user preferences, > etc. It's used in HTTP (RFC 3282 Accept-Language tag) and > in the TNC specs. Why not use this technique? Yes. Let's not re-invent the wheel. Alan DeKok. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Aug 13 12:37: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 1IKcv0-0004P8-Jr; Mon, 13 Aug 2007 12:37:26 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IKcuz-0004P1-D3 for nea-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 12:37:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKcuz-0004Oq-2K for nea@ietf.org; Mon, 13 Aug 2007 12:37:25 -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 1IKcuy-0004B3-Jh for nea@ietf.org; Mon, 13 Aug 2007 12:37:24 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 13 Aug 2007 09:37:24 -0700 X-IronPort-AV: i="4.19,255,1183359600"; d="scan'208"; a="13227814:sNHT22135512" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l7DGbO0B030873; Mon, 13 Aug 2007 09:37:24 -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 l7DGbFiL026638; Mon, 13 Aug 2007 16:37:24 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); Mon, 13 Aug 2007 09:37:15 -0700 Received: from 10.21.93.151 ([10.21.93.151]) by xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) with Microsoft Exchange Server HTTP-DAV ; Mon, 13 Aug 2007 16:37:15 +0000 User-Agent: Microsoft-Entourage/11.3.6.070618 Date: Mon, 13 Aug 2007 09:37:13 -0700 Subject: Re: [Nea] NEA requirements and internationalization From: Kaushik Narayan To: Stephen Hanna , Alan DeKok Message-ID: Thread-Topic: [Nea] NEA requirements and internationalization Thread-Index: AcfdtHP55N6lRCL5TKWr/4JiMG14jgABdMbgAAN7GcM= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 13 Aug 2007 16:37:15.0462 (UTC) FILETIME=[34EEEE60:01C7DDC8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1958; t=1187023044; x=1187887044; c=relaxed/simple; s=sjdkim2002; 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]=20NEA=20requirements=20and=20internationalizati on |Sender:=20; bh=ouQjepAtOuPmv6MevHqU/E2Ulda/bGzEduk11qMVLkg=; b=Rh9S1IGl8JFAjFHX1R39PLjlfnXyhlRLW/MXBQHKSrFPNhppkkyoMSSGMoKeyj0WonjAPuTe CK2KHDgLieUJahoYQ/SKTaEX8WjM67gZPghPUozqb+8gq4cDXQJWvlH7; Authentication-Results: sj-dkim-2; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.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 Hi Steve, You proposed change seems fine to me; string handling is handled by layers other than PA and internationalization should be a common requirement. regards, kaushik On 8/13/07 7:58 AM, "Stephen Hanna" wrote: > Sounds like we're getting close to agreement on how to > handle language and internationalization. Since we're > still at the requirements stage, we should probably > focus on requirements and step back from the details > of how things will be done. > > I propose deleting requirement PA-8 and adding a new > common requirement saying "For any strings intended > for display to a user, the protocols MUST support > adapting these strings to the user's language preferences." > > Comments? > > Thanks, > > Steve > > -----Original Message----- > From: Alan DeKok [mailto:aland@deployingradius.com] > Sent: Monday, August 13, 2007 10:15 AM > To: Stephen Hanna > Cc: TS Glassey; nea@ietf.org > Subject: Re: [Nea] NEA requirements and internationalization > > Stephen Hanna wrote: >> One easy way to determine the user's preferred language(s) >> is for the Posture Broker Client to read this information >> from the operating system or platform (e.g. POSIX locale, >> Java Locale, Windows Locale) and pass this information to >> the Posture Broker Server early in the NEA exchange. The >> Posture Broker Server can then attempt to adapt any human- >> readable messages to the user's preferences. > > Sounds good to me. > >> This approach avoids the need for any administrative >> configuration, maintaining databases of user preferences, >> etc. It's used in HTTP (RFC 3282 Accept-Language tag) and >> in the TNC specs. Why not use this technique? > > Yes. Let's not re-invent the wheel. > > 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 Mon Aug 13 13:55: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 1IKe8L-0002mw-Rl; Mon, 13 Aug 2007 13:55:17 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IKe8K-0002lx-Up for nea-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 13:55:16 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKe8K-0002lp-If for nea@ietf.org; Mon, 13 Aug 2007 13:55:16 -0400 Received: from extu-mxob-1.symantec.com ([216.10.194.28]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IKe8K-0006zZ-1q for nea@ietf.org; Mon, 13 Aug 2007 13:55:16 -0400 Received: from tus1opsmtapin02.ges.symantec.com ([192.168.214.44]:54681) by extu-mxob-1.symantec.com with esmtp (Exim 4.66) (envelope-from ) id 1IKe8J-0007VY-6B; Mon, 13 Aug 2007 10:55:15 -0700 Received: from reserved-155-64-230-18.ges.symantec.com ([155.64.230.18] helo=TUS1XCHECNPIN01.enterprise.veritas.com) by tus1opsmtapin02.ges.symantec.com with esmtp (Exim 4.67) (envelope-from ) id 1IKe7r-0002Hh-0f; Mon, 13 Aug 2007 10:54:47 -0700 Received: from TUS1XCHEVSPIN05.enterprise.veritas.com ([155.64.231.27]) by TUS1XCHECNPIN01.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 10:54:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Nea] comments on requirements Date: Mon, 13 Aug 2007 10:54:35 -0700 Message-ID: In-Reply-To: <002a01c7db75$f4f63060$9a00a8c0@HP> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] comments on requirements Thread-Index: AcfbdfTXIaYZH7VITzOfX9PmEhc9cACXElTQ References: <002a01c7db75$f4f63060$9a00a8c0@HP> From: "Paul Sangster" To: "Chris Salter" , X-OriginalArrivalTime: 13 Aug 2007 17:54:46.0603 (UTC) FILETIME=[093AB9B0:01C7DDD3] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: cdeeb24e6b743a852c396a4af0e53c8f Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0913250179==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============0913250179== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7DDD3.063BAE36" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7DDD3.063BAE36 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Chris/Lauren, =20 Thanks for the comments. With respect to your concern, its certainly in our charter to identify and specify the use of a standards based PT protocol (which is why we're defining PT protocol requirements). We'll add some text to the scope section to make this more clear as this is critical to having an interoperable protocol stack for NEA. =20 Paul ________________________________ From: Chris Salter [mailto:csalter@comcast.net]=20 Sent: Friday, August 10, 2007 10:43 AM To: nea@ietf.org Subject: [Nea] comments on requirements =09 =09 We thought that overall the document was very clear and well written and we have no strong criticisms of the requirements. We do have one concern, however. =20 As we were reviewing, one thing we tried to keep in our minds is what would be needed in order to provide maximal interoperability between vendors. To us, this would mean something along the lines of being able to support a variety of operating systems on our network, being able to use a different NEA client for each OS, and having them all talk to the same NEA server. We would like to be able to use an access policy such as "Must have a firewall turned on, an anti-virus program running, and signatures must have been updated within the last 24 hours" without specifying which firewall or antivirus program the clients must use. =20 It seems to us that the use of a standard PA protocol, combined with a set of basic, standardized posture attributes that every NEA client and server understands, will make it possible to use a generic policy as described above. The use of a standard PB protocol that every NEA client and server understands will allow each client to package its integrity measurements in a format that the server will understand, parse and distribute responses from the server, and vice versa. =20 =20 The NEA document defined these protocols clearly, and we're happy to see the emphasis on standardizing them. Our concern is the lack of emphasis on standardizing PT. The document's scope section says that, when PA and PB are used with standard lower layer protocols, they provide interoperability. This may be true, but what lower layer protocols will be used? =20 =20 Even if an EAP method for transport of measurements is standardized and supported by all NEA components, a client and server must additionally support the same tunneled EAP method for authentication in order to be interoperable. There are examples today of different vendors who use the same access protocol (802.1x/RADIUS), but different tunneled EAP methods, and thus cannot interoperate. We would like to see language clearly stating that standardization of both an authentication protocol and a measurement transport protocol is required for true interoperability. =20 Lauren Giroux Chris Salter ------_=_NextPart_001_01C7DDD3.063BAE36 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Chris/Lauren,
 
Thanks for the comments.   With = respect to your=20 concern, its certainly in our charter to identify and specify the use of = a=20 standards based PT protocol (which is why we're defining PT protocol=20 requirements).  We'll add some text to the scope section to make = this more=20 clear as this is critical to having an interoperable protocol stack for=20 NEA.
 
Paul

From: Chris Salter=20 [mailto:csalter@comcast.net]
Sent: Friday, August 10, 2007 = 10:43=20 AM
To: nea@ietf.org
Subject: [Nea] comments on=20 requirements

We thought that overall the document was = very clear=20 and well written and we have no strong criticisms of the requirements. = We do=20 have one concern, however.

 

As we were reviewing, one thing we tried to = keep in=20 our minds is what would be needed in order to provide maximal = interoperability=20 between vendors.  To us, this would mean something along the = lines of=20 being able to support a variety of operating systems on our network, = being=20 able to use a different NEA client for each OS, and having them all = talk to=20 the same NEA server.  We would like to be able to use an access = policy=20 such as "Must have a firewall turned on, an anti-virus program = running, and=20 signatures must have been updated within the last 24 = hours" without=20 specifying which firewall or antivirus program the clients must=20 use.

 

It seems to us that the use of a standard PA = protocol,=20 combined with a set of basic, standardized posture attributes that = every NEA=20 client and server understands, will make it possible to use a generic = policy=20 as described above.  The use of a standard PB protocol that every = NEA=20 client and server understands will allow each client to package its = integrity=20 measurements in a format that the server will understand, parse and = distribute=20 responses from the server, and vice versa.  =

 

The NEA document defined these protocols = clearly, and=20 we’re happy to see the emphasis on standardizing them.  Our = concern is=20 the lack of emphasis on standardizing PT.  The document’s = scope section=20 says that, when PA and PB are used with standard lower layer = protocols, they=20 provide interoperability.  This may be true, but what lower layer = protocols will be used?  

 

Even if an EAP method for transport of = measurements is=20 standardized and supported by all NEA components, a client and server = must=20 additionally support the same tunneled EAP method for authentication = in order=20 to be interoperable. There are examples today of different vendors who = use the=20 same access protocol (802.1x/RADIUS), but different tunneled EAP = methods, and=20 thus cannot interoperate.  We would like to see language clearly = stating=20 that standardization of both an authentication protocol and a = measurement=20 transport protocol is required for true=20 interoperability.

 

Lauren=20 Giroux

Chris=20 Salter

------_=_NextPart_001_01C7DDD3.063BAE36-- --===============0913250179== 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 --===============0913250179==-- From nea-bounces@ietf.org Mon Aug 13 13:59:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKeCC-0005k8-1M; Mon, 13 Aug 2007 13:59:16 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IKeCA-0005jw-3x for nea-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 13:59:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKeC9-0005jh-Pg for nea@ietf.org; Mon, 13 Aug 2007 13:59:13 -0400 Received: from extu-mxob-2.symantec.com ([216.10.194.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKeC8-0006xv-Ad for nea@ietf.org; Mon, 13 Aug 2007 13:59:13 -0400 Received: from tus1opsmtapin02.ges.symantec.com ([192.168.214.44]:55783) by extu-mxob-2.symantec.com with esmtp (Exim 4.66) (envelope-from ) id 1IKeC7-0004P9-NQ; Mon, 13 Aug 2007 10:59:11 -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 1IKeC7-0002gD-5B; Mon, 13 Aug 2007 10:59:11 -0700 Received: from TUS1XCHEVSPIN05.enterprise.veritas.com ([155.64.231.27]) by TUS1XCHECNPIN03.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 10:59:10 -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] NEA requirements and internationalization Date: Mon, 13 Aug 2007 10:59:04 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] NEA requirements and internationalization Thread-Index: AcfdtHP55N6lRCL5TKWr/4JiMG14jgABdMbgAAYyfDA= References: <46BF095D.9090305@deployingradius.com><001601c7dcfe$03366990$6501a8c0@tsg1><46BF3B85.3030208@deployingradius.com><003401c7dd10$c3417290$6501a8c0@tsg1><46C0677B.6020705@deployingradius.com> From: "Paul Sangster" To: "Stephen Hanna" , "Alan DeKok" X-OriginalArrivalTime: 13 Aug 2007 17:59:10.0948 (UTC) FILETIME=[A6CA9240:01C7DDD3] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -4.0 (----) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org I agree it should be a common requirement since it may affect PB as well. Unless there are comments with your proposed text, we'll add it to the draft. Is everyone happy with the way this proposal is worded (particularly "protocols MUST support adapting")? This wording is oriented towards the processing of the strings by the protocol endpoints as opposed to the way its represented on the wire as per the old PA wording below: "PA-8 String attributes MUST support being encoded with an encoding standard that supports internationalization." Paul=20 > -----Original Message----- > From: Stephen Hanna [mailto:shanna@juniper.net]=20 > Sent: Monday, August 13, 2007 7:59 AM > To: Alan DeKok > Cc: nea@ietf.org > Subject: RE: [Nea] NEA requirements and internationalization >=20 > Sounds like we're getting close to agreement on how to handle=20 > language and internationalization. Since we're still at the=20 > requirements stage, we should probably focus on requirements=20 > and step back from the details of how things will be done. >=20 > I propose deleting requirement PA-8 and adding a new common=20 > requirement saying "For any strings intended for display to a=20 > user, the protocols MUST support adapting these strings to=20 > the user's language preferences." >=20 > Comments? >=20 > Thanks, >=20 > Steve=20 >=20 > -----Original Message----- > From: Alan DeKok [mailto:aland@deployingradius.com] > Sent: Monday, August 13, 2007 10:15 AM > To: Stephen Hanna > Cc: TS Glassey; nea@ietf.org > Subject: Re: [Nea] NEA requirements and internationalization >=20 > Stephen Hanna wrote: > > One easy way to determine the user's preferred language(s)=20 > is for the=20 > > Posture Broker Client to read this information from the operating=20 > > system or platform (e.g. POSIX locale, Java Locale, Windows Locale)=20 > > and pass this information to the Posture Broker Server early in the=20 > > NEA exchange. The Posture Broker Server can then attempt to=20 > adapt any=20 > > human- readable messages to the user's preferences. >=20 > Sounds good to me. >=20 > > This approach avoids the need for any administrative configuration,=20 > > maintaining databases of user preferences, etc. It's used=20 > in HTTP (RFC=20 > > 3282 Accept-Language tag) and in the TNC specs. Why not use this=20 > > technique? >=20 > Yes. Let's not re-invent the wheel. >=20 > Alan DeKok. >=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 Aug 13 18:09: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 1IKi5x-0006uB-9q; Mon, 13 Aug 2007 18:09:05 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IKi5v-0006tr-Qa for nea-confirm+ok@megatron.ietf.org; Mon, 13 Aug 2007 18:09:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKi5v-0006ti-Fr for nea@ietf.org; Mon, 13 Aug 2007 18:09:03 -0400 Received: from extu-mxob-2.symantec.com ([216.10.194.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKi5u-0007LM-8Y for nea@ietf.org; Mon, 13 Aug 2007 18:09:03 -0400 Received: from tus1opsmtapin01.ges.symantec.com ([192.168.214.43]:40842) by extu-mxob-2.symantec.com with esmtp (Exim 4.66) (envelope-from ) id 1IKi5t-0001qs-TN; Mon, 13 Aug 2007 15:09:01 -0700 Received: from reserved-155-64-230-19.ges.symantec.com ([155.64.230.19] helo=TUS1XCHECNPIN02.enterprise.veritas.com) by tus1opsmtapin01.ges.symantec.com with esmtp (Exim 4.67) (envelope-from ) id 1IKi5r-0000vu-MY; Mon, 13 Aug 2007 15:08:59 -0700 Received: from TUS1XCHEVSPIN05.enterprise.veritas.com ([155.64.231.27]) by TUS1XCHECNPIN02.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Aug 2007 15:08:59 -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] comments on draft-ietf-nea-requirements-03 Date: Mon, 13 Aug 2007 15:08:43 -0700 Message-ID: In-Reply-To: <90062D95-8D05-41D2-B8E8-2E8CDE7460E8@nist.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] comments on draft-ietf-nea-requirements-03 Thread-Index: AcfbkJXGNav6FJxbRJ2ap3XCG3bLegCVPBbQ References: <90062D95-8D05-41D2-B8E8-2E8CDE7460E8@nist.gov> From: "Paul Sangster" To: "Tim Polk" , "Kaushik Narayan" X-OriginalArrivalTime: 13 Aug 2007 22:08:59.0489 (UTC) FILETIME=[8CA86D10:01C7DDF6] X-Brightmail-Tracker: AAAAAQAAAUA= X-Spam-Score: -4.0 (----) X-Scan-Signature: 2d133cc328f58695161c98bb4f4dc213 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 Catching up on this thread and doing the discussed editing ... Some additional comments in-lined with [PS] prefix:=20 > -----Original Message----- > From: Tim Polk [mailto:tim.polk@nist.gov]=20 > Sent: Friday, August 10, 2007 1:52 PM > To: Kaushik Narayan > Cc: nea@ietf.org > Subject: Re: [Nea] comments on draft-ietf-nea-requirements-03 >=20 > Hi Kaushik, >=20 > Thanks for the prompt and enlightening response. In general,=20 > I am fine with your responses, so I deleted most of the=20 > quoted conversation. Responses on the remaining issues are inline. >=20 > On Aug 10, 2007, at 3:18 PM, Kaushik Narayan wrote: >=20 > > Hi Tim, > > > > Thanks for your comments. Please find my response inline. > > > > > > On 8/9/07 2:27 PM, "Tim Polk" wrote: > > > >> Section 2.0 Terminology > >> > >> Numerous terms are defined in terms of Posture Collectors=20 > and Posture=20 > >> Validators, but these terms are not defined until section 5. > >> > > > > > > > > > > The definitions currently cover all terms expect for the=20 > components of=20 > > the NEA client and NEA server stack defined in the reference model. > > There might > > not be sufficient context before Section 2.0 to properly=20 > define terms=20 > > such as Posture Collector, Posture Broker etc. We could=20 > certainly try=20 > > to add these definitions for the sake of completeness. > > > > Did you find lack of these definitions in Section 2.0 as=20 > effecting the=20 > > readability of the document. > > >=20 > Personally, I thought the definitions would be cleaner if the=20 > Posture Collector, Posture Broker, and Posture Validator were=20 > not addressed in the terminology section. [PS] Presume you would prefer we not mention those components in the terminology but instead try to be descriptive. We could try this or create terminology entries for the couple that we use. The challenge is several folks have asked for more precise term definitions so we used those names. We could also include references "Posture Collector (see section 5.1.1.1)"... >=20 > This is a stylistic question, though; the effect on=20 > readability was negligible. [PS] Sounds like its not worth a big change but we'll try to make a minor change to improve the situation. >=20 > > > > > > > >> > >> 5.1.1.2 Posture Broker Client > >> > >> Question 2: Does the WG envision a set of result attributes that > >> are mandatory to support for a posture broker client? This is > >> implied by the fourth bullet... > >> > > > > > > > > Yes. The document talks about the global posture assessment =20 > > attribute which > > is mandatory to support for posture broker clients and servers. > > > > > > >=20 > That makes sense to me, but it doesn't seem to be clearly=20 > specified as a > requirement. I don't think that is a significant problem,=20 > but if the =20 > WG has > consensus on this maybe we should clearly state it. [PS] We currently defined just the protocol capability (normative) requirements as these affect the WG protocol selection process (e.g. PB-1 says protocol must be able to carry the result attributes). We didn't define NEA Client/Server processing requirements such as what the Posture Broker Client must be able to do with different types of error/success result attributes. Hopefully this was the right decision as we didn't want to state requirements for all the semantics that NEA components would need to provide. When a PB protocol is selected and the result attributes defined they will describe their syntax and semantics. >=20 > >> > >> > >> Section 6. > >> > >> The example seems to assume that the OS is known. Stating that up > >> front would be helpful. > >> > >> Figure 2 and the text in 6.1.1.2 should be tightly=20 > coupled. The text > >> contains 13 numbered steps, but the figure has either 14 or 17 > >> steps (depending on how I count the flows between the pt client and > >> pt broker server). > >> > > > > > > > > Figure 2 is common to both examples of initial assessment, i.e. =20 > > Section > > 6.1.1 & 6.1.2. We did not intend a co-relation to a specific =20 > > example and > > that's why you notice the difference in steps. > > > > We will add text before Figure 2 to make this clear. > > > > > > >=20 > If a tight coupling between the figure and examples is not intended, =20 > more > information may be needed in Figure 2. For example "Pos Req" or a =20 > variant > of that is the label on five arrows. Those five arrows correspond to >=20 > (1) Posture validator(s) send PA messages containing the desired =20 > attributes > to the Posture Broker Server. > (2), (3) Posture Broker Server aggregates the PA messages and=20 > sends them > to the NEA client via the Posture Transport Server. > (4) The Posture Transport Client sends the aggregated PA=20 > messages to the > Posture Broker Client. > (5) The Posture Broker Client de-mulitplexes the PA messages and =20 > delivers > them to the appropriate Posture Collector(s). >=20 > We are asking a lot from the reader to sort all this out on their own! [PS] As Kaushik mentioned the diagram was supposed to be generic covering all initial assessment cases but as a result don't correspond well with the detailed use cases defined. We included the illustrations with the understanding that if they caused confusion we would consider removing them. We didn't feel strongly that they were needed but until now noone had mentioned that they were confusing. Do folks believe we should try to repair them or just drop both form the document (saving a page)? >=20 > > > > > >> 7.3 > >> > >> Requirement PB-4 > >> > >> If the posture broker needs to protect global assessment=20 > information > >> (see comments on 5.2.2), then MAY is too weak. MUST or=20 > possibly MAY > >> would be needed... > >> > > > > > > > > You mean MUST or SHOULD. This was discussed at the Prague IETF =20 > > meeting and > > moved from a SHOULD to a MAY. > > > > We certainly open this discussion within the WG. > > > > > > >=20 > No need to reopen discussion on this item. MAY is consistent with =20 > the rationale > provided for my comment on 5.2.2. I am satisfied that the WG has =20 > considered the > issue. [PS] Ok, their hasn't been strong support to move this back to SHOULD yet but if this occurs we could consider it. Note this is a requirement that applies to our protocol selection (the WG can still select a PB protocol that has strong security capabilities) even with a MAY in this requirement. >=20 > > > >> 8.1.2 > >> > >> The last sentence in this section seems to establish a=20 > requirement =20 > >> for > >> the NEA protocols. This material needs to be presented earlier and > >> represented as a section 7 requirement. > >> > >> Section 9.2, next to last paragraph: > >> > >> "For example, an enterprise might ask about the OS > >> version in the initial message dialog and after learning the > >> system is a Linux system, ask for a different/smaller set of > >> attributes specific to Linux then it would if the=20 > endpoint was a > >> Windows system. " > >> > >> This text answered a nagging question for me, when I=20 > encountered it. > >> While I was glad to learn how the wg intended to address the OS > >> identification problem, page 48 was a little too late. I believe > >> the possibility of a bootstrapping ought to be addressed earlier, =20 > >> and we > >> should clearly state which component (PB Client or PC?) resolves > >> this type of question... > > > > > > > > > > Would this be a requirement or update to the reference model to =20 > > state that > > the OS discovery would be handled by the Posture Collector. I am =20 > > not sure > > about the motivation to special case the OS type different=20 > from any =20 > > other > > standard attribute. > > > > Regards, > > kaushik > > > > > > >=20 > Once again, I was unintentionally vague.... >=20 > Interrogating an endpoint with respect to its OS seems inconsistent =20 > with the > definitions of posture and posture attribute in 2., so I couldn't =20 > figure out how the > posture validator(s) knew which OS a system ran. Without that =20 > knowledge, the > posture validator(s) can't know which attributes to request. >=20 > There are a couple of solutions: (1) request all possibly=20 > interesting =20 > posture > attributes for all recognized OSes, and sort out the results; or (2) =20 > interrogate the > endpoint and request teh attributes that make sense. >=20 > From the text in the security considerations, I deduced that =20 > discovery may be > performed by requesting posture attributes that describe the OS, =20 > etc. but that > this step was omitted from the example since multiple round trips =20 > complicate > the base concepts. This also implies the definitions of posture and =20 > posture > attribute could be expanded... >=20 > So, maybe it isn't a new requirement, its just an extra=20 > clause in the =20 > definition > of posture. We could add a couple clauses in the examples to make it more clear that the OS version is treated like other component (e.g. firewall) versions on the endpoint. >=20 > Thanks again, >=20 > Tim Polk >=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 Aug 14 12:57: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 1IKzi2-00064f-Jk; Tue, 14 Aug 2007 12:57:34 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IKzi1-000647-Jg for nea-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 12:57:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKzi1-00063z-9w for nea@ietf.org; Tue, 14 Aug 2007 12:57:33 -0400 Received: from smtpa.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKzhz-0000Qy-Se for nea@ietf.org; Tue, 14 Aug 2007 12:57:33 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpa.juniper.net with ESMTP; 14 Aug 2007 09:57:30 -0700 X-IronPort-AV: i="4.19,260,1183359600"; d="scan'208"; a="57410886:sNHT72587216" 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] comments on draft-ietf-nea-requirements-03 Date: Tue, 14 Aug 2007 12:57:14 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] comments on draft-ietf-nea-requirements-03 Thread-Index: AcfbkJXGNav6FJxbRJ2ap3XCG3bLegCVPBbQACQhFwA= References: <90062D95-8D05-41D2-B8E8-2E8CDE7460E8@nist.gov> From: "Stephen Hanna" To: "Paul Sangster" , "Tim Polk" , "Kaushik Narayan" X-Spam-Score: 0.0 (/) X-Scan-Signature: 65215b440f7ab00ca9514de4a7a89926 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 in favor of dropping the diagrams. I agree it's hard to match up the diagrams to the steps in the text. Using ASCII art, I think it will be hard to make this work. And without this correspondence, I don't think the diagrams add very much. In fact, they confuse things. That's just my personal opinion, BTW. Thanks, Steve -----Original Message----- From: Paul Sangster [mailto:Paul_Sangster@symantec.com]=20 Sent: Monday, August 13, 2007 6:09 PM To: Tim Polk; Kaushik Narayan Cc: nea@ietf.org Subject: RE: [Nea] comments on draft-ietf-nea-requirements-03 Catching up on this thread and doing the discussed editing ... Some additional comments in-lined with [PS] prefix:=20 > -----Original Message----- > From: Tim Polk [mailto:tim.polk@nist.gov]=20 > Sent: Friday, August 10, 2007 1:52 PM > To: Kaushik Narayan > Cc: nea@ietf.org > Subject: Re: [Nea] comments on draft-ietf-nea-requirements-03 >=20 > Hi Kaushik, >=20 > Thanks for the prompt and enlightening response. In general,=20 > I am fine with your responses, so I deleted most of the=20 > quoted conversation. Responses on the remaining issues are inline. >=20 > On Aug 10, 2007, at 3:18 PM, Kaushik Narayan wrote: >=20 > > Hi Tim, > > > > Thanks for your comments. Please find my response inline. > > > > > > On 8/9/07 2:27 PM, "Tim Polk" wrote: > > > >> Section 2.0 Terminology > >> > >> Numerous terms are defined in terms of Posture Collectors=20 > and Posture=20 > >> Validators, but these terms are not defined until section 5. > >> > > > > > > > > > > The definitions currently cover all terms expect for the=20 > components of=20 > > the NEA client and NEA server stack defined in the reference model. > > There might > > not be sufficient context before Section 2.0 to properly=20 > define terms=20 > > such as Posture Collector, Posture Broker etc. We could=20 > certainly try=20 > > to add these definitions for the sake of completeness. > > > > Did you find lack of these definitions in Section 2.0 as=20 > effecting the=20 > > readability of the document. > > >=20 > Personally, I thought the definitions would be cleaner if the=20 > Posture Collector, Posture Broker, and Posture Validator were=20 > not addressed in the terminology section. [PS] Presume you would prefer we not mention those components in the terminology but instead try to be descriptive. We could try this or create terminology entries for the couple that we use. The challenge is several folks have asked for more precise term definitions so we used those names. We could also include references "Posture Collector (see section 5.1.1.1)"... >=20 > This is a stylistic question, though; the effect on=20 > readability was negligible. [PS] Sounds like its not worth a big change but we'll try to make a minor change to improve the situation. >=20 > > > > > > > >> > >> 5.1.1.2 Posture Broker Client > >> > >> Question 2: Does the WG envision a set of result attributes that > >> are mandatory to support for a posture broker client? This is > >> implied by the fourth bullet... > >> > > > > > > > > Yes. The document talks about the global posture assessment =20 > > attribute which > > is mandatory to support for posture broker clients and servers. > > > > > > >=20 > That makes sense to me, but it doesn't seem to be clearly=20 > specified as a > requirement. I don't think that is a significant problem,=20 > but if the =20 > WG has > consensus on this maybe we should clearly state it. [PS] We currently defined just the protocol capability (normative) requirements as these affect the WG protocol selection process (e.g. PB-1 says protocol must be able to carry the result attributes). We didn't define NEA Client/Server processing requirements such as what the Posture Broker Client must be able to do with different types of error/success result attributes. Hopefully this was the right decision as we didn't want to state requirements for all the semantics that NEA components would need to provide. When a PB protocol is selected and the result attributes defined they will describe their syntax and semantics. >=20 > >> > >> > >> Section 6. > >> > >> The example seems to assume that the OS is known. Stating that up > >> front would be helpful. > >> > >> Figure 2 and the text in 6.1.1.2 should be tightly=20 > coupled. The text > >> contains 13 numbered steps, but the figure has either 14 or 17 > >> steps (depending on how I count the flows between the pt client and > >> pt broker server). > >> > > > > > > > > Figure 2 is common to both examples of initial assessment, i.e. =20 > > Section > > 6.1.1 & 6.1.2. We did not intend a co-relation to a specific =20 > > example and > > that's why you notice the difference in steps. > > > > We will add text before Figure 2 to make this clear. > > > > > > >=20 > If a tight coupling between the figure and examples is not intended, =20 > more > information may be needed in Figure 2. For example "Pos Req" or a =20 > variant > of that is the label on five arrows. Those five arrows correspond to >=20 > (1) Posture validator(s) send PA messages containing the desired =20 > attributes > to the Posture Broker Server. > (2), (3) Posture Broker Server aggregates the PA messages and=20 > sends them > to the NEA client via the Posture Transport Server. > (4) The Posture Transport Client sends the aggregated PA=20 > messages to the > Posture Broker Client. > (5) The Posture Broker Client de-mulitplexes the PA messages and =20 > delivers > them to the appropriate Posture Collector(s). >=20 > We are asking a lot from the reader to sort all this out on their own! [PS] As Kaushik mentioned the diagram was supposed to be generic covering all initial assessment cases but as a result don't correspond well with the detailed use cases defined. We included the illustrations with the understanding that if they caused confusion we would consider removing them. We didn't feel strongly that they were needed but until now noone had mentioned that they were confusing. Do folks believe we should try to repair them or just drop both form the document (saving a page)? >=20 > > > > > >> 7.3 > >> > >> Requirement PB-4 > >> > >> If the posture broker needs to protect global assessment=20 > information > >> (see comments on 5.2.2), then MAY is too weak. MUST or=20 > possibly MAY > >> would be needed... > >> > > > > > > > > You mean MUST or SHOULD. This was discussed at the Prague IETF =20 > > meeting and > > moved from a SHOULD to a MAY. > > > > We certainly open this discussion within the WG. > > > > > > >=20 > No need to reopen discussion on this item. MAY is consistent with =20 > the rationale > provided for my comment on 5.2.2. I am satisfied that the WG has =20 > considered the > issue. [PS] Ok, their hasn't been strong support to move this back to SHOULD yet but if this occurs we could consider it. Note this is a requirement that applies to our protocol selection (the WG can still select a PB protocol that has strong security capabilities) even with a MAY in this requirement. >=20 > > > >> 8.1.2 > >> > >> The last sentence in this section seems to establish a=20 > requirement =20 > >> for > >> the NEA protocols. This material needs to be presented earlier and > >> represented as a section 7 requirement. > >> > >> Section 9.2, next to last paragraph: > >> > >> "For example, an enterprise might ask about the OS > >> version in the initial message dialog and after learning the > >> system is a Linux system, ask for a different/smaller set of > >> attributes specific to Linux then it would if the=20 > endpoint was a > >> Windows system. " > >> > >> This text answered a nagging question for me, when I=20 > encountered it. > >> While I was glad to learn how the wg intended to address the OS > >> identification problem, page 48 was a little too late. I believe > >> the possibility of a bootstrapping ought to be addressed earlier, =20 > >> and we > >> should clearly state which component (PB Client or PC?) resolves > >> this type of question... > > > > > > > > > > Would this be a requirement or update to the reference model to =20 > > state that > > the OS discovery would be handled by the Posture Collector. I am =20 > > not sure > > about the motivation to special case the OS type different=20 > from any =20 > > other > > standard attribute. > > > > Regards, > > kaushik > > > > > > >=20 > Once again, I was unintentionally vague.... >=20 > Interrogating an endpoint with respect to its OS seems inconsistent =20 > with the > definitions of posture and posture attribute in 2., so I couldn't =20 > figure out how the > posture validator(s) knew which OS a system ran. Without that =20 > knowledge, the > posture validator(s) can't know which attributes to request. >=20 > There are a couple of solutions: (1) request all possibly=20 > interesting =20 > posture > attributes for all recognized OSes, and sort out the results; or (2) =20 > interrogate the > endpoint and request teh attributes that make sense. >=20 > From the text in the security considerations, I deduced that =20 > discovery may be > performed by requesting posture attributes that describe the OS, =20 > etc. but that > this step was omitted from the example since multiple round trips =20 > complicate > the base concepts. This also implies the definitions of posture and =20 > posture > attribute could be expanded... >=20 > So, maybe it isn't a new requirement, its just an extra=20 > clause in the =20 > definition > of posture. We could add a couple clauses in the examples to make it more clear that the OS version is treated like other component (e.g. firewall) versions on the endpoint. >=20 > Thanks again, >=20 > Tim Polk >=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 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Aug 14 18:41: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 1IL55A-0007PZ-JR; Tue, 14 Aug 2007 18:41:48 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IL559-0007PP-LM for nea-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 18:41:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL559-0007PH-A8 for nea@ietf.org; Tue, 14 Aug 2007 18:41:47 -0400 Received: from extu-mxob-2.symantec.com ([216.10.194.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IL557-00085g-Rv for nea@ietf.org; Tue, 14 Aug 2007 18:41:47 -0400 Received: from tus1opsmtapin01.ges.symantec.com ([192.168.214.43]:58328) by extu-mxob-2.symantec.com with esmtp (Exim 4.66) (envelope-from ) id 1IL557-0003Za-G6; Tue, 14 Aug 2007 15:41:45 -0700 Received: from reserved-155-64-230-19.ges.symantec.com ([155.64.230.19] helo=TUS1XCHECNPIN02.enterprise.veritas.com) by tus1opsmtapin01.ges.symantec.com with esmtp (Exim 4.67) (envelope-from ) id 1IL557-0005sS-D6; Tue, 14 Aug 2007 15:41:45 -0700 Received: from TUS1XCHEVSPIN05.enterprise.veritas.com ([155.64.231.27]) by TUS1XCHECNPIN02.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 15:41:44 -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] Comments on draft-ietf-nea-requirements-03.txt Date: Tue, 14 Aug 2007 15:41:19 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Comments on draft-ietf-nea-requirements-03.txt Thread-Index: AcfbqpkR2RO3Mv6hQ9aJC7GjQxG3nwDD1O2A References: From: "Paul Sangster" To: "Joseph Salowey (jsalowey)" , X-OriginalArrivalTime: 14 Aug 2007 22:41:44.0793 (UTC) FILETIME=[4A7BC490:01C7DEC4] X-Brightmail-Tracker: AAAAAQAAAUA= X-Spam-Score: -4.0 (----) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Thanks for the comments on the draft, some feedback is in-lined...=20 > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com]=20 > Sent: Friday, August 10, 2007 5:00 PM > To: nea@ietf.org > Subject: [Nea] Comments on draft-ietf-nea-requirements-03.txt >=20 > In general the document looks pretty good, but I do have a=20 > few comments. >=20 >=20 > Comments on Section 2 >=20 > - I expected to see a term along the lines of "Network=20 > Endpoint Assessment Authority." This is the entity who is=20 > trusted to perform the endpoint assessment. This is often=20 > related to the device owner in that it is either specific=20 > entities that are part of the device owner or a third party=20 > that has been delegated the authority to perform assessment=20 > by the device owner. =20 I presume by "device owner" your referring to the owner of the endpoint (device being assessed). Would you envision this authority being someone other than the NEA Server for this document? We discuss the trust relationships in section 8.1 and I suspect the NEA Server is fulfilling the role your describing. Did the lack of a term take away from readibility of the document? >=20 > Comments on Section 3 >=20 > - Is the case where an device is owned by an individual who=20 > contracts out compliance assessment to a third party in scope? No, our scope is pretty narrow as dictated by our charter. Section 3.2 paragraph 2 and 3 discusses the scope regarding ownership of the endpoint (device) vs. the network which is primarily about when both the endpoint and network are owned by the same entity. >=20 > Comment on Section 5 >=20 > Section 5.1.1.1 >=20 > - The last paragraph is asking the reader to "Recall that=20 > this is not a set of requirements for what each Posture=20 > Collector implementation must support." Where is the reader=20 > recalling this from? Also does this apply to the other sections. Will fix the text (recall isn't the best word). I'll review the other NEA component descriptions to see if a similar note is required. Its particularly important for the collector and validator where we expect many to exist and likely be pretty simple so not every responsibility listed may be applicable. >=20 > Section 5.1.1.1,2,3 >=20 > - 5.1.1.1 and 5.1.1.3 describe cryptographic protection at=20 > the transport, the collector, why wouldn't the broker be able=20 > to provide cryptographic protection as well? What are the=20 > goals of the cryptographic protection cited? Each layer provides different cryptographic security services. The PA layer security is providing true end to end protection even when the Posture Validator is located on a different system then the Posture Broker Server. This enables the end Posture Validator to cryptographically authenticate the Posture Collector and even provide private (encrypted) messages spanning multiple systems. This mentioned later in the document and in requirement PA-5 but we could make it more clear if you think it would help. =20 >=20 > Section 5.2.1 >=20 > - Is the application of cryptographic protection a matter of=20 > policy as in 5.2.3? Yes, we talk about this in section 8.2. >=20 > Section 6 >=20 > Section 6.1.1.x >=20 > - In this case it is not clear when network access is given=20 > or not, or really what it means to have network access. It=20 > is also not clear that the NEA client itself would the=20 > component that requests network access.=20 Not sure I follow. For example, in 6.1.1.x it's the last sentence of the last paragraph of 6.1.1.1 and step 16 in 6.1.1.2. Does this need to be more clear or were you referring to something to something else. =20 I agree its possible the NEA client doesn't necessarily directly request network access but it would be tied into the sequence of events during the entrance to the network. We expect their may be lower layer protocols below the NEA client that might directly request network access. One might argue they are part of the carrier protocol which we define to be part of PT (in the NEA Client) but some portion may be below it without damaging the model. >=20 > Section 7 >=20 > - C-5 - It seems that it might be advantageous for the PA and=20 > PB protocols to have knowledge of which transport they are=20 > running over. > This may help in determining which mode from c-10 to run in.=20 Agreed. We're reworded C-5 which should help as it might be helpful for PA/PB to know information about bandwidth, MTU, latency in order to optimize its payload sizes. We didn't want the PA or PB message formats to change for different PT protocols. Its now says: "The PA and PB protocols MUST be capable of operating over any PT protocol." The 2nd sentence remains as it was. >=20 > - PA-6 - It seems that different posture collectors may use=20 > different mechanisms to protect their attributes based on=20 > there requirements necessary to protect their data and the=20 > type of security relationship their components have. Is it=20 > necessary to specify protection at this layer? These=20 > different layers of cryptography introduce complexities=20 > around key management suggest multiple trust relationships.=20 The PA candidate protocols will specify how they provide these cryptographic protections to attributes if desired by a collector/validator. I'm not sure about 'different mechanisms' as they will all use what ever the PA protocol the NEA WG selects offers. The WG did discuss the cryptography at multiple layers issue a few times most recently in Prague and agreed we wanted support for end to end security even when the Posture Validator was remote from the Posture Broker Server. (We did however downgrade the PB protocol to a MAY for having to provide such cryptographic mechanisms). =20 >=20 > - PT-6 What does "This MAY occur by leveraging by-products=20 > (e.g., keys) supplied by the PB protocol authentication."=20 > mean and is it important at this level of requirements. This text was removed from the next version of the I-D, but it used to refer to cryptographic binding between protocol layers by exposing by-products (derived) keying material to higher layers (also might be nice for channel binding if desired). The text is now gone based on other feedback. Of course candidate protocols may offer this feature. =20 >=20 > Section 8=20 >=20 > - Section 8.1 - the discussion of trust left me a bit unsatisfied. > There are lots of components (PC,PV,etc.) in the NEA system=20 > that have the requirement for a cryptographic basis for=20 > trust. This section glosses over trust between components in=20 > favor of discussing a NEA Client and NEA Server. Since the=20 > document treats these as composed of separate components with=20 > apparently their own trust relationships the should be=20 > discussed in this section. Not sure how to address your comment. Do you have any proposed text or even specific boundaries to make this more clear? I'm not opposed to doing this particularly if it's a key trust boundary. The trust section focuses on the key boundaries between components where trust is essential. We didn't focus on trust issues between some components that we expected (or even assumed by charter) to be co-located. >=20 > Section 9=20 >=20 > - Just a comment that there may be benefit to the endpoint=20 > user to have their compliance checked, NEA should be as much=20 > about protecting the end point rather than protecting the=20 > client. Most of the document seems OK with the respect, but=20 > it something to keep in mind.=20 Agree, so you suggesting we highlight this elsewhere in the spec (since its not a privacy topic)? We did try to mention this including in use case example section 6.1.2.1. >=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 Aug 14 20:42:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL6xp-00050V-RN; Tue, 14 Aug 2007 20:42:21 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IL6xo-00050P-GK for nea-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 20:42:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL6xo-00050H-4s for nea@ietf.org; Tue, 14 Aug 2007 20:42:20 -0400 Received: from extu-mxob-2.symantec.com ([216.10.194.135]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IL6xm-0000d3-DL for nea@ietf.org; Tue, 14 Aug 2007 20:42:19 -0400 Received: from tus1opsmtapin02.ges.symantec.com ([192.168.214.44]:59277) by extu-mxob-2.symantec.com with esmtp (Exim 4.66) (envelope-from ) id 1IL6xl-0007w7-Ag; Tue, 14 Aug 2007 17:42:17 -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 1IL6xl-0001sK-6n; Tue, 14 Aug 2007 17:42:17 -0700 Received: from TUS1XCHEVSPIN05.enterprise.veritas.com ([155.64.231.27]) by TUS1XCHECNPIN02.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 17:42:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] comments on draft-ietf-nea-requirements-03.txt Date: Tue, 14 Aug 2007 17:41:53 -0700 Message-ID: In-Reply-To: <08A9A3213527A6428774900A80DBD8D804A1D8FF@xmb-sjc-222.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] comments on draft-ietf-nea-requirements-03.txt Thread-Index: Acfbx/VbZjlPjyE8Ql6tTL3YpjY4XAC/h1Qg References: <08A9A3213527A6428774900A80DBD8D804A1D8FF@xmb-sjc-222.amer.cisco.com> From: "Paul Sangster" To: "Nancy Winget (ncamwing)" , X-OriginalArrivalTime: 15 Aug 2007 00:42:17.0035 (UTC) FILETIME=[213C51B0:01C7DED5] X-Brightmail-Tracker: AAAAAQAAAUA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 7c1a129dc3801d79d40c5ca8dee767eb Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Thanks for the comments, some feedback is in-lined...=20 > -----Original Message----- > From: Nancy Winget (ncamwing) [mailto:ncamwing@cisco.com]=20 > Sent: Friday, August 10, 2007 8:30 PM > To: nea@ietf.org > Subject: [Nea] comments on draft-ietf-nea-requirements-03.txt=20 >=20 > In general the draft is a great improvement over the last=20 > revision. I still have a few comments/questions: > =20 > Section 2 > --------- > * while the PA, PB and PT are described in Section 5, it=20 > would be good to give summary definitions to these here as=20 > they are referenced=20 This comment is similar to Tim's about using words (Posture Collector) the reader doesn't yet know in the terminology. We chose to define the reference model in section 5 while having most of the terms defined up front. We'll review the spec and see if we can figure out how to reduce the dependance on section 5 when reading section 2. One option is to move/copy the defs from section 5 into the terminology and massage section 5 to not repeat what has already been defined too much. >=20 > Section 5 > ---------- > * The Posture Collector as described in 5.1.1.1 states: > " Receiving attributes containing remediation instructions on=20 > how to update the component(s) on the endpoint. This could=20 > require the collector to interact with the user, owner=20 > and/or a remediation server." > which seems somewhat contradictory or needs further=20 > elaboration when > relating to the statement in the Posture Broker Client=20 > description of > 5.1.1.2: > " Providing user notification about the global assessment=20 > decision and other user messages sent by the NEA Server." > If the PB is maintaining a more "global" state, this implies=20 > that it may "reassess" and modify the "remediation" as=20 > provided by the server. > Or what is meant by "global assessment" (as that result=20 > could imply different actions versus the collection of=20 > "individual assessments" > belonging to a particular Posture Collector. The component level (e.g. firewall) level assessments and remediation instructions would go to the firewall Posture Collector. The global assessment goes to the Posture Broker Client as it handles the overall decision. So maybe its confusing but both the Posture Collector and Posture Broker Client could receive attributes at the end of an assessment (e.g. the Collector on how to remediate its associated security mechanism and the Broker on the global assessment decision). To have an integrated user interface, the Posture Broker Client implementation may provide an interface to the Collectors for providing remediation instructions to the user (this is outside the scope of this doc as we're getting into implementation's detailed designs). We'll edit the paragraph about the Posture Broker Client (para 3) to help make this more clear. >=20 > * 5.1.1.1 states "...offering cryptographic protection to the=20 > attributes returned." > - protection from whom? Is it protecting it from the=20 > layers within the NEA client (e.g. > Protected from the PB and PT) as it is provided by the PA?=20 Yes its providing end to end security protections. This is more obviously needed when the Posture Validator is remote from the Posture Broker Server. This enables the Posture Validator to cryptographically authenticate the specific collector, check the integrity of the posture received, and protect the confidentiality of the posture sent (which might include PII or other information an attacker might use for vulnerability scanning/fingerprinting). We discussed this in Prague and in prior e-mail threads. Note that we downgraded the requirement for PB security to a MAY. >=20 > * 5.1.1.3 what are the threat models addressed in "providing=20 > cryptographic protection > for the message dialog between the NEA Client and NEA Server"? This is discussed in the security considerations section. The PT security protections against passive and active attacks again the server authentication, optional endpoint authentication, eavesdropping, integrity of the PT, PB and PA payloads, MITM, replay, etc. Note that its optional to deploy PT security although one might expect this would be common (much more so then PB security). >=20 > * Figure 1 is somewhat confusing as the PA, PB and PT are=20 > drawn across the client and server, but the descriptions=20 > infer that the PA flow from PA to PB to PT and up back up on=20 > the other end. These are encapsulating "protocols" (as per our charter terminology). They are shown as horizonal protocol flows because those are the entities that see the data exchanged. > While it is understood that the communication "targets" are=20 > across, the security implications and considerations must=20 > take into account the threats that may occur while the=20 > information is flowing through the different nodes. For=20 > instance, there may be multiple nodes supporting the "NEA=20 > Server" and thus the transport between the Posture Validators=20 > and Posture Broker (and Posture Transport Server[s]) must=20 > also be described in the security considerations.=20 Correct we do discuss this in security considerations section (search for "remote", see section 8.1.3, section 8.2, 8.3.2 ...) This is the reason for PA security protections to be required. With that said I believe its out of scope for the Posture Transport Client, Posture Broker Client and Posture Collectors to be on different nodes. Similarly its out of scope for the Posture Transport Server and Posture Broker Server to be on different nodes. So we're just including the one case which you mentioned. >=20 > * 5.1.2.1 (Posture Validator) > "Requesting attributes froma Posture Collector".....does=20 > this mean that the > Posture Collector is uniquely identified within an NEA=20 > client? Or does the client > determine which PC to route the request to? (this text=20 > infers the former, but > given the "global assessment" of the Posture Broker, it's not clear. We don't specify a particular PC/PV identification scheme but mention 3 possible approaches (section 5.1.1.1 P2 and 5.1.2.1 P2) that the PB protocol candidates will need to specify how their approach works. Of course we require in PB-2 that the PB protocol can carry these identifiers. >=20 >=20 > Section 7 > ---------- >=20 > * C-2: a nit, by "after the endpoint has gained normal=20 > network"......the intent is really > "during the endpoint's session in the network"? =20 We've reworded C-2 in the next I-D so these words are removed. The new C-2 (merged with the old C-3) says: "C-2 NEA protocols SHOULD provide a way for both the NEA Client and the NEA Server to initiate a posture assessment or reassessment as needed." >=20 > * C-4: who are the intermediaries? Since there are multiple=20 > Posture Collectors, Validators, Transports, there needs to be=20 > clarification on the message flow as the flow say, between a=20 > particular Posture Validator to Broker to Transport server=20 > are authorized. Intermediaries are discussed in section 8.1.2. I believe this requirement is oriented towards network-based intermediaries and not hostile components on the endpoint. Hostile components on the endpoint are out of scope for NEA (see section 8.1.1). We could edit it to say "... attacks by network-based intermediaries and other endpoints ..." if that makes it more clear? >=20 > * C-7, C-9: it would be good to quantify the "scale" and a=20 > reasonably expected number of NEA clients and Posture=20 > Validators. Is the scale on the order of 100's, 1000's, 10K? Suggestions on how to come up with an appropriate number that will work for a very wide variety of potential deployments? Text suggestions are welcome. We struggled with this issue as well and ultimately will probably be part of the PB protocol submission. For example, if the PB protocol candidate assigns static UUIDs to each PC and PV then the namespace needs to be very large. If the PC and PV naming is dynamically generated based on a per NEA Client basis then the number can be *much* smaller (much higher then the largest number of PCs we expect will ever be on a single node). If the naming is based on message content information (used in the subscription model) then a large number is somewhere in between. Our thinking was for the WG to apply judgement when evaluation candidate protocols. >=20 > * In Section 7.2, there are many requirements for enabling=20 > the Posture Validator. Shouldn't there be allowance for the=20 > Posture attributes to be sent unsolicited from the Posture=20 > Collector to the Validators as well? Not sure I follow, but we do allow for the Posture Collector to proactively send Posture Attributes without the Posture Validator requesting them. For example, this could be by having pre-configured client policy stating which attributes to send during a network connection attempt to a particular NEA Server (this one is discussed in a couple places in the spec including section 5.1.1.2 P1 and 9.2 P1-3. >=20 > * PA-6: clarification is needed on the "end-to-end" security=20 > across an NEA deployment. The model in Figure 1 abstracts=20 > the layers as there may be different deployments, and how the=20 > protection is carried out can be dependent on the=20 > instatiation of the model. It is not clear why the=20 > protection needs to be a hard requirement vs. a "MAY" at this layer. See feedback above and to Joe Salowey's comments about this topic. Your comment above highlighted why this was needed (Posture Validator on different node from Posture Broker Server). >=20 > * PA-7: I can see this being true for the server side, but=20 > why is this required on the client? Encrypted attributes and other binary data could be sent by the client and encrypted remediation instructions and other binary data could be sent by the server. The PA protocol needs to allow such data to be transported. >=20 > * PB-4: "The PB protocol MAY support authentication, integrity and =20 > confidentiality protection for the attribute messages it =20 > carries between an NEA Client and Server. " What=20 > is meant by=20 > "NEA Client and Server", is the intent to protect a=20 > layer of protection > between the brokers? Yes we could be more specific here. Will change to "Posture Broker Client and Posture Broker Server". >=20 > * PT-6: "The PT protocol MUST be capable of supporting mutual =20 > authentication between the Posture Transport Client=20 > and the =20 > Posture Transport Server. This MAY occur by leveraging by-=20 > products (e.g., keys) supplied by the PB protocol =20 > authentication." > I don't see how the PB protocol helps here? This text was changed based on other comments but the example was thinking about cryptographic bindings for EAP tunnels or potentially channel bindings in other environments. =20 >=20 >=20 > Section 8.1: > - Components can really mean components within an NEA=20 > Client or Server and > the "general" network components as well. It is unclear in either > 8.1 and > 8.1.1 what components are being referred to. It would be Same comments as above in this e-mail about trust boundaries. =20 Also we hope to improve the terminology around components so NEA components are easier to identify vs. other software components (e.g. firewall) on the endpoint which might move to a different term. With that said intermediaries on the network are not referred to as components in this spec. Currently, components specifically part of the NEA reference model are described as "NEA [optional qualifier] component" or something similar ("components in the NEA system") to help with readibility. Section 8.1's components are about the components within the NEA reference model. =20 > better to separate > the threat models within the "NEA component" and between=20 > an "NEA Client" and > "NEA Server" and the rest of the network components (that=20 > are not NEA participants). The trust model discussions are organized this way. Because of our trust model for the NEA client and server components, the threats primarily are those posed from the network to the network protocols not intra-NEA client or intra-NEA server except for the remote Posture Validator case. So section 8.3.x is organized by network born attacks which seems desired from my read of RFC 3552. If you have some specific changes that would help improve the section, we're happy to consider them. >=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 Aug 14 20:51:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL76S-0002Ot-Oa; Tue, 14 Aug 2007 20:51:16 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IL76R-0002Om-Lw for nea-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 20:51:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL76R-0002Oe-9o for nea@ietf.org; Tue, 14 Aug 2007 20:51:15 -0400 Received: from extu-mxob-1.symantec.com ([216.10.194.28]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IL76P-0000lf-Rj for nea@ietf.org; Tue, 14 Aug 2007 20:51:15 -0400 Received: from tus1opsmtapin02.ges.symantec.com ([192.168.214.44]:32878) by extu-mxob-1.symantec.com with esmtp (Exim 4.66) (envelope-from ) id 1IL76P-0002bH-77; Tue, 14 Aug 2007 17:51:13 -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 1IL75s-0002UM-3j; Tue, 14 Aug 2007 17:50:40 -0700 Received: from TUS1XCHEVSPIN05.enterprise.veritas.com ([155.64.231.27]) by TUS1XCHECNPIN03.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Aug 2007 17:50: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] comments on draft-ietf-nea-requirements-03 Date: Tue, 14 Aug 2007 17:50:17 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] comments on draft-ietf-nea-requirements-03 Thread-Index: AcfbkJXGNav6FJxbRJ2ap3XCG3bLegCVPBbQACQhFwAAF/PKsA== References: <90062D95-8D05-41D2-B8E8-2E8CDE7460E8@nist.gov> From: "Paul Sangster" To: "Stephen Hanna" , "Tim Polk" X-OriginalArrivalTime: 15 Aug 2007 00:50:39.0981 (UTC) FILETIME=[4D03C9D0:01C7DED6] X-Brightmail-Tracker: AAAAAQAAAUA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 841b5d6ad57042632519d2198f34cc8d Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Would anyone like to argue that the diagrams (figure 2 and 3) are important to remain (justifying their use of nearly 1 page of the spec)? > -----Original Message----- > From: Stephen Hanna [mailto:shanna@juniper.net]=20 > Sent: Tuesday, August 14, 2007 9:57 AM > To: Paul Sangster; Tim Polk; Kaushik Narayan > Cc: nea@ietf.org > Subject: RE: [Nea] comments on draft-ietf-nea-requirements-03 >=20 > I'm in favor of dropping the diagrams. I agree it's hard to=20 > match up the diagrams to the steps in the text. Using ASCII=20 > art, I think it will be hard to make this work. And without=20 > this correspondence, I don't think the diagrams add very=20 > much. In fact, they confuse things. >=20 > That's just my personal opinion, BTW. >=20 > Thanks, >=20 > Steve >=20 > -----Original Message----- > From: Paul Sangster [mailto:Paul_Sangster@symantec.com] > Sent: Monday, August 13, 2007 6:09 PM > To: Tim Polk; Kaushik Narayan > Cc: nea@ietf.org > Subject: RE: [Nea] comments on draft-ietf-nea-requirements-03 >=20 > Catching up on this thread and doing the discussed editing ... >=20 > Some additional comments in-lined with [PS] prefix:=20 >=20 > > -----Original Message----- > > From: Tim Polk [mailto:tim.polk@nist.gov] > > Sent: Friday, August 10, 2007 1:52 PM > > To: Kaushik Narayan > > Cc: nea@ietf.org > > Subject: Re: [Nea] comments on draft-ietf-nea-requirements-03 > >=20 > > Hi Kaushik, > >=20 > > Thanks for the prompt and enlightening response. In general, I am=20 > > fine with your responses, so I deleted most of the quoted=20 > > conversation. Responses on the remaining issues are inline. > >=20 > > On Aug 10, 2007, at 3:18 PM, Kaushik Narayan wrote: > >=20 > > > Hi Tim, > > > > > > Thanks for your comments. Please find my response inline. > > > > > > > > > On 8/9/07 2:27 PM, "Tim Polk" wrote: > > > > > >> Section 2.0 Terminology > > >> > > >> Numerous terms are defined in terms of Posture Collectors > > and Posture > > >> Validators, but these terms are not defined until section 5. > > >> > > > > > > > > > > > > > > > The definitions currently cover all terms expect for the > > components of > > > the NEA client and NEA server stack defined in the=20 > reference model. > > > There might > > > not be sufficient context before Section 2.0 to properly > > define terms > > > such as Posture Collector, Posture Broker etc. We could > > certainly try > > > to add these definitions for the sake of completeness. > > > > > > Did you find lack of these definitions in Section 2.0 as > > effecting the > > > readability of the document. > > > > >=20 > > Personally, I thought the definitions would be cleaner if=20 > the Posture=20 > > Collector, Posture Broker, and Posture Validator were not=20 > addressed in=20 > > the terminology section. >=20 > [PS] Presume you would prefer we not mention those components=20 > in the terminology but instead try to be descriptive. We=20 > could try this or create terminology entries for the couple=20 > that we use. The challenge is several folks have asked for=20 > more precise term definitions so we used those names. We=20 > could also include references "Posture Collector (see section=20 > 5.1.1.1)"... >=20 > >=20 > > This is a stylistic question, though; the effect on readability was=20 > > negligible. >=20 > [PS] Sounds like its not worth a big change but we'll try to=20 > make a minor change to improve the situation. >=20 > >=20 > > > > > > > > > > > >> > > >> 5.1.1.2 Posture Broker Client > > >> > > >> Question 2: Does the WG envision a set of result attributes that=20 > > >> are mandatory to support for a posture broker client? This is=20 > > >> implied by the fourth bullet... > > >> > > > > > > > > > > > > Yes. The document talks about the global posture assessment=20 > > > attribute which is mandatory to support for posture=20 > broker clients=20 > > > and servers. > > > > > > > > > > >=20 > > That makes sense to me, but it doesn't seem to be clearly=20 > specified as=20 > > a requirement. I don't think that is a significant problem, but if=20 > > the WG has consensus on this maybe we should clearly state it. >=20 > [PS] We currently defined just the protocol capability=20 > (normative) requirements as these affect the WG protocol=20 > selection process (e.g. > PB-1 says protocol must be able to carry the result=20 > attributes). We didn't define NEA Client/Server processing=20 > requirements such as what the Posture Broker Client must be=20 > able to do with different types of error/success result=20 > attributes. Hopefully this was the right decision as we=20 > didn't want to state requirements for all the semantics that=20 > NEA components would need to provide. When a PB protocol is=20 > selected and the result attributes defined they will describe=20 > their syntax and semantics. >=20 > >=20 > > >> > > >> > > >> Section 6. > > >> > > >> The example seems to assume that the OS is known. =20 > Stating that up=20 > > >> front would be helpful. > > >> > > >> Figure 2 and the text in 6.1.1.2 should be tightly > > coupled. The text > > >> contains 13 numbered steps, but the figure has either 14 or 17=20 > > >> steps (depending on how I count the flows between the pt=20 > client and=20 > > >> pt broker server). > > >> > > > > > > > > > > > > Figure 2 is common to both examples of initial assessment, i.e. =20 > > > Section > > > 6.1.1 & 6.1.2. We did not intend a co-relation to a=20 > specific example=20 > > > and that's why you notice the difference in steps. > > > > > > We will add text before Figure 2 to make this clear. > > > > > > > > > > >=20 > > If a tight coupling between the figure and examples is not=20 > intended,=20 > > more information may be needed in Figure 2. For example=20 > "Pos Req" or=20 > > a variant of that is the label on five arrows. Those five arrows=20 > > correspond to > >=20 > > (1) Posture validator(s) send PA messages containing the desired=20 > > attributes to the Posture Broker Server. > > (2), (3) Posture Broker Server aggregates the PA messages and sends=20 > > them to the NEA client via the Posture Transport Server. > > (4) The Posture Transport Client sends the aggregated PA=20 > messages to=20 > > the Posture Broker Client. > > (5) The Posture Broker Client de-mulitplexes the PA messages and=20 > > delivers them to the appropriate Posture Collector(s). > >=20 > > We are asking a lot from the reader to sort all this out on=20 > their own! >=20 > [PS] As Kaushik mentioned the diagram was supposed to be=20 > generic covering all initial assessment cases but as a result=20 > don't correspond well with the detailed use cases defined. =20 > We included the illustrations with the understanding that if=20 > they caused confusion we would consider removing them. We=20 > didn't feel strongly that they were needed but until now=20 > noone had mentioned that they were confusing. Do folks=20 > believe we should try to repair them or just drop both form=20 > the document (saving a page)? >=20 > >=20 > > > > > > > > >> 7.3 > > >> > > >> Requirement PB-4 > > >> > > >> If the posture broker needs to protect global assessment > > information > > >> (see comments on 5.2.2), then MAY is too weak. MUST or > > possibly MAY > > >> would be needed... > > >> > > > > > > > > > > > > You mean MUST or SHOULD. This was discussed at the Prague IETF=20 > > > meeting and moved from a SHOULD to a MAY. > > > > > > We certainly open this discussion within the WG. > > > > > > > > > > >=20 > > No need to reopen discussion on this item. MAY is=20 > consistent with the=20 > > rationale provided for my comment on 5.2.2. I am satisfied=20 > that the=20 > > WG has considered the issue. >=20 > [PS] Ok, their hasn't been strong support to move this back=20 > to SHOULD yet but if this occurs we could consider it. Note=20 > this is a requirement that applies to our protocol selection=20 > (the WG can still select a PB protocol that has strong=20 > security capabilities) even with a MAY in this requirement. >=20 > >=20 > > > > > >> 8.1.2 > > >> > > >> The last sentence in this section seems to establish a > > requirement > > >> for > > >> the NEA protocols. This material needs to be presented=20 > earlier and=20 > > >> represented as a section 7 requirement. > > >> > > >> Section 9.2, next to last paragraph: > > >> > > >> "For example, an enterprise might ask about the OS > > >> version in the initial message dialog and after learning the > > >> system is a Linux system, ask for a different/smaller set of > > >> attributes specific to Linux then it would if the > > endpoint was a > > >> Windows system. " > > >> > > >> This text answered a nagging question for me, when I > > encountered it. > > >> While I was glad to learn how the wg intended to address the OS=20 > > >> identification problem, page 48 was a little too late. =20 > I believe=20 > > >> the possibility of a bootstrapping ought to be addressed=20 > earlier,=20 > > >> and we should clearly state which component (PB Client or PC?)=20 > > >> resolves this type of question... > > > > > > > > > > > > > > > Would this be a requirement or update to the reference model to=20 > > > state that the OS discovery would be handled by the Posture=20 > > > Collector. I am not sure about the motivation to special=20 > case the OS=20 > > > type different > > from any > > > other > > > standard attribute. > > > > > > Regards, > > > kaushik > > > > > > > > > > >=20 > > Once again, I was unintentionally vague.... > >=20 > > Interrogating an endpoint with respect to its OS seems inconsistent=20 > > with the definitions of posture and posture attribute in 2., so I=20 > > couldn't figure out how the posture validator(s) knew which OS a=20 > > system ran. Without that knowledge, the posture validator(s) can't=20 > > know which attributes to request. > >=20 > > There are a couple of solutions: (1) request all possibly=20 > interesting=20 > > posture attributes for all recognized OSes, and sort out=20 > the results;=20 > > or (2) interrogate the endpoint and request teh attributes=20 > that make=20 > > sense. > >=20 > > From the text in the security considerations, I deduced that=20 > > discovery may be performed by requesting posture attributes that=20 > > describe the OS, etc. but that this step was omitted from=20 > the example=20 > > since multiple round trips complicate the base concepts. This also=20 > > implies the definitions of posture and posture attribute could be=20 > > expanded... > >=20 > > So, maybe it isn't a new requirement, its just an extra=20 > clause in the=20 > > definition of posture. >=20 > We could add a couple clauses in the examples to make it more=20 > clear that the OS version is treated like other component=20 > (e.g. firewall) versions on the endpoint. >=20 > >=20 > > Thanks again, > >=20 > > Tim Polk > >=20 > >=20 > >=20 > > _______________________________________________ > > Nea mailing list > > Nea@ietf.org > > https://www1.ietf.org/mailman/listinfo/nea > >=20 >=20 >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea >=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 Aug 14 20:53:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL78s-0004kF-Vq; Tue, 14 Aug 2007 20:53:46 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IL78r-0004dh-D4 for nea-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 20:53:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL78r-0004cG-2h for nea@ietf.org; Tue, 14 Aug 2007 20:53:45 -0400 Received: from elasmtp-masked.atl.sa.earthlink.net ([209.86.89.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IL78p-000597-MU for nea@ietf.org; Tue, 14 Aug 2007 20:53:45 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=hWqWO8a1S3ExR0ZxInhC3hwArUCVLwMjlqUhgZSDkWk5izU9DarsnWrfGb9kgPHh; 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 [24.23.176.93] (helo=tsg1) by elasmtp-masked.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IL78n-0004Rq-A4; Tue, 14 Aug 2007 20:53:41 -0400 Message-ID: <003101c7ded6$b91afdf0$6501a8c0@tsg1> From: "TS Glassey" To: "Alan DeKok" References: <46BF095D.9090305@deployingradius.com> <001601c7dcfe$03366990$6501a8c0@tsg1> <46BF3B85.3030208@deployingradius.com> <003401c7dd10$c3417290$6501a8c0@tsg1> <46BFB615.4090208@deployingradius.com> Subject: Re: [Nea] NEA requirements and internationalization Date: Tue, 14 Aug 2007 17:53:37 -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: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec799e6ded6271a713e9dd2ba1ba5ba08cee350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.23.176.93 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 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 Alan - pardon the tone of this. Nothing personal is meant by these responses but AHAHAHAHAHAHAHAHAHAHAh -I haven't laughed that hard in a while... Now that said - I am NOT against NEA just I want it to do more than what I already have implemented with DHCP and several other tools including Tripwire. Otherwise its doomed in my estimation. Todd ----- Original Message ----- From: "Alan DeKok" To: "TS Glassey" Cc: "Stephen Hanna" ; Sent: Sunday, August 12, 2007 6:38 PM Subject: Re: [Nea] NEA requirements and internationalization > TS Glassey wrote: >>> MAY, rather than MUST. Many sites will have a site-wide configuration >>> saying "language used by everyone here." >> >> So then you are suggesting that as part of the entitlement-enablement >> process that the client is interactively configured. > > MAY be interactively configured. Or, as many administrators do, th > process may be scripted. scripting opens the system to security issues. It also enables many types of script driven attacks too. > >> What I am saying is that based on new requirements from the Courts (as >> of May 4th 2007) in the US there are now five specific tests for ESI >> (Electronicially Stored Information) into the Court's as evidence, and >> what that means is that in any system that 'may produce content that may >> come to be reviewed as evidence' will need to meet these new >> requirements. >> >> What that means to us, is that if we are designing technologies to meet >> specific control requirements, there are now new constraints on those >> systems which would come to be used in officia capacities. > > NEA is working on protocol level requirements and design. Logging, > UI, and legal issues are (IMHO) out of scope. its a good thing its just an opinion... what I am talking about is what is required to place technologies into SOX and other regulated entities, and if the IETF doesnt want to deal with those then it should specifically say that in the scope statement to elminate the issues of legal compliance requirements. The problem is that most techies here have no idea what the law is doing to IT requirements and yet people continue to design technologies intentionally to fail to meet those requirements. The really funny thing to do is to listen to the IT Manager try and talk their way out of being dinged by the IT Auditor's for running unsecured and rediculously stupid code in their system, and as it happens I think that NEA is the next one of these winners to come out of the IETF. The issues are simple - and that is if there is a desire to install a system that can pre-qualify the security compliance and platform configuration compliance into the IT world then it needs to do so in concert with the Auditor's who will tell the IETF whether they are willing to put their names and professional reputation/credentials on the line by using this protocol as their recommendation. Otherwise why bother? > An NEA requirement that > systems MAY transport user-visible strings is fine. However, certain > implementations in certain jurisdictions MAY have additional > requirements on what is done with those strings. The EU Data Integrity "regulation" may not agree with you. > > If we design NEA for the lowest-common legal denominator, then we will > have a system that does nothing. No - but that is the typical claim from techies who dont know what they are designing to. The problem with NEA is that there are regulatory requirements for this type of thing and the NEA WG wants to build something else that doesnt address those but claims to apparently. > >> That said, since there are new 'requirements' in operating official >> systems, NEA should address those too... and that said, passing >> plain-text about is a no-no > > I'm a little at a loss to see how we can design an access protocol > that doesn't tell the user whether or not they've been granted access, > or even if they've been denied. Uh simple - the users NIC can easily be used to tell them all kinds of things including NO CONNECTION. > A list of canned status/error messages > isn't good enough, as experience has shown. > >>> I would like the ability for administrators to push messages to end >>> users via NEA. This involves the *capability* to transport >>> internationalized strings in NEA. However, those strings are >>> informative to the end user, and opaque to the rest of NEA. >> >> So do a table of messages based on the entitlement models supported and >> then publish UTF-8 strings of them in whatever language you want to >> support. > > Can we enumerate *enough* possible messages to be useful? I doubt it. Sure - a common set of messages is all that is necessary and simple UTF-8 Encoding to make those transportable. > >>> I can understand this on the wide open net. For the chartered purpose >>> (enterprises), I don't see why it's a problem. >> >> Integrity of the Audit Process running inside the "Entity". Think of >> your average University for instance. How many would-be hackers are >> inside the Entity then. > > Charter. We have it. We should focus on it. Universities are out of > scope. Issues with deploying NEA inside of Universities are out of > scope. If certain designs work in an enterprise, but not in a > university, then issues with the university deployment are irrelevant. > They are canards, and out of scope. Screw the Academic issues, as a professional auditor I believe that you nor no one else here will install NEA in its current form in any regulated networks period. I just wont fly with what you got now, whether you like that or not, and whether you believe it or not... > >>> [ re: informational messages ] >>> No. They can be thrown away. Many PPP implementations have done this >>> for years. It's annoying, but widely accepted practice. >> >> Depending what type of auditing and integrity of process model NEA is to >> support. > > I'm not really sure what you mean by that. Informational messages > are... informational. They have little definitive meaning. Uhh is NEA a tool for qualifying systems prior to accessing the entity resources? > > In contrast, messages like "you must upgrade now" are not > informational. They impose normative requirements on the user, and > should be logged, audited, etc. Agreed as should any status message from any transaction. > > Alan DeKok. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Aug 14 20:56: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 1IL7BW-0005rY-Sv; Tue, 14 Aug 2007 20:56:30 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IL7BV-0005rT-Q8 for nea-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 20:56:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL7BV-0005rL-Ga for nea@ietf.org; Tue, 14 Aug 2007 20:56:29 -0400 Received: from elasmtp-kukur.atl.sa.earthlink.net ([209.86.89.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IL7BU-0005B0-1L for nea@ietf.org; Tue, 14 Aug 2007 20:56:29 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=TFKZXo70t+HV4MpxplzOqZfGGfyfV7Lbqm2kgxjc+HXVuI6irFHZ7jYV9nCVecHR; h=Received:Message-ID:From:To: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 [24.23.176.93] (helo=tsg1) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IL7BN-0007Ue-UI; Tue, 14 Aug 2007 20:56:22 -0400 Message-ID: <003c01c7ded7$18d7a8b0$6501a8c0@tsg1> From: "TS Glassey" To: "Paul Sangster" , "Nancy Winget \(ncamwing\)" , References: <08A9A3213527A6428774900A80DBD8D804A1D8FF@xmb-sjc-222.amer.cisco.com> Subject: Re: [Nea] comments on draft-ietf-nea-requirements-03.txt Date: Tue, 14 Aug 2007 17:55:15 -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: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec790d4ba8704d867fcec80eb8ca0b155a92350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.23.176.93 X-Spam-Score: 0.0 (/) X-Scan-Signature: f1405b5eaa25d745f8c52e3273d3af78 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 Paul - a component summary at 50,000 feet would deal with this and allow for the noticing of that there were numerous Terms of Art in the draft/rfc Todd ----- Original Message ----- From: "Paul Sangster" To: "Nancy Winget (ncamwing)" ; Sent: Tuesday, August 14, 2007 5:41 PM Subject: RE: [Nea] comments on draft-ietf-nea-requirements-03.txt Thanks for the comments, some feedback is in-lined... > -----Original Message----- > From: Nancy Winget (ncamwing) [mailto:ncamwing@cisco.com] > Sent: Friday, August 10, 2007 8:30 PM > To: nea@ietf.org > Subject: [Nea] comments on draft-ietf-nea-requirements-03.txt > > In general the draft is a great improvement over the last > revision. I still have a few comments/questions: > > Section 2 > --------- > * while the PA, PB and PT are described in Section 5, it > would be good to give summary definitions to these here as > they are referenced This comment is similar to Tim's about using words (Posture Collector) the reader doesn't yet know in the terminology. We chose to define the reference model in section 5 while having most of the terms defined up front. We'll review the spec and see if we can figure out how to reduce the dependance on section 5 when reading section 2. One option is to move/copy the defs from section 5 into the terminology and massage section 5 to not repeat what has already been defined too much. > > Section 5 > ---------- > * The Posture Collector as described in 5.1.1.1 states: > " Receiving attributes containing remediation instructions on > how to update the component(s) on the endpoint. This could > require the collector to interact with the user, owner > and/or a remediation server." > which seems somewhat contradictory or needs further > elaboration when > relating to the statement in the Posture Broker Client > description of > 5.1.1.2: > " Providing user notification about the global assessment > decision and other user messages sent by the NEA Server." > If the PB is maintaining a more "global" state, this implies > that it may "reassess" and modify the "remediation" as > provided by the server. > Or what is meant by "global assessment" (as that result > could imply different actions versus the collection of > "individual assessments" > belonging to a particular Posture Collector. The component level (e.g. firewall) level assessments and remediation instructions would go to the firewall Posture Collector. The global assessment goes to the Posture Broker Client as it handles the overall decision. So maybe its confusing but both the Posture Collector and Posture Broker Client could receive attributes at the end of an assessment (e.g. the Collector on how to remediate its associated security mechanism and the Broker on the global assessment decision). To have an integrated user interface, the Posture Broker Client implementation may provide an interface to the Collectors for providing remediation instructions to the user (this is outside the scope of this doc as we're getting into implementation's detailed designs). We'll edit the paragraph about the Posture Broker Client (para 3) to help make this more clear. > > * 5.1.1.1 states "...offering cryptographic protection to the > attributes returned." > - protection from whom? Is it protecting it from the > layers within the NEA client (e.g. > Protected from the PB and PT) as it is provided by the PA? Yes its providing end to end security protections. This is more obviously needed when the Posture Validator is remote from the Posture Broker Server. This enables the Posture Validator to cryptographically authenticate the specific collector, check the integrity of the posture received, and protect the confidentiality of the posture sent (which might include PII or other information an attacker might use for vulnerability scanning/fingerprinting). We discussed this in Prague and in prior e-mail threads. Note that we downgraded the requirement for PB security to a MAY. > > * 5.1.1.3 what are the threat models addressed in "providing > cryptographic protection > for the message dialog between the NEA Client and NEA Server"? This is discussed in the security considerations section. The PT security protections against passive and active attacks again the server authentication, optional endpoint authentication, eavesdropping, integrity of the PT, PB and PA payloads, MITM, replay, etc. Note that its optional to deploy PT security although one might expect this would be common (much more so then PB security). > > * Figure 1 is somewhat confusing as the PA, PB and PT are > drawn across the client and server, but the descriptions > infer that the PA flow from PA to PB to PT and up back up on > the other end. These are encapsulating "protocols" (as per our charter terminology). They are shown as horizonal protocol flows because those are the entities that see the data exchanged. > While it is understood that the communication "targets" are > across, the security implications and considerations must > take into account the threats that may occur while the > information is flowing through the different nodes. For > instance, there may be multiple nodes supporting the "NEA > Server" and thus the transport between the Posture Validators > and Posture Broker (and Posture Transport Server[s]) must > also be described in the security considerations. Correct we do discuss this in security considerations section (search for "remote", see section 8.1.3, section 8.2, 8.3.2 ...) This is the reason for PA security protections to be required. With that said I believe its out of scope for the Posture Transport Client, Posture Broker Client and Posture Collectors to be on different nodes. Similarly its out of scope for the Posture Transport Server and Posture Broker Server to be on different nodes. So we're just including the one case which you mentioned. > > * 5.1.2.1 (Posture Validator) > "Requesting attributes froma Posture Collector".....does > this mean that the > Posture Collector is uniquely identified within an NEA > client? Or does the client > determine which PC to route the request to? (this text > infers the former, but > given the "global assessment" of the Posture Broker, it's not clear. We don't specify a particular PC/PV identification scheme but mention 3 possible approaches (section 5.1.1.1 P2 and 5.1.2.1 P2) that the PB protocol candidates will need to specify how their approach works. Of course we require in PB-2 that the PB protocol can carry these identifiers. > > > Section 7 > ---------- > > * C-2: a nit, by "after the endpoint has gained normal > network"......the intent is really > "during the endpoint's session in the network"? We've reworded C-2 in the next I-D so these words are removed. The new C-2 (merged with the old C-3) says: "C-2 NEA protocols SHOULD provide a way for both the NEA Client and the NEA Server to initiate a posture assessment or reassessment as needed." > > * C-4: who are the intermediaries? Since there are multiple > Posture Collectors, Validators, Transports, there needs to be > clarification on the message flow as the flow say, between a > particular Posture Validator to Broker to Transport server > are authorized. Intermediaries are discussed in section 8.1.2. I believe this requirement is oriented towards network-based intermediaries and not hostile components on the endpoint. Hostile components on the endpoint are out of scope for NEA (see section 8.1.1). We could edit it to say "... attacks by network-based intermediaries and other endpoints ..." if that makes it more clear? > > * C-7, C-9: it would be good to quantify the "scale" and a > reasonably expected number of NEA clients and Posture > Validators. Is the scale on the order of 100's, 1000's, 10K? Suggestions on how to come up with an appropriate number that will work for a very wide variety of potential deployments? Text suggestions are welcome. We struggled with this issue as well and ultimately will probably be part of the PB protocol submission. For example, if the PB protocol candidate assigns static UUIDs to each PC and PV then the namespace needs to be very large. If the PC and PV naming is dynamically generated based on a per NEA Client basis then the number can be *much* smaller (much higher then the largest number of PCs we expect will ever be on a single node). If the naming is based on message content information (used in the subscription model) then a large number is somewhere in between. Our thinking was for the WG to apply judgement when evaluation candidate protocols. > > * In Section 7.2, there are many requirements for enabling > the Posture Validator. Shouldn't there be allowance for the > Posture attributes to be sent unsolicited from the Posture > Collector to the Validators as well? Not sure I follow, but we do allow for the Posture Collector to proactively send Posture Attributes without the Posture Validator requesting them. For example, this could be by having pre-configured client policy stating which attributes to send during a network connection attempt to a particular NEA Server (this one is discussed in a couple places in the spec including section 5.1.1.2 P1 and 9.2 P1-3. > > * PA-6: clarification is needed on the "end-to-end" security > across an NEA deployment. The model in Figure 1 abstracts > the layers as there may be different deployments, and how the > protection is carried out can be dependent on the > instatiation of the model. It is not clear why the > protection needs to be a hard requirement vs. a "MAY" at this layer. See feedback above and to Joe Salowey's comments about this topic. Your comment above highlighted why this was needed (Posture Validator on different node from Posture Broker Server). > > * PA-7: I can see this being true for the server side, but > why is this required on the client? Encrypted attributes and other binary data could be sent by the client and encrypted remediation instructions and other binary data could be sent by the server. The PA protocol needs to allow such data to be transported. > > * PB-4: "The PB protocol MAY support authentication, integrity and > confidentiality protection for the attribute messages it > carries between an NEA Client and Server. " What > is meant by > "NEA Client and Server", is the intent to protect a > layer of protection > between the brokers? Yes we could be more specific here. Will change to "Posture Broker Client and Posture Broker Server". > > * PT-6: "The PT protocol MUST be capable of supporting mutual > authentication between the Posture Transport Client > and the > Posture Transport Server. This MAY occur by leveraging by- > products (e.g., keys) supplied by the PB protocol > authentication." > I don't see how the PB protocol helps here? This text was changed based on other comments but the example was thinking about cryptographic bindings for EAP tunnels or potentially channel bindings in other environments. > > > Section 8.1: > - Components can really mean components within an NEA > Client or Server and > the "general" network components as well. It is unclear in either > 8.1 and > 8.1.1 what components are being referred to. It would be Same comments as above in this e-mail about trust boundaries. Also we hope to improve the terminology around components so NEA components are easier to identify vs. other software components (e.g. firewall) on the endpoint which might move to a different term. With that said intermediaries on the network are not referred to as components in this spec. Currently, components specifically part of the NEA reference model are described as "NEA [optional qualifier] component" or something similar ("components in the NEA system") to help with readibility. Section 8.1's components are about the components within the NEA reference model. > better to separate > the threat models within the "NEA component" and between > an "NEA Client" and > "NEA Server" and the rest of the network components (that > are not NEA participants). The trust model discussions are organized this way. Because of our trust model for the NEA client and server components, the threats primarily are those posed from the network to the network protocols not intra-NEA client or intra-NEA server except for the remote Posture Validator case. So section 8.3.x is organized by network born attacks which seems desired from my read of RFC 3552. If you have some specific changes that would help improve the section, we're happy to consider them. > > > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea > _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Aug 14 22:39: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 1IL8ms-0005MV-Ce; Tue, 14 Aug 2007 22:39:10 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IL8mq-0005LB-Q1 for nea-confirm+ok@megatron.ietf.org; Tue, 14 Aug 2007 22:39:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IL8mq-0005L3-6n for nea@ietf.org; Tue, 14 Aug 2007 22:39:08 -0400 Received: from www.deployingradius.com ([216.240.42.17] helo=deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IL8mo-0006ju-Az for nea@ietf.org; Tue, 14 Aug 2007 22:39:08 -0400 Received: from [142.131.76.184] (unknown [142.131.76.184]) by deployingradius.com (Postfix) with ESMTP id 4088EA7161; Tue, 14 Aug 2007 19:38:58 -0700 (PDT) Message-ID: <46C26741.3070400@deployingradius.com> Date: Tue, 14 Aug 2007 22:38:57 -0400 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: TS Glassey Subject: Re: [Nea] NEA requirements and internationalization References: <46BF095D.9090305@deployingradius.com> <001601c7dcfe$03366990$6501a8c0@tsg1> <46BF3B85.3030208@deployingradius.com> <003401c7dd10$c3417290$6501a8c0@tsg1> <46BFB615.4090208@deployingradius.com> <003101c7ded6$b91afdf0$6501a8c0@tsg1> In-Reply-To: <003101c7ded6$b91afdf0$6501a8c0@tsg1> 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: 6e922792024732fb1bb6f346e63517e4 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 TS Glassey wrote: > Alan - pardon the tone of this. Nothing personal is meant by these > responses but AHAHAHAHAHAHAHAHAHAHAh -I haven't laughed that hard in a > while... It's nice to know that my attempts at achieving consensus cause such good feelings. > scripting opens the system to security issues. It also enables many > types of script driven attacks too. From who? Unless I'm mistaken, NEA is about giving known and trusted administrators the ability to require the end host to download something called "software updates". If you're worried about script attacks from people within a circle of trust, I suggest you give up on NEA entirely. > The problem is that most techies here have no idea what the law is doing > to IT requirements and yet people continue to design technologies > intentionally to fail to meet those requirements. That statement is rather a lot stronger than what I said. Please explain how we can design NEA to fulfill all legal requirements in all jurisdictions. If we can't do that, then we should give up on NEA now. Or, we should pick a jurisdiction that is understood, and design NEA to work only there. Since NEA has been chartered, the first option is off of the table. Since the IETF is an international group, the second option is off of the table. Please come up with constructive suggestions as to *how* something positive can be done. All you've done so far is to state absolute requirements. >> An NEA requirement that >> systems MAY transport user-visible strings is fine. However, certain >> implementations in certain jurisdictions MAY have additional >> requirements on what is done with those strings. > > The EU Data Integrity "regulation" may not agree with you. The EU Data Integrity "regulation" specifies that user-visible strings MAY NOT be transported? Or maybe you mean that the EU Data Integrity "regulation" MAY NOT have any requirements on what is done with user-visible strings? I'm trying to figure out how your statement bears any relation to what I said. I'm failing. >> If we design NEA for the lowest-common legal denominator, then we will >> have a system that does nothing. > > No - but that is the typical claim from techies who dont know what they > are designing to. Design to meet Iran's requirements. Don't know them? I'll mock you mercilessly, and ridicule your position on the list. Ah, the refreshing breeze of open communication. > The problem with NEA is that there are regulatory > requirements for this type of thing and the NEA WG wants to build > something else that doesnt address those but claims to apparently. I don't think we're reading the same list. > Uh simple - the users NIC can easily be used to tell them all kinds of > things including NO CONNECTION. > >> A list of canned status/error messages >> isn't good enough, as experience has shown. Yup. >> Can we enumerate *enough* possible messages to be useful? I doubt it. > > Sure - a common set of messages is all that is necessary and simple > UTF-8 Encoding to make those transportable. If there is a common set of messages that can be defined, then simple integer status codes will suffice. If a common set of messages can't be defined, then user-visible strings are required. See above for my opinion on the topic. >> Charter. We have it. We should focus on it. Universities are out of >> scope. Issues with deploying NEA inside of Universities are out of >> scope. If certain designs work in an enterprise, but not in a >> university, then issues with the university deployment are irrelevant. >> They are canards, and out of scope. > > Screw the Academic issues, as a professional auditor I believe that you > nor no one else here will install NEA in its current form in any > regulated networks period. I just wont fly with what you got now, > whether you like that or not, and whether you believe it or not... So you disagree with the charter. Why are you still here? Alan DeKok. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Aug 15 11:56:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILLEV-0000zL-Dl; Wed, 15 Aug 2007 11:56:31 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1ILLEU-0000zF-DY for nea-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 11:56:30 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILLEU-0000xW-05 for nea@ietf.org; Wed, 15 Aug 2007 11:56:30 -0400 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILLES-0007dD-VG for nea@ietf.org; Wed, 15 Aug 2007 11:56:29 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=omM04pUdm1zLDd7XhWEggshdDltvAVRPYiTsJZkl9WOy+qHxXHkjaFq+FuqX4agJ; 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-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1ILLER-0002JW-3Y; Wed, 15 Aug 2007 11:56:27 -0400 Message-ID: <009801c7df54$d7655de0$174f7d40@home.glassey.com> From: "todd glassey" To: "Alan DeKok" References: <46BF095D.9090305@deployingradius.com> <001601c7dcfe$03366990$6501a8c0@tsg1> <46BF3B85.3030208@deployingradius.com> <003401c7dd10$c3417290$6501a8c0@tsg1> <46BFB615.4090208@deployingradius.com> <003101c7ded6$b91afdf0$6501a8c0@tsg1> <46C26741.3070400@deployingradius.com> Subject: Re: [Nea] NEA requirements and internationalization Date: Wed, 15 Aug 2007 08:56:19 -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: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec799d9e4cb5c9d57516798a5a7413ec197f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.125.79.23 X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org ----- Original Message ----- From: "Alan DeKok" To: "TS Glassey" Cc: "Stephen Hanna" ; Sent: Tuesday, August 14, 2007 7:38 PM Subject: Re: [Nea] NEA requirements and internationalization > TS Glassey wrote: >> Alan - pardon the tone of this. Nothing personal is meant by these >> responses but AHAHAHAHAHAHAHAHAHAHAh -I haven't laughed that hard in a >> while... > > It's nice to know that my attempts at achieving consensus cause such > good feelings. :-) > >> scripting opens the system to security issues. It also enables many >> types of script driven attacks too. MITM attacks are what I am worried about - and anything that happens from a configuration control aspect inside of controled networks needs to be both secured/authenticated and fully logged on an end-to-end basis. > > From who? Unless I'm mistaken, NEA is about giving known and trusted > administrators the ability to require the end host to download something > called "software updates". > > If you're worried about script attacks from people within a circle of > trust, I suggest you give up on NEA entirely. Do you know about the separation of Roles and Responsibilities within the existing Audit Models. NEA Administrator's are likely NOT to be user administrator's except in smaller entities. So it is appropriate that only some of the admins in any entity have access to NEA facilities. > >> The problem is that most techies here have no idea what the law is doing >> to IT requirements and yet people continue to design technologies >> intentionally to fail to meet those requirements. > > That statement is rather a lot stronger than what I said. It is, and I apologize for offending anyone with a sensitive ego, but the reality is what it is. Let me ask - Why do you think that these Federal Entitie's which are being publicly spanked for IT Failings are failing??? Is it the Government itself? I dont think so - its because those administrator's, who were trained by those folks out of the 70'sthrough 90's IT world's are assuring everyone that their systems are 'solid', and as it happens they are not. This ISNT and WASNT my doing... I am just noticing that those people failing the current operations requirements are the same people who before SOX and the FISCAM requirements were signing documents saying that they assured the management that their sites were secure. These failings didnt happen overnight, they were always there. Hell - I was attacking systems for one of the clients I worked for with Buffer-Overflows in 1998. Their client's included the US Navy and other financial entities so this is not new stuff or rocket science. That said - YES I am slamming those admins and most of those outside the Government too for just not understanding what is necessary to run a secured and audited shop, and (here comes the rub) for assuring the world that they did. > > Please explain how we can design NEA to fulfill all legal requirements > in all jurisdictions. If we can't do that, then we should give up on > NEA now. Or, we should pick a jurisdiction that is understood, and > design NEA to work only there. Simple - For SOX Compliance create a set of COBIT practice control models that rely on NEA and draft a procedure for installing and managing a new platform or ongoing status-compliance therein. The same is true for HIPAA Compliance in Medical Processes. > > Since NEA has been chartered, the first option is off of the table. > Since the IETF is an international group, the second option is off of > the table. > > Please come up with constructive suggestions as to *how* something > positive can be done. All you've done so far is to state absolute > requirements. Lets document the use then of that COBIT compliance model - I will draft a NEA use document that addresses these control issues and file it as an I-D. The IETF can then formally inform ISACA that it has a COBIT practice model available for use by ISACA professionals and others for using NEA as a part of a COBIT compliance model. > >>> An NEA requirement that >>> systems MAY transport user-visible strings is fine. However, certain >>> implementations in certain jurisdictions MAY have additional >>> requirements on what is done with those strings. >> >> The EU Data Integrity "regulation" may not agree with you. > > The EU Data Integrity "regulation" specifies that user-visible strings > MAY NOT be transported? Or maybe you mean that the EU Data Integrity > "regulation" MAY NOT have any requirements on what is done with > user-visible strings? Both depending on what messages are sent. That is why its important to pre-define the messages and their respons processes. > > I'm trying to figure out how your statement bears any relation to what > I said. I'm failing. > >>> If we design NEA for the lowest-common legal denominator, then we will >>> have a system that does nothing. >> >> No - but that is the typical claim from techies who dont know what they >> are designing to. > > Design to meet Iran's requirements. Don't know them? I'll mock you > mercilessly, and ridicule your position on the list. What I am saying is that designing for the purpose of desing itself is Art. Desinging for some specific purpose is what we are about here I thought, so lets define the uses of NEA and then meet those needs with technologies specific to those requirements. > > Ah, the refreshing breeze of open communication. :-) > >> The problem with NEA is that there are regulatory >> requirements for this type of thing and the NEA WG wants to build >> something else that doesnt address those but claims to apparently. > > I don't think we're reading the same list. > >> Uh simple - the users NIC can easily be used to tell them all kinds of >> things including NO CONNECTION. >> >>> A list of canned status/error messages >>> isn't good enough, as experience has shown. > > Yup. > >>> Can we enumerate *enough* possible messages to be useful? I doubt it. >> >> Sure - a common set of messages is all that is necessary and simple >> UTF-8 Encoding to make those transportable. > > If there is a common set of messages that can be defined, then simple > integer status codes will suffice. If a common set of messages can't be > defined, then user-visible strings are required. See above for my > opinion on the topic. > >>> Charter. We have it. We should focus on it. Universities are out of >>> scope. Issues with deploying NEA inside of Universities are out of >>> scope. If certain designs work in an enterprise, but not in a >>> university, then issues with the university deployment are irrelevant. >>> They are canards, and out of scope. >> >> Screw the Academic issues, as a professional auditor I believe that you >> nor no one else here will install NEA in its current form in any >> regulated networks period. I just wont fly with what you got now, >> whether you like that or not, and whether you believe it or not... > > So you disagree with the charter. Why are you still here? No I dont disagree with the Charter, I just think its too narrow to meet any specific end-use. > > Alan DeKok. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Aug 15 13:36:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILMmw-0007TG-S5; Wed, 15 Aug 2007 13:36:10 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1ILMmv-0007T6-4L for nea-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 13:36:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILMmu-0007Sy-R2 for nea@ietf.org; Wed, 15 Aug 2007 13:36:08 -0400 Received: from umhost1.ukerna.ac.uk ([193.62.83.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILMmt-0003lz-Eh for nea@ietf.org; Wed, 15 Aug 2007 13:36:08 -0400 Received: from uxsrvr20.ukerna.ac.uk ([193.62.83.209] helo=uxsrvr20.atlas.ukerna.ac.uk) by umhost1.ukerna.ac.uk with esmtp (Exim 4.50) id 1ILMms-0005y9-1Q; Wed, 15 Aug 2007 18:36:06 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] NEA requirements and internationalization Date: Wed, 15 Aug 2007 18:37:07 +0100 Message-ID: <6ED388AA006C454BA35B0098396B9BFB028F4AC7@uxsrvr20.atlas.ukerna.ac.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] NEA requirements and internationalization Thread-Index: AcffVQf4cTPx7sDDQeWBh/glzjxHRQACoB4g From: "Josh Howlett" To: "todd glassey" X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Josh Howlett , 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 todd glassey wrote: > No I dont disagree with the Charter, I just think its too=20 > narrow to meet any specific end-use. If I understand your argument correctly, you believe that NEA MUST facilitate adherence to certain statutory instruments, and that this constitutes the only valid end-use of NEA. Can you enumerate these? josh. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Aug 15 15:32:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILOb4-00011k-K6; Wed, 15 Aug 2007 15:32:02 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1ILOb3-00011c-DY for nea-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 15:32:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILOb3-00011U-3w for nea@ietf.org; Wed, 15 Aug 2007 15:32:01 -0400 Received: from smtpb.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILOb1-0006rp-N5 for nea@ietf.org; Wed, 15 Aug 2007 15:32:01 -0400 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by smtpb.juniper.net with ESMTP; 15 Aug 2007 12:31:58 -0700 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Aug 2007 15:31:39 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Posted draft minutes from IETF 69 NEA meeting Thread-Index: AcffcubxOuUOo9qgQLyQhM2m2e6H7A== From: "Stephen Hanna" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: b84f8c8fba0e1389e5eb998b64078964 Subject: [Nea] Posted draft minutes from IETF 69 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 draft minutes from the IETF 69 NEA WG meeting on the IETF 69 meeting materials web site. For your convenience, I have also copied them below. Please review these minutes. If you find any errors or omissions, please send email to the list. The deadline for correcting these minutes is September 12 so please send corrections to the list by end of day on September 11 so I have time to make the corrections. Thanks, Steve ----------- Minutes from NEA WG Meeting IETF 69 in Chicago, IL July 23, 2007, 1:00 PM - 3:00 PM Chaired by Steve Hanna and Susan Thomson Notes taken by Mani Mahalingam and Joe Tardo These notes do not attempt to duplicate all the material in the slides. Instead, they provide a brief summary of that material and focus on comments and discussion (especially consensus checks). Steve and Susan called the meeting to order at 1:04 PM and reviewed logistical information about the group (email list, chairs, etc.). Blue sheets were distributed and minutes scribes found. No Jabber scribes were found. The following draft agenda was agreed to: 1:00 Administrivia Blue Sheets Jabber & Minutes Scribes Agenda Bashing 1:05 WG Status 1:10 Discuss NEA Requirements Draft http://www.ietf.org/internet-drafts/draft-ietf-nea-requirements-03.txt 2:55 Review of Next Steps 3:00 Adjourn *WG Status* Steve reviewed the current status of the Working Group. Our requirements document is in Working Group Last Call. Please review it and sent comments to the list. Steve asked for a show of hands from those who have read some version of the requirements document and another show of hands from those who have read the latest version (-03). A good number of people raised their hands for both. Steve explained that our next steps are: * Finish WGLC on NEA Requirements I-D * Revise NEA Requirements I-D * Another WGLC if major changes made * Submit NEA Reqs I-D to IESG for IETF LC and approval as Informational RFC * Revise milestones to start work on PA & PB Tim Polk (our AD) agreed. Paul Hoffman: When will the rechartering start? Tim Polk: We should start work on that when IETF LC completes so that it can be approved when or shortly after the time when the IESG approves the requirements document. Steve Hanna: I hope we'll only need to change milestones not do a real rechartering. Tim Polk: If that's true, it will be easy. Hannes Tschofenig: The mailing list has been quiet, which means the document has not received much review. You need more review, especially since this document has more than just requirements. Tim Polk: Agreed. I'm going to recruit more reviewers. We were waiting until the document was solid. Steve Hanna: Could I see a show of hands from people who are willing to review the document? Got seven volunteers. Hannes: Write down people's names so you can bug them! Here are the names of the volunteers: Hao Zhou, Nancy Winget, Alan Breese, Alan DeKok, Joe Salowey, Mauricio Sanchez, and Hannes Tschofenig. Steve reviewed the NEA Reference Model and reminded people of the WG's scope: endpoint assessment and in particular agreeing on standard PA, PB, and PT protocols. *NEA Requirements* Kaushik Narayan started reviewing the latest NEA requirements document. He reviewed the changes made in the -02 and -03 drafts. See his slides for details. Kaushik raised some issues for discussion. 1) The current draft contains informative text that touches upon a few aspects of protocol design at a high level to provide guidance but does not impose requirements. Should this text be retained? Paul Hoffman: It's good to have this text as long as you make it VERY clear that this text is informative. Kaushik Narayan: We've tried to do that. Steve Hanna: Is it true that the only normative text is in the Requirements section? Kaushik Narayan: Yes. Steve Hanna: Maybe we should say that somewhere. Paul Sangster: We do. Susan Thomson: We must make sure this is clear and not confusing. Steve Hanna: Maybe we should place at the beginning of each section a reminder that all normative text is in the Requirements section. Susan Thomson: We should also avoid having too much informative text. Paul Sangster: I think we should just change the title for the Requirements section to say "ONLY NORMATIVE TEXT". Steve Hanna: That wouldn't address my concern sufficiently. Kaushik Narayan: Let's take this to the list. 2) Requirement PB-3 seems redundant in light of requirement C-1. In fact, the requirement for supporting multiple messages can be met by the PT layer or the PB layer so this requirement is going into protocol design. Should we remove requirement PB-3? There were no comments on this topic at the meeting. Kaushik Narayan: The Design Team has decided we'd like to remove requirement PB-3. If there are no other comments, we'll do so. 3) The Privacy Considerations section includes implementation guidelines. We haven't received much input on this section. Is it adequate? Too much? Not enough? Needs to be changed? Mauricio Sanchez: I think the document is going in the right direction and has the right level of detail. Steve Hanna: Are there privacy experts we should consult? Tim Polk: I'll look into that. Kaushik Narayan: And we'll take this to the list. Kaushik Narayan: OK. That's the last of the open issues we wanted to discuss today. But we thought it would be productive to review every one of the requirements in the draft now and see if anyone has any concerns or issues with them. Kaushik ran through the requirements, starting with C-1. The text here is taken from Kaushik's slides. C-1 Capable of multi-message dialog Hao Zhou: You mean multiple round trips? Kaushik Narayan: That's right. This is clear in the actual requirement text. I'm sorry the summary on the slide is ambiguous. C-2 Allow assessment prior and after normal network access C-3 Enable re-assessment by either client or server Paul Hoffman: What's the difference between C-2 and C-3? Kaushik Narayan: C-3 is about triggering. It's saying that either the client or server should be able to trigger a reassessment. Alan Breese: So C-2 is about initial assessment and C-3 is about reassessment? Kaushik Narayan: Actually, C-2 includes both initial assessment and reassessment. C-3 says either party can trigger reassessment. C-4 Protection against active/passive attacks by intermediaries C-5 PA and PB transport agnostic interfaces C-6 Selection process prefer reuse of existing open standards C-7 Scalable (many collectors and validators on multiple servers) C-8 Efficient transport of many Attributes C-9 Large numbers of compliance policies C-10 Allow for Assessment with reduced amount of information exchanged Alan DeKok: For C-8, if the server caches the results of previous assessments, later assessments can be quick since they can just send what has changed. For C-9, I'm not sure there's any way around that. If you don't comply, you may need to download a lot of data to come into compliance. Kaushik Narayan: For C-9, we'd just be looking for ways to make the data transmitted for assessment as small as possible. Alan DeKok: The only way we know to express complex policies is running code. So I'm not sure I agree with C-9. You can push down the policies during remediation along with patches, not during assessment. Then assessment will be much faster. Kaushik Narayan: We removed the idea of policy attributes so policies will no longer be pushed down during assessment. PA-1 Support transport standard Attributes PA-2 Support transport of vendor-specific Attributes PA-3 Enable validator to request Posture and Assertion Attributes from client's Collector PA-4 Allow for multiple requests for posture information within a single assessment. PA-5 Carry validator results and remediation instructions PA-6 Capable of authentication, integrity and confidentiality of Attributes PA-7 Capable of carrying Attributes including binary data PA-8 String Attributes being encoded with an encoding standard that supports internationalization.=20 PB-1 Capable of carrying the decision and (if present) remediation instructions PB-2 Carry naming for collectors and validators (used for message delivery). Naming should allow for dynamic registration. PB-3 MAY be capable of authentication, integrity and confidentiality of messages, decision and remediation instructions PB-4 Support grouping of attributes to optimize messages per roundtrip PT-1 SHOULD incur low overhead for low bandwidth links PT-2 SHOULD be capable of using a half duplex link PT-3 MUST NOT interpret the contents of PB messages PT-4 Capable of protecting the integrity and confidentiality of the PB messages PT-5 Reliable delivery of PB messages (detect dups, fragmentation) PT-6 Capable of mutual authentication (possibly leveraging an authentication inside the protected tunnel.) An open mike session was next. Alan DeKok: Overall, much clearer than the previous versions. I'd still like to emphasize clarity and simplicity. I have sent some comments to the list and will send some more. In Section 5, every other word is "posture". At that point, it doesn't mean anything. Just take it out. There were no other comments. Steve Hanna: Please review the current draft, which is draft-ietf-nea-requirements-03.txt. It's in WGLC, which closes August 10. Send comments on the document to the list. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Aug 15 16:11: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 1ILPDb-0002m9-F0; Wed, 15 Aug 2007 16:11:51 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1ILPDZ-0002m2-Om for nea-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 16:11:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILPDZ-0002lu-DJ for nea@ietf.org; Wed, 15 Aug 2007 16:11:49 -0400 Received: from www.deployingradius.com ([216.240.42.17] helo=deployingradius.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILPDY-0006vi-UM for nea@ietf.org; Wed, 15 Aug 2007 16:11:49 -0400 Received: from [192.168.1.102] (ottawa-hs-206-191-39-219.d-ip.magma.ca [206.191.39.219]) by deployingradius.com (Postfix) with ESMTP id 79664A7161; Wed, 15 Aug 2007 13:11:41 -0700 (PDT) Message-ID: <46C35DF8.6020304@deployingradius.com> Date: Wed, 15 Aug 2007 16:11:36 -0400 From: Alan DeKok User-Agent: Thunderbird 1.5.0.12 (X11/20070604) MIME-Version: 1.0 To: todd glassey Subject: Re: [Nea] NEA requirements and internationalization References: <46BF095D.9090305@deployingradius.com> <001601c7dcfe$03366990$6501a8c0@tsg1> <46BF3B85.3030208@deployingradius.com> <003401c7dd10$c3417290$6501a8c0@tsg1> <46BFB615.4090208@deployingradius.com> <003101c7ded6$b91afdf0$6501a8c0@tsg1> <46C26741.3070400@deployingradius.com> <009801c7df54$d7655de0$174f7d40@home.glassey.com> In-Reply-To: <009801c7df54$d7655de0$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: 08e48e05374109708c00c6208b534009 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org todd glassey wrote: > No I dont disagree with the Charter, I just think its too narrow to meet > any specific end-use. I guess there isn't much point in continuing. I'm trying to be productive, and you're not. Alan DeKok. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Aug 15 16:27:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILPSO-0001g0-0t; Wed, 15 Aug 2007 16:27:08 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1ILPSL-0001ft-Sp for nea-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 16:27:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILPSL-0001fl-Gy for nea@ietf.org; Wed, 15 Aug 2007 16:27:05 -0400 Received: from elasmtp-banded.atl.sa.earthlink.net ([209.86.89.70]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILPSJ-0007rE-Nj for nea@ietf.org; Wed, 15 Aug 2007 16:27:05 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=GTbaSVNSTNRv/RqxYbgiR4p3ZG6ttXRF6aDKgTwQnotEYTuqJaU7IZdkF00hp9rN; h=Received:Message-ID:From:To: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-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1ILPSF-0006VE-0A; Wed, 15 Aug 2007 16:26:59 -0400 Message-ID: <004301c7df7a$a2922780$174f7d40@home.glassey.com> From: "todd glassey" To: "Stephen Hanna" , References: Subject: Re: [Nea] Posted draft minutes from IETF 69 NEA meeting Date: Wed, 15 Aug 2007 13:26:50 -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: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79833d52d26c886565db0cab0963611c09350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.125.79.23 X-Spam-Score: 0.0 (/) X-Scan-Signature: 75ac86d24bd0a3cd8a26e327ae61143e 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 on the NEA Requirements Draft: 1) in the opening paragraph, NEA is more a tool for 'remote management of networks and their infrastructure' than a VPN tool. I think the line in the opening paragraph which reads: (e.g. an enterprise offering remote access) should be changed to notice that the intent behind NEA is not a VPN enablement, but a remote hands-off management tool for system. 2) in the SCOPE segment - these two changes to the scope statement are to be cleaner. a) PA and PB will be designed to be carried over a variety of lower layer transport (PT) protocols. Should read something like: NEA components are designed to be transport layer independant (TLI), and so they will work with a number of different transport layers. b) protocols are intended to allow interoperability between an NEA Client from one vendor and an NEA Server from another. Should read something like: protocols implemeted on standardized network transports like IP are intended to allow complete interoperability between NEA components from different vendors or sources. c) What I am also concerned for is that without the ability to detect lying endpoints that there is no real security available here. That said I strongly suggest that this requirement be added back into scope and if not considered in the first round only deferred to the second round. Its important... 3) In section 3.2 Conversely, some environments where NEA is not expected to be applicable would be environments where the endpoint is owned by a user that has not agreed to conform to a network provider's policies. An example might include when the above contractor visits any public area like the local coffee shop which offers Internet access. This coffee shop would not be expected to be able to use NEA technologies to assess the posture of the contractor's laptop. Because of the potentially invasive nature of NEA technology, such an assessment could amount to an invasion of privacy of the contractor. The problem is that NEA could easily become a valuable system for places that operate Hidden Gardens and the like as controlled Internet Hotspots. For instance the Denny's across the street from a client's place in Sunnyvale has a new 'access enablement webpage and agreement process' that has to be setup for their proxy to work. NEA would be a tremendously valuable tool to have to allow those proxies to be able to check the local mobile computing nodes for proper configuration of their firewall's for instance, or their patches. The value here is as a tool to limit liability from collateral damages based on some twirp hacking your laptop while your sitting in Denny's per se. That said I think that NEA is exactly what those coffee shops need in the form of an embedded NEA server built into the WAP itself. 4) Section 4 ... NEA technology may be used for several purposes. One use is to facilitate endpoint compliance checking against an organization's security policy when an endpoint connects to the network. Organizations often require endpoints to run an IT- specified OS configuration and have certain security applications enabled, e.g. anti-virus software, host intrusion detection/prevention systems, personal firewalls, and patch management software. An endpoint that is not compliant with IT policy may be vulnerable to a number of known threats that might exist on the network. One of the big problems network operators have is with rogue systems which are placed on a network by individuals who are running them in modes not compliant to the network's operatio's policy. That has any number of meanings including that the system is infested with something, mis-configured, or is mascarading as something it isnt. Also there are those instances where NON-NEA devices or systems may be placed on a network and that also must be dealt with. snip Re-assessment is an important part of NEA technology as it allows for additional assessments of previously considered compliant endpoints to be performed. This might become necessary because network compliance policies and/or endpoint posture can change over time. or that the systems configuration of those nodes under NEA management could also change or be changed by patches, human error, hacking, or other attack processes. A system initially assessed as being compliant when it joined the network may no longer be in compliance after changes occur. You mean Periodic Recertification... the process of running the NEA "Client/Node Admittance" (CNA)certification process continuously or on a periodic basis. For example, re-assessment might be necessary if a user disables a security protection (e.g. host firewall) required by policy or when the firewall becomes non-compliant after a firewall patch is issued and network policy is changed to require the patch. This also feeds back into the idea that NEA is supposed to continuously tell us that all the systems connected to the entity's networks are configured properly and are not running evil things. So... say that. SNIP 5) The Refernece Model (5.0) ... The NEA Reference model does not include mechanisms for discovery of NEA Clients and NEA Servers. It is expected that NEA Clients and NEA Servers are configured with information that allows them to reach each other. The specific methods of referencing the configuration and establishing the communication channel are out of scope for the NEA Reference Model and should be covered in the specifications of candidate protocols for the Posture Transport (PT) protocol. OK so can we change this to say "does not at this time include mechanisms for discovery" so we dont eliminate that as as feature. Its a powerful one. And can I ask... Isnt the Posture Transport Client really a reconfigurable NEA proxy? If so can we call it that? 6) 5.1.1 The NEA Client is responsible for responding to requests for attributes describing the configuration of the local operating domain of the client and handling the assessment results including potential remediation instructions for how to conform to policy. 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. For example a NAT device might route communications for many systems behind it, but when the NAT device is joining the network its NEA Client would only report its own (local) posture. Similarly, endpoints with virtualization capabilities might have multiple independent domains of execution (e.g. OS instances). Should read: The NEA Client is responsible for responding to requests for attributes describing the configuration of the local operating domain of the client and handling the assessment results including potential remediation instructions for how to conform to policy. 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. For example a NAT device might route communications for many systems behind it, but when the NAT device is joining the network its NEA Client would only report its own (local) posture. Similarly, endpoints with virtualization capabilities might have multiple independent domains of execution (e.g. OS instances). blah blah blah... - I will go through sections 5 and 6 later tonight and send them in too.. Todd ----- Original Message ----- From: "Stephen Hanna" To: Sent: Wednesday, August 15, 2007 12:31 PM Subject: [Nea] Posted draft minutes from IETF 69 NEA meeting I have posted draft minutes from the IETF 69 NEA WG meeting on the IETF 69 meeting materials web site. For your convenience, I have also copied them below. Please review these minutes. If you find any errors or omissions, please send email to the list. The deadline for correcting these minutes is September 12 so please send corrections to the list by end of day on September 11 so I have time to make the corrections. Thanks, Steve ----------- Minutes from NEA WG Meeting IETF 69 in Chicago, IL July 23, 2007, 1:00 PM - 3:00 PM Chaired by Steve Hanna and Susan Thomson Notes taken by Mani Mahalingam and Joe Tardo These notes do not attempt to duplicate all the material in the slides. Instead, they provide a brief summary of that material and focus on comments and discussion (especially consensus checks). Steve and Susan called the meeting to order at 1:04 PM and reviewed logistical information about the group (email list, chairs, etc.). Blue sheets were distributed and minutes scribes found. No Jabber scribes were found. The following draft agenda was agreed to: 1:00 Administrivia Blue Sheets Jabber & Minutes Scribes Agenda Bashing 1:05 WG Status 1:10 Discuss NEA Requirements Draft http://www.ietf.org/internet-drafts/draft-ietf-nea-requirements-03.txt 2:55 Review of Next Steps 3:00 Adjourn *WG Status* Steve reviewed the current status of the Working Group. Our requirements document is in Working Group Last Call. Please review it and sent comments to the list. Steve asked for a show of hands from those who have read some version of the requirements document and another show of hands from those who have read the latest version (-03). A good number of people raised their hands for both. Steve explained that our next steps are: * Finish WGLC on NEA Requirements I-D * Revise NEA Requirements I-D * Another WGLC if major changes made * Submit NEA Reqs I-D to IESG for IETF LC and approval as Informational RFC * Revise milestones to start work on PA & PB Tim Polk (our AD) agreed. Paul Hoffman: When will the rechartering start? Tim Polk: We should start work on that when IETF LC completes so that it can be approved when or shortly after the time when the IESG approves the requirements document. Steve Hanna: I hope we'll only need to change milestones not do a real rechartering. Tim Polk: If that's true, it will be easy. Hannes Tschofenig: The mailing list has been quiet, which means the document has not received much review. You need more review, especially since this document has more than just requirements. Tim Polk: Agreed. I'm going to recruit more reviewers. We were waiting until the document was solid. Steve Hanna: Could I see a show of hands from people who are willing to review the document? Got seven volunteers. Hannes: Write down people's names so you can bug them! Here are the names of the volunteers: Hao Zhou, Nancy Winget, Alan Breese, Alan DeKok, Joe Salowey, Mauricio Sanchez, and Hannes Tschofenig. Steve reviewed the NEA Reference Model and reminded people of the WG's scope: endpoint assessment and in particular agreeing on standard PA, PB, and PT protocols. *NEA Requirements* Kaushik Narayan started reviewing the latest NEA requirements document. He reviewed the changes made in the -02 and -03 drafts. See his slides for details. Kaushik raised some issues for discussion. 1) The current draft contains informative text that touches upon a few aspects of protocol design at a high level to provide guidance but does not impose requirements. Should this text be retained? Paul Hoffman: It's good to have this text as long as you make it VERY clear that this text is informative. Kaushik Narayan: We've tried to do that. Steve Hanna: Is it true that the only normative text is in the Requirements section? Kaushik Narayan: Yes. Steve Hanna: Maybe we should say that somewhere. Paul Sangster: We do. Susan Thomson: We must make sure this is clear and not confusing. Steve Hanna: Maybe we should place at the beginning of each section a reminder that all normative text is in the Requirements section. Susan Thomson: We should also avoid having too much informative text. Paul Sangster: I think we should just change the title for the Requirements section to say "ONLY NORMATIVE TEXT". Steve Hanna: That wouldn't address my concern sufficiently. Kaushik Narayan: Let's take this to the list. 2) Requirement PB-3 seems redundant in light of requirement C-1. In fact, the requirement for supporting multiple messages can be met by the PT layer or the PB layer so this requirement is going into protocol design. Should we remove requirement PB-3? There were no comments on this topic at the meeting. Kaushik Narayan: The Design Team has decided we'd like to remove requirement PB-3. If there are no other comments, we'll do so. 3) The Privacy Considerations section includes implementation guidelines. We haven't received much input on this section. Is it adequate? Too much? Not enough? Needs to be changed? Mauricio Sanchez: I think the document is going in the right direction and has the right level of detail. Steve Hanna: Are there privacy experts we should consult? Tim Polk: I'll look into that. Kaushik Narayan: And we'll take this to the list. Kaushik Narayan: OK. That's the last of the open issues we wanted to discuss today. But we thought it would be productive to review every one of the requirements in the draft now and see if anyone has any concerns or issues with them. Kaushik ran through the requirements, starting with C-1. The text here is taken from Kaushik's slides. C-1 Capable of multi-message dialog Hao Zhou: You mean multiple round trips? Kaushik Narayan: That's right. This is clear in the actual requirement text. I'm sorry the summary on the slide is ambiguous. C-2 Allow assessment prior and after normal network access C-3 Enable re-assessment by either client or server Paul Hoffman: What's the difference between C-2 and C-3? Kaushik Narayan: C-3 is about triggering. It's saying that either the client or server should be able to trigger a reassessment. Alan Breese: So C-2 is about initial assessment and C-3 is about reassessment? Kaushik Narayan: Actually, C-2 includes both initial assessment and reassessment. C-3 says either party can trigger reassessment. C-4 Protection against active/passive attacks by intermediaries C-5 PA and PB transport agnostic interfaces C-6 Selection process prefer reuse of existing open standards C-7 Scalable (many collectors and validators on multiple servers) C-8 Efficient transport of many Attributes C-9 Large numbers of compliance policies C-10 Allow for Assessment with reduced amount of information exchanged Alan DeKok: For C-8, if the server caches the results of previous assessments, later assessments can be quick since they can just send what has changed. For C-9, I'm not sure there's any way around that. If you don't comply, you may need to download a lot of data to come into compliance. Kaushik Narayan: For C-9, we'd just be looking for ways to make the data transmitted for assessment as small as possible. Alan DeKok: The only way we know to express complex policies is running code. So I'm not sure I agree with C-9. You can push down the policies during remediation along with patches, not during assessment. Then assessment will be much faster. Kaushik Narayan: We removed the idea of policy attributes so policies will no longer be pushed down during assessment. PA-1 Support transport standard Attributes PA-2 Support transport of vendor-specific Attributes PA-3 Enable validator to request Posture and Assertion Attributes from client's Collector PA-4 Allow for multiple requests for posture information within a single assessment. PA-5 Carry validator results and remediation instructions PA-6 Capable of authentication, integrity and confidentiality of Attributes PA-7 Capable of carrying Attributes including binary data PA-8 String Attributes being encoded with an encoding standard that supports internationalization. PB-1 Capable of carrying the decision and (if present) remediation instructions PB-2 Carry naming for collectors and validators (used for message delivery). Naming should allow for dynamic registration. PB-3 MAY be capable of authentication, integrity and confidentiality of messages, decision and remediation instructions PB-4 Support grouping of attributes to optimize messages per roundtrip PT-1 SHOULD incur low overhead for low bandwidth links PT-2 SHOULD be capable of using a half duplex link PT-3 MUST NOT interpret the contents of PB messages PT-4 Capable of protecting the integrity and confidentiality of the PB messages PT-5 Reliable delivery of PB messages (detect dups, fragmentation) PT-6 Capable of mutual authentication (possibly leveraging an authentication inside the protected tunnel.) An open mike session was next. Alan DeKok: Overall, much clearer than the previous versions. I'd still like to emphasize clarity and simplicity. I have sent some comments to the list and will send some more. In Section 5, every other word is "posture". At that point, it doesn't mean anything. Just take it out. There were no other comments. Steve Hanna: Please review the current draft, which is draft-ietf-nea-requirements-03.txt. It's in WGLC, which closes August 10. Send comments on the document to the list. _______________________________________________ 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 Aug 15 20:58:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILTh9-0000z4-GD; Wed, 15 Aug 2007 20:58:39 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1ILTh8-0000yy-2I for nea-confirm+ok@megatron.ietf.org; Wed, 15 Aug 2007 20:58:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILTh7-0000yq-Op for nea@ietf.org; Wed, 15 Aug 2007 20:58:37 -0400 Received: from extu-mxob-1.symantec.com ([216.10.194.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILTh6-0001ZT-Cv for nea@ietf.org; Wed, 15 Aug 2007 20:58:37 -0400 Received: from tus1opsmtapin01.ges.symantec.com ([192.168.214.43]:37675) by extu-mxob-1.symantec.com with esmtp (Exim 4.66) (envelope-from ) id 1ILTh5-0008E4-RI for nea@ietf.org; Wed, 15 Aug 2007 17:58:35 -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 1ILTgY-00041S-Jf for nea@ietf.org; Wed, 15 Aug 2007 17:58:02 -0700 Received: from TUS1XCHEVSPIN05.enterprise.veritas.com ([155.64.231.27]) by TUS1XCHECNPIN03.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Aug 2007 17:58:02 -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] Posted draft minutes from IETF 69 NEA meeting Date: Wed, 15 Aug 2007 17:57:33 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Posted draft minutes from IETF 69 NEA meeting Thread-Index: AcffcubxOuUOo9qgQLyQhM2m2e6H7AALEAJg References: From: "Paul Sangster" To: X-OriginalArrivalTime: 16 Aug 2007 00:58:02.0388 (UTC) FILETIME=[7F1F7D40:01C7DFA0] X-Brightmail-Tracker: AAAAAQAAAUA= X-Spam-Score: -4.0 (----) X-Scan-Signature: 155726d2f5fe5eb5c40a9f079fd9e841 X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org The minutes are a good reminder that we had hoped to take a couple topics to the mailing list. The design team raised the following question in Chicago: "3) The Privacy Considerations section includes implementation guidelines. We haven't received much input on this section. Is it adequate? Too much? Not enough? Needs to be changed?" There was not a lot of discussion about this during the meeting beside an initial show of support for section 9's direction. We would appreciate feedback on this section particularly whether the implementation guidance is helpful or whether it should be scaled back. In particular what should we do with section 9.2 discussing Minimal Attribute Disclosure. Comments welcome. In Chicago we also discussed whether and how to make it more clear that most of the document is informative and that only section 7 (requirements) are normative. In response to this discussion we added text in section 1 making this clear and then augmented the title of section to "Requirements (Only Normative Section)" and added text to the initial paragraph. Hopefully this is sufficient. Paul > -----Original Message----- > From: Stephen Hanna [mailto:shanna@juniper.net]=20 > Sent: Wednesday, August 15, 2007 12:32 PM > To: nea@ietf.org > Subject: [Nea] Posted draft minutes from IETF 69 NEA meeting >=20 > I have posted draft minutes from the IETF 69 NEA WG meeting=20 > on the IETF 69 meeting materials web site. > For your convenience, I have also copied them below. >=20 > Please review these minutes. If you find any errors or=20 > omissions, please send email to the list. The deadline for=20 > correcting these minutes is September 12 so please send=20 > corrections to the list by end of day on September 11 so I=20 > have time to make the corrections. >=20 > Thanks, >=20 > Steve >=20 > ----------- >=20 > Minutes from NEA WG Meeting > IETF 69 in Chicago, IL > July 23, 2007, 1:00 PM - 3:00 PM > Chaired by Steve Hanna and Susan Thomson Notes taken by Mani=20 > Mahalingam and Joe Tardo >=20 > These notes do not attempt to duplicate all the material in=20 > the slides. Instead, they provide a brief summary of that=20 > material and focus on comments and discussion (especially=20 > consensus checks). >=20 > Steve and Susan called the meeting to order at 1:04 PM and=20 > reviewed logistical information about the group (email list,=20 > chairs, etc.). > Blue sheets were distributed and minutes scribes found. No=20 > Jabber scribes were found. The following draft agenda was agreed to: >=20 > 1:00 Administrivia > Blue Sheets > Jabber & Minutes Scribes > Agenda Bashing > 1:05 WG Status > 1:10 Discuss NEA Requirements Draft > =20 > http://www.ietf.org/internet-drafts/draft-ietf-nea-requirements-03.txt > 2:55 Review of Next Steps > 3:00 Adjourn >=20 > *WG Status* >=20 > Steve reviewed the current status of the Working Group. > Our requirements document is in Working Group Last Call. > Please review it and sent comments to the list. >=20 > Steve asked for a show of hands from those who have read some=20 > version of the requirements document and another show of=20 > hands from those who have read the latest version (-03). > A good number of people raised their hands for both. >=20 > Steve explained that our next steps are: >=20 > * Finish WGLC on NEA Requirements I-D > * Revise NEA Requirements I-D > * Another WGLC if major changes made > * Submit NEA Reqs I-D to IESG for IETF LC and approval > as Informational RFC > * Revise milestones to start work on PA & PB >=20 > Tim Polk (our AD) agreed. >=20 > Paul Hoffman: When will the rechartering start? > Tim Polk: We should start work on that when IETF LC completes=20 > so that it can be approved when or shortly after the time=20 > when the IESG approves the requirements document. > Steve Hanna: I hope we'll only need to change milestones not=20 > do a real rechartering. > Tim Polk: If that's true, it will be easy. >=20 > Hannes Tschofenig: The mailing list has been quiet, which=20 > means the document has not received much review. You need=20 > more review, especially since this document has more than=20 > just requirements. > Tim Polk: Agreed. I'm going to recruit more reviewers. > We were waiting until the document was solid. >=20 > Steve Hanna: Could I see a show of hands from people who are=20 > willing to review the document? Got seven volunteers. > Hannes: Write down people's names so you can bug them! > Here are the names of the volunteers: Hao Zhou, Nancy Winget,=20 > Alan Breese, Alan DeKok, Joe Salowey, Mauricio Sanchez, and=20 > Hannes Tschofenig. >=20 > Steve reviewed the NEA Reference Model and reminded people of=20 > the WG's scope: endpoint assessment and in particular=20 > agreeing on standard PA, PB, and PT protocols. >=20 > *NEA Requirements* >=20 > Kaushik Narayan started reviewing the latest NEA requirements=20 > document. He reviewed the changes made in the -02 and -03 drafts. > See his slides for details. >=20 > Kaushik raised some issues for discussion. >=20 > 1) The current draft contains informative text that touches > upon a few aspects of protocol design at a high level to > provide guidance but does not impose requirements. Should > this text be retained? >=20 > Paul Hoffman: It's good to have this text as long as you make=20 > it VERY clear that this text is informative. > Kaushik Narayan: We've tried to do that. > Steve Hanna: Is it true that the only normative text is in=20 > the Requirements section? > Kaushik Narayan: Yes. > Steve Hanna: Maybe we should say that somewhere. > Paul Sangster: We do. > Susan Thomson: We must make sure this is clear and not confusing. > Steve Hanna: Maybe we should place at the beginning of each=20 > section a reminder that all normative text is in the=20 > Requirements section. > Susan Thomson: We should also avoid having too much informative text. > Paul Sangster: I think we should just change the title for=20 > the Requirements section to say "ONLY NORMATIVE TEXT". > Steve Hanna: That wouldn't address my concern sufficiently. > Kaushik Narayan: Let's take this to the list. >=20 > 2) Requirement PB-3 seems redundant in light of requirement C-1. > In fact, the requirement for supporting multiple messages can=20 > be met by the PT layer or the PB layer so this requirement is=20 > going into protocol design. Should we remove requirement PB-3? >=20 > There were no comments on this topic at the meeting. >=20 > Kaushik Narayan: The Design Team has decided we'd like to=20 > remove requirement PB-3. If there are no other comments, we'll do so. >=20 > 3) The Privacy Considerations section includes implementation=20 > guidelines. We haven't received much input on this section. > Is it adequate? Too much? Not enough? Needs to be changed? >=20 > Mauricio Sanchez: I think the document is going in the right=20 > direction and has the right level of detail. > Steve Hanna: Are there privacy experts we should consult? > Tim Polk: I'll look into that. > Kaushik Narayan: And we'll take this to the list. >=20 > Kaushik Narayan: OK. That's the last of the open issues we=20 > wanted to discuss today. But we thought it would be=20 > productive to review every one of the requirements in the=20 > draft now and see if anyone has any concerns or issues with them. >=20 > Kaushik ran through the requirements, starting with C-1. > The text here is taken from Kaushik's slides. >=20 > C-1 Capable of multi-message dialog >=20 > Hao Zhou: You mean multiple round trips? > Kaushik Narayan: That's right. This is clear in the actual=20 > requirement text. I'm sorry the summary on the slide is ambiguous. >=20 > C-2 Allow assessment prior and after normal network access > C-3 Enable re-assessment by either client or server >=20 > Paul Hoffman: What's the difference between C-2 and C-3? > Kaushik Narayan: C-3 is about triggering. It's saying that=20 > either the client or server should be able to trigger a reassessment. > Alan Breese: So C-2 is about initial assessment and C-3 is=20 > about reassessment? > Kaushik Narayan: Actually, C-2 includes both initial=20 > assessment and reassessment. C-3 says either party can=20 > trigger reassessment. >=20 > C-4 Protection against active/passive attacks by intermediaries > C-5 PA and PB transport agnostic interfaces > C-6 Selection process prefer reuse of existing open standards > C-7 Scalable (many collectors and validators on multiple servers) > C-8 Efficient transport of many Attributes > C-9 Large numbers of compliance policies C-10 Allow for=20 > Assessment with reduced amount of information exchanged >=20 > Alan DeKok: For C-8, if the server caches the results of=20 > previous assessments, later assessments can be quick since=20 > they can just send what has changed. For C-9, I'm not sure=20 > there's any way around that. If you don't comply, you may=20 > need to download a lot of data to come into compliance. > Kaushik Narayan: For C-9, we'd just be looking for ways to=20 > make the data transmitted for assessment as small as possible. > Alan DeKok: The only way we know to express complex policies=20 > is running code. So I'm not sure I agree with C-9. You can=20 > push down the policies during remediation along with patches,=20 > not during assessment. Then assessment will be much faster. > Kaushik Narayan: We removed the idea of policy attributes so=20 > policies will no longer be pushed down during assessment. >=20 > PA-1 Support transport standard Attributes > PA-2 Support transport of vendor-specific Attributes > PA-3 Enable validator to request Posture and Assertion Attributes > from client's Collector > PA-4 Allow for multiple requests for posture information within > a single assessment. > PA-5 Carry validator results and remediation instructions > PA-6 Capable of authentication, integrity and confidentiality > of Attributes > PA-7 Capable of carrying Attributes including binary data > PA-8 String Attributes being encoded with an encoding standard > that supports internationalization.=20 >=20 > PB-1 Capable of carrying the decision and (if present) remediation > instructions > PB-2 Carry naming for collectors and validators (used for message > delivery). Naming should allow for dynamic registration. > PB-3 MAY be capable of authentication, integrity and confidentiality > of messages, decision and remediation instructions > PB-4 Support grouping of attributes to optimize messages per roundtrip >=20 > PT-1 SHOULD incur low overhead for low bandwidth links > PT-2 SHOULD be capable of using a half duplex link > PT-3 MUST NOT interpret the contents of PB messages > PT-4 Capable of protecting the integrity and confidentiality of > the PB messages > PT-5 Reliable delivery of PB messages (detect dups, fragmentation) > PT-6 Capable of mutual authentication (possibly leveraging an > authentication inside the protected tunnel.) >=20 > An open mike session was next. >=20 > Alan DeKok: Overall, much clearer than the previous versions. > I'd still like to emphasize clarity and simplicity. I have=20 > sent some comments to the list and will send some more. In=20 > Section 5, every other word is "posture". At that point, it=20 > doesn't mean anything. Just take it out. >=20 > There were no other comments. >=20 > Steve Hanna: Please review the current draft, which is=20 > draft-ietf-nea-requirements-03.txt. It's in WGLC, which=20 > closes August 10. Send comments on the document to the list. >=20 >=20 > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea >=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Aug 16 00:34:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILX3j-0004nk-QN; Thu, 16 Aug 2007 00:34:11 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1ILX3i-0004nf-7f for nea-confirm+ok@megatron.ietf.org; Thu, 16 Aug 2007 00:34:10 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILX3h-0004nX-HP for nea@ietf.org; Thu, 16 Aug 2007 00:34:09 -0400 Received: from e36.co.us.ibm.com ([32.97.110.154]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ILX3f-00087e-Hm for nea@ietf.org; Thu, 16 Aug 2007 00:34:09 -0400 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e36.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l7G4Y6Do028111 for ; Thu, 16 Aug 2007 00:34:06 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v8.4) with ESMTP id l7G4Y6Ct270058 for ; Wed, 15 Aug 2007 22:34:06 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l7G4Y6oF032253 for ; Wed, 15 Aug 2007 22:34:06 -0600 Received: from d03nm129.boulder.ibm.com (d03nm129.boulder.ibm.com [9.17.195.155]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l7G4Y5iC032249; Wed, 15 Aug 2007 22:34:05 -0600 In-Reply-To: <003101c7ded6$b91afdf0$6501a8c0@tsg1> Subject: Re: [Nea] NEA requirements and internationalization To: "TS Glassey" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Frank Yeh Jr Date: Wed, 15 Aug 2007 21:33:28 -0700 X-MIMETrack: Serialize by Router on D03NM129/03/M/IBM(Release 7.0.2FP2HF51 | June 19, 2007) at 08/15/2007 22:34:05 MIME-Version: 1.0 X-Spam-Score: 2.6 (++) X-Scan-Signature: b4c10eaa27436d806c79842272125a2a 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="===============1733021343==" Errors-To: nea-bounces@ietf.org --===============1733021343== Content-type: multipart/related; Boundary="0__=07BBF9AADF8B1AB98f9e8a93df938690918c07BBF9AADF8B1AB9" --0__=07BBF9AADF8B1AB98f9e8a93df938690918c07BBF9AADF8B1AB9 Content-type: multipart/alternative; Boundary="1__=07BBF9AADF8B1AB98f9e8a93df938690918c07BBF9AADF8B1AB9" --1__=07BBF9AADF8B1AB98f9e8a93df938690918c07BBF9AADF8B1AB9 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Greetings, Todd, based on your argument below, wouldn't we have to eliminate= use of TCP/IP in all deployments affected by compliance auditing? Compliance does not have to be built into the network protocols, = nor would it be wise to try to do this. Compliance is something that happen= s at Layer 7, NEA is shooting at about Layer 2. If you want to get into a discussion into legal aspects of compliance, IBM has a few hundred lawyers who will engage and make sure= that you never get anything meaningful done ever again (trust me, I've = been there). Regards, Frank Yeh Sr. Security & Privacy Integration Architect IBM Global Technology Services Security & Privacy Technology Integration Team Second Life: Yehoo Newall = "TS Glassey" = = To "Alan DeKok" = 08/14/2007 05:53 = PM = cc nea@ietf.org = Subj= ect Re: [Nea] NEA requirements and = internationalization = = = = = = = Alan - pardon the tone of this. Nothing personal is meant by these responses but AHAHAHAHAHAHAHAHAHAHAh -I haven't laughed that hard in a while... N= ow that said - I am NOT against NEA just I want it to do more than what I already have implemented with DHCP and several other tools including Tripwire. Otherwise its doomed in my estimation. Todd ----- Original Message ----- From: "Alan DeKok" To: "TS Glassey" Cc: "Stephen Hanna" ; Sent: Sunday, August 12, 2007 6:38 PM Subject: Re: [Nea] NEA requirements and internationalization > TS Glassey wrote: >>> MAY, rather than MUST. Many sites will have a site-wide configura= tion >>> saying "language used by everyone here." >> >> So then you are suggesting that as part of the entitlement-enablemen= t >> process that the client is interactively configured. > > MAY be interactively configured. Or, as many administrators do, th > process may be scripted. scripting opens the system to security issues. It also enables many typ= es of script driven attacks too. > >> What I am saying is that based on new requirements from the Courts (= as >> of May 4th 2007) in the US there are now five specific tests for ESI= >> (Electronicially Stored Information) into the Court's as evidence, a= nd >> what that means is that in any system that 'may produce content that= may >> come to be reviewed as evidence' will need to meet these new >> requirements. >> >> What that means to us, is that if we are designing technologies to m= eet >> specific control requirements, there are now new constraints on thos= e >> systems which would come to be used in officia capacities. > > NEA is working on protocol level requirements and design. Logging, > UI, and legal issues are (IMHO) out of scope. its a good thing its just an opinion... what I am talking about is what= is required to place technologies into SOX and other regulated entities, a= nd if the IETF doesnt want to deal with those then it should specifically say= that in the scope statement to elminate the issues of legal compliance requirements. The problem is that most techies here have no idea what the law is doin= g to IT requirements and yet people continue to design technologies intentionally to fail to meet those requirements. The really funny thing to do is to listen to the IT Manager try and talk their way out of being dinged by = the IT Auditor's for running unsecured and rediculously stupid code in thei= r system, and as it happens I think that NEA is the next one of these win= ners to come out of the IETF. The issues are simple - and that is if there is a desire to install a system that can pre-qualify the security compliance and platform configuration= compliance into the IT world then it needs to do so in concert with the= Auditor's who will tell the IETF whether they are willing to put their names and professional reputation/credentials on the line by using this proto= col as their recommendation. Otherwise why bother? > An NEA requirement that > systems MAY transport user-visible strings is fine. However, certain= > implementations in certain jurisdictions MAY have additional > requirements on what is done with those strings. The EU Data Integrity "regulation" may not agree with you. > > If we design NEA for the lowest-common legal denominator, then we wi= ll > have a system that does nothing. No - but that is the typical claim from techies who dont know what they= are designing to. The problem with NEA is that there are regulatory requirements for this type of thing and the NEA WG wants to build something else tha= t doesnt address those but claims to apparently. > >> That said, since there are new 'requirements' in operating official >> systems, NEA should address those too... and that said, passing >> plain-text about is a no-no > > I'm a little at a loss to see how we can design an access protocol > that doesn't tell the user whether or not they've been granted access= , > or even if they've been denied. Uh simple - the users NIC can easily be used to tell them all kinds of things including NO CONNECTION. > A list of canned status/error messages > isn't good enough, as experience has shown. > >>> I would like the ability for administrators to push messages to en= d >>> users via NEA. This involves the *capability* to transport >>> internationalized strings in NEA. However, those strings are >>> informative to the end user, and opaque to the rest of NEA. >> >> So do a table of messages based on the entitlement models supported = and >> then publish UTF-8 strings of them in whatever language you want to >> support. > > Can we enumerate *enough* possible messages to be useful? I doubt i= t. Sure - a common set of messages is all that is necessary and simple UTF= -8 Encoding to make those transportable. > >>> I can understand this on the wide open net. For the chartered pur= pose >>> (enterprises), I don't see why it's a problem. >> >> Integrity of the Audit Process running inside the "Entity". Think o= f >> your average University for instance. How many would-be hackers are >> inside the Entity then. > > Charter. We have it. We should focus on it. Universities are out = of > scope. Issues with deploying NEA inside of Universities are out of > scope. If certain designs work in an enterprise, but not in a > university, then issues with the university deployment are irrelevant= . > They are canards, and out of scope. Screw the Academic issues, as a professional auditor I believe that you= nor no one else here will install NEA in its current form in any regulated networks period. I just wont fly with what you got now, whether you lik= e that or not, and whether you believe it or not... > >>> [ re: informational messages ] >>> No. They can be thrown away. Many PPP implementations have done = this >>> for years. It's annoying, but widely accepted practice. >> >> Depending what type of auditing and integrity of process model NEA i= s to >> support. > > I'm not really sure what you mean by that. Informational messages > are... informational. They have little definitive meaning. Uhh is NEA a tool for qualifying systems prior to accessing the entity resources? > > In contrast, messages like "you must upgrade now" are not > informational. They impose normative requirements on the user, and > should be logged, audited, etc. Agreed as should any status message from any transaction. > > Alan DeKok. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea = --1__=07BBF9AADF8B1AB98f9e8a93df938690918c07BBF9AADF8B1AB9 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Greetings,

Todd, based on your argument below, wouldn't we have to eliminate use = of TCP/IP in all deployments affected by compliance auditing?

Compliance does not have to be built into the network protocols, nor w= ould it be wise to try to do this. Compliance is something that happens= at Layer 7, NEA is shooting at about Layer 2.

If you want to get into a discussion into legal aspects of compliance,= IBM has a few hundred lawyers who will engage and make sure that you n= ever get anything meaningful done ever again (trust me, I've been there= ).


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

Second Life: Yehoo Newall

3D"Inactive"TS Glassey"= ; <tglassey@earthlink.net>


=
          "TS Glassey" <tglassey@earthlink.n= et>

          08/14/2007 05:53 PM

 =
3D=
To
3D""
"Alan DeKok" <aland@deployingradius.com&g= t;
3D=
cc
3D""
nea@ietf.org
3D=
Subject
3D""
Re: [Nea] NEA requirements and internationalization
3D=3D""

Alan - pardon the tone of this. Nothing personal is meant by these = responses
but AHAHAHAHAHAHAHAHAHAHAh -I haven't laughed that hard in a while... N= ow
that said - I am NOT against NEA just I want it to do more than what I =
already have implemented with DHCP and several other tools including Tripwire. Otherwise its doomed in my estimation.

Todd
----- Original Message -----
From: "Alan DeKok" <aland@deployingradius.com>
To: "TS Glassey" <tglassey@earthlink.net>
Cc: "Stephen Hanna" <shanna@juniper.net>; <nea@ietf.= org>
Sent: Sunday, August 12, 2007 6:38 PM
Subject: Re: [Nea] NEA requirements and internationalization


> TS Glassey wrote:
>>>  MAY, rather than MUST.  Many sites will have a = site-wide configuration
>>> saying "language used by everyone here."
>>
>> So then you are suggesting that as part of the entitlement-ena= blement
>> process that the client is interactively configured.
>
>  MAY be interactively configured.  Or, as many administr= ators do, th
> process may be scripted.

scripting opens the system to security issues. It also enables many typ= es of
script driven attacks too.

>
>> What I am saying is that based on new requirements from the Co= urts (as
>> of May 4th 2007) in the US there are now five specific tests f= or ESI
>> (Electronicially Stored Information) into the Court's as evide= nce, and
>> what that means is that in any system that 'may produce conten= t that may
>> come to be reviewed as evidence' will need to meet these new <= br> >> requirements.
>>
>> What that means to us, is that if we are designing technologie= s to meet
>> specific control requirements, there are now new constraints o= n those
>> systems which would come to be used in officia capacities.
= >
>  NEA is working on protocol level requirements and design. &n= bsp;Logging,
> UI, and legal issues are (IMHO) out of scope.

its a good thing its just an opinion... what I am talking about is what= is
required to place technologies into SOX and other regulated entities, a= nd if
the IETF doesnt want to deal with those then it should specifically say= that
in the scope statement to elminate the issues of legal compliance
requirements.

The problem is that most techies here have no idea what the law is doin= g to
IT requirements and yet people continue to design technologies intentio= nally
to fail to meet those requirements. The really funny thing to do is to =
listen to the IT Manager try and talk their way out of being dinged by = the
IT Auditor's for running unsecured and rediculously stupid code in thei= r
system, and as it happens I think that NEA is the next one of these win= ners
to come out of the IETF.

The issues are simple - and that is if there is a desire to install a s= ystem
that can pre-qualify the security compliance and platform configuration=
compliance into the IT world then it needs to do so in concert with the=
Auditor's who will tell the IETF whether they are willing to put their = names
and professional reputation/credentials on the line by using this proto= col
as  their recommendation. Otherwise why bother?

> An NEA requirement that
> systems MAY transport user-visible strings is fine.  However,= certain
> implementations in certain jurisdictions MAY have additional
> requirements on what is done with those strings.

The EU Data Integrity "regulation" may not agree with you.
>
>  If we design NEA for the lowest-common legal denominator, th= en we will
> have a system that does nothing.

No - but that is the typical claim from techies who dont know what they= are
designing to. The problem with NEA is that there are regulatory require= ments
for this type of thing and the NEA WG wants to build something else tha= t
doesnt address those but claims to apparently.

>
>> That said, since there are new 'requirements' in operating off= icial
>> systems, NEA should address those too... and that said, passin= g
>> plain-text about is a no-no
>
>  I'm a little at a loss to see how we can design an access pr= otocol
> that doesn't tell the user whether or not they've been granted acc= ess,
> or even if they've been denied.

Uh simple - the users NIC can easily be used to tell them all kinds of =
things including NO CONNECTION.

> A list of canned status/error messages
> isn't good enough, as experience has shown.
>
>>>  I would like the ability for administrators to push = messages to end
>>> users via NEA.  This involves the *capability* to tra= nsport
>>> internationalized strings in NEA.  However, those str= ings are
>>> informative to the end user, and opaque to the rest of NEA= .
>>
>> So do a table of messages based on the entitlement models supp= orted and
>> then publish UTF-8 strings of them in whatever language you wa= nt to
>> support.
>
>  Can we enumerate *enough* possible messages to be useful? &n= bsp;I doubt it.

Sure - a common set of messages is all that is necessary and simple UTF= -8
Encoding to make those transportable.

>
>>>  I can understand this on the wide open net.  Fo= r the chartered purpose
>>> (enterprises), I don't see why it's a problem.
>>
>> Integrity of the Audit Process running inside the "Entity= ".  Think of
>> your average University for instance. How many would-be hacker= s are
>> inside the Entity then.
>
>  Charter.  We have it.  We should focus on it. &nbs= p;Universities are out of
> scope.  Issues with deploying NEA inside of Universities are = out of
> scope.  If certain designs work in an enterprise, but not in = a
> university, then issues with the university deployment are irrelev= ant.
> They are canards, and out of scope.

Screw the Academic issues, as a professional auditor I believe that you= nor
no one else here will install NEA in its current form in any regulated =
networks period. I just wont fly with what you got now, whether you lik= e
that or not, and whether you believe it or not...

>
>>> [ re: informational messages ]
>>>  No.  They can be thrown away.  Many PPP im= plementations have done this
>>> for years.  It's annoying, but widely accepted practi= ce.
>>
>> Depending what type of auditing and integrity of process model= NEA is to
>> support.
>
>  I'm not really sure what you mean by that.  Information= al messages
> are... informational.  They have little definitive meaning.
Uhh is NEA a tool for qualifying systems prior to accessing the entity =
resources?

>
>  In contrast, messages like "you must upgrade now" = are not
> informational.  They impose normative requirements on the use= r, and
> should be logged, audited, etc.

Agreed as should any status message from any transaction.

>
>  Alan DeKok.



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

= --1__=07BBF9AADF8B1AB98f9e8a93df938690918c07BBF9AADF8B1AB9-- --0__=07BBF9AADF8B1AB98f9e8a93df938690918c07BBF9AADF8B1AB9 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=07BBF9AADF8B1AB98f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=07BBF9AADF8B1AB98f9e8a93df938690918c07BBF9AADF8B1AB9 Content-type: image/gif; name="pic12068.gif" Content-Disposition: inline; filename="pic12068.gif" Content-ID: <2__=07BBF9AADF8B1AB98f9e8a93df938@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__=07BBF9AADF8B1AB98f9e8a93df938690918c07BBF9AADF8B1AB9 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <3__=07BBF9AADF8B1AB98f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=07BBF9AADF8B1AB98f9e8a93df938690918c07BBF9AADF8B1AB9-- --===============1733021343== 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 --===============1733021343==-- From nea-bounces@ietf.org Thu Aug 16 10:25: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 1ILgI3-0002y6-Eu; Thu, 16 Aug 2007 10:25:35 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1ILgI2-0002xq-3m for nea-confirm+ok@megatron.ietf.org; Thu, 16 Aug 2007 10:25:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILgI1-0002xf-QF for nea@ietf.org; Thu, 16 Aug 2007 10:25:33 -0400 Received: from elasmtp-spurfowl.atl.sa.earthlink.net ([209.86.89.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILgHz-00087V-8N for nea@ietf.org; Thu, 16 Aug 2007 10:25:33 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=KwxW7tIMh8Vy++xboWQAo3LZ3eO2g4J+GQ80jBTFbQLLRXfspBhDFWjDhdzm6pmV; 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 1ILgHw-00051U-8E; Thu, 16 Aug 2007 10:25:28 -0400 Message-ID: <00d801c7e011$4cfcf2e0$174f7d40@home.glassey.com> From: "todd glassey" To: "Frank Yeh Jr" References: Subject: Re: [Nea] NEA requirements and internationalization Date: Thu, 16 Aug 2007 07:25:17 -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: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec795ac6c13da79ff1a40be680e4d9884d87350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.125.79.23 X-Spam-Score: 1.0 (+) X-Scan-Signature: d70738b58489ee14fb507f541b784688 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="===============2045335913==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============2045335913== Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_00D0_01C7DFD6.987A5D60" This is a multi-part message in MIME format. ------=_NextPart_000_00D0_01C7DFD6.987A5D60 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00D1_01C7DFD6.987A5D60" ------=_NextPart_001_00D1_01C7DFD6.987A5D60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sorry Frank, I disagree - more inline below...=20 ----- Original Message -----=20 From: Frank Yeh Jr=20 To: TS Glassey=20 Cc: Alan DeKok ; nea@ietf.org=20 Sent: Wednesday, August 15, 2007 9:33 PM Subject: Re: [Nea] NEA requirements and internationalization Greetings, Todd, based on your argument below, wouldn't we have to eliminate use = of TCP/IP in all deployments affected by compliance auditing? Not from my viewpoint. But the issue is in creating systems which use = what is available to accomplish those requirements. So "No... IP can be = audited" it just takes an additional amount of overhead to do it.=20 XNS by comparison, and even OSX/SPX were better protocols for that type = of thing. And remember what TCP/IP was designed to do. Its a = demonstration protocol built under contract to ARPA by BB&N to = facilitate the operations of the Air Force's data exchange network with = military and academic institutions. It (TCP/IP) was never built to be = secured or audited in the sense of something say like the services = provided electronically from the Federal Reserve Bank or like entities. = And YES Frank I still have one of Stanford's old Honnywell H316 IMP's in = my garage so...=20 By the way - inside the DoD and intelligence Community, CIPR and NIPR = net's replaced the ARPA Net for secured communications so formally the = US Military itself DOESNT rely on publicly routed TCP/IP like the rest = of us do... Compliance does not have to be built into the network protocols, nor = would it be wise to try to do this.=20 Boy is that a broken statement. Sorry Frank you ARE wrong here - and = that is part of the problem with why the Audit Community is estranged = from this Standards Body. Compliance with regulatory requirements = happens at ALL levels and that is simply that. The problem with layering = compliance on the Application Layer is that it requires a = fully-functional station prior to compliance being determined. Which is = why NEA's working at Layer-2/3 is so important. Application Layer = certification means that the OS is already up and running on the = client-node and that means that prior to its being authorized to = participate in that network's operations it is already a threat to the = integrity of the system... And yes - we can thank the design of IP for that. Compliance is something that happens at Layer 7, NEA is shooting at = about Layer 2. Frank... You actually mean layer 4 right? See TCP/IP was not designed on = the ISO OSI model but rather prior to the ISO's Seven Layer OSI Model's = birth. If you want to get into a discussion into legal aspects of compliance, = IBM has a few hundred lawyers who will engage and make sure that you = never get anything meaningful done ever again (trust me, I've been = there). Actually - I formally presented IBM's General Counsel with a set of = compliance questions, and they refused to answer or even acknowledge = that they had been asked. I asked Lou Lupin, General Counsel of Qualcomm = the same Questions and Mark Chamber's, General Counsel of Cisco the same = set. Cisco was the only one that answered the questions by the way, so = again Frank I disagree.=20 Todd Glassey Regards, Frank Yeh Sr. Security & Privacy Integration Architect IBM Global Technology Services Security & Privacy Technology Integration Team Second Life: Yehoo Newall "TS Glassey" "TS Glassey" =20 08/14/2007 05:53 PM =20 To=20 "Alan DeKok" =20 cc=20 nea@ietf.org=20 Subject=20 Re: [Nea] NEA requirements and internationalization=20 =20 =20 Alan - pardon the tone of this. Nothing personal is meant by these = responses=20 but AHAHAHAHAHAHAHAHAHAHAh -I haven't laughed that hard in a while... = Now=20 that said - I am NOT against NEA just I want it to do more than what I = already have implemented with DHCP and several other tools including=20 Tripwire. Otherwise its doomed in my estimation. Todd ----- Original Message -----=20 From: "Alan DeKok" To: "TS Glassey" Cc: "Stephen Hanna" ; Sent: Sunday, August 12, 2007 6:38 PM Subject: Re: [Nea] NEA requirements and internationalization > TS Glassey wrote: >>> MAY, rather than MUST. Many sites will have a site-wide = configuration >>> saying "language used by everyone here." >> >> So then you are suggesting that as part of the = entitlement-enablement >> process that the client is interactively configured. > > MAY be interactively configured. Or, as many administrators do, th > process may be scripted. scripting opens the system to security issues. It also enables many = types of=20 script driven attacks too. > >> What I am saying is that based on new requirements from the Courts = (as >> of May 4th 2007) in the US there are now five specific tests for = ESI >> (Electronicially Stored Information) into the Court's as evidence, = and >> what that means is that in any system that 'may produce content = that may >> come to be reviewed as evidence' will need to meet these new=20 >> requirements. >> >> What that means to us, is that if we are designing technologies to = meet >> specific control requirements, there are now new constraints on = those >> systems which would come to be used in officia capacities. > > NEA is working on protocol level requirements and design. Logging, > UI, and legal issues are (IMHO) out of scope. its a good thing its just an opinion... what I am talking about is = what is=20 required to place technologies into SOX and other regulated entities, = and if=20 the IETF doesnt want to deal with those then it should specifically = say that=20 in the scope statement to elminate the issues of legal compliance=20 requirements. The problem is that most techies here have no idea what the law is = doing to=20 IT requirements and yet people continue to design technologies = intentionally=20 to fail to meet those requirements. The really funny thing to do is to = listen to the IT Manager try and talk their way out of being dinged by = the=20 IT Auditor's for running unsecured and rediculously stupid code in = their=20 system, and as it happens I think that NEA is the next one of these = winners=20 to come out of the IETF. The issues are simple - and that is if there is a desire to install a = system=20 that can pre-qualify the security compliance and platform = configuration=20 compliance into the IT world then it needs to do so in concert with = the=20 Auditor's who will tell the IETF whether they are willing to put their = names=20 and professional reputation/credentials on the line by using this = protocol=20 as their recommendation. Otherwise why bother? > An NEA requirement that > systems MAY transport user-visible strings is fine. However, = certain > implementations in certain jurisdictions MAY have additional > requirements on what is done with those strings. The EU Data Integrity "regulation" may not agree with you. > > If we design NEA for the lowest-common legal denominator, then we = will > have a system that does nothing. No - but that is the typical claim from techies who dont know what = they are=20 designing to. The problem with NEA is that there are regulatory = requirements=20 for this type of thing and the NEA WG wants to build something else = that=20 doesnt address those but claims to apparently. > >> That said, since there are new 'requirements' in operating official >> systems, NEA should address those too... and that said, passing >> plain-text about is a no-no > > I'm a little at a loss to see how we can design an access protocol > that doesn't tell the user whether or not they've been granted = access, > or even if they've been denied. Uh simple - the users NIC can easily be used to tell them all kinds of = things including NO CONNECTION. > A list of canned status/error messages > isn't good enough, as experience has shown. > >>> I would like the ability for administrators to push messages to = end >>> users via NEA. This involves the *capability* to transport >>> internationalized strings in NEA. However, those strings are >>> informative to the end user, and opaque to the rest of NEA. >> >> So do a table of messages based on the entitlement models supported = and >> then publish UTF-8 strings of them in whatever language you want to >> support. > > Can we enumerate *enough* possible messages to be useful? I doubt = it. Sure - a common set of messages is all that is necessary and simple = UTF-8=20 Encoding to make those transportable. > >>> I can understand this on the wide open net. For the chartered = purpose >>> (enterprises), I don't see why it's a problem. >> >> Integrity of the Audit Process running inside the "Entity". Think = of >> your average University for instance. How many would-be hackers are >> inside the Entity then. > > Charter. We have it. We should focus on it. Universities are out = of > scope. Issues with deploying NEA inside of Universities are out of > scope. If certain designs work in an enterprise, but not in a > university, then issues with the university deployment are = irrelevant. > They are canards, and out of scope. Screw the Academic issues, as a professional auditor I believe that = you nor=20 no one else here will install NEA in its current form in any regulated = networks period. I just wont fly with what you got now, whether you = like=20 that or not, and whether you believe it or not... > >>> [ re: informational messages ] >>> No. They can be thrown away. Many PPP implementations have done = this >>> for years. It's annoying, but widely accepted practice. >> >> Depending what type of auditing and integrity of process model NEA = is to >> support. > > I'm not really sure what you mean by that. Informational messages > are... informational. They have little definitive meaning. Uhh is NEA a tool for qualifying systems prior to accessing the entity = resources? > > In contrast, messages like "you must upgrade now" are not > informational. They impose normative requirements on the user, and > should be logged, audited, etc. Agreed as should any status message from any transaction. > > Alan DeKok.=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea ------=_NextPart_001_00D1_01C7DFD6.987A5D60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Sorry Frank, = I disagree -=20 more inline below...
 
----- Original Message -----
From:=20 Frank Yeh = Jr
Sent: Wednesday, August 15, = 2007 9:33=20 PM
Subject: Re: [Nea] NEA = requirements and=20 internationalization

Greetings,

Todd, based on your argument below, wouldn't we = have to=20 eliminate use of TCP/IP in all deployments affected by compliance=20 auditing?

Not from my = viewpoint. But the=20 issue is in creating systems which use what is available to accomplish = those=20 requirements.  So "No... IP can be audited" it just takes an = additional=20 amount of overhead to do it.

XNS by comparison, = and even=20 OSX/SPX were better protocols for that type of thing. And remember what = TCP/IP=20 was designed to do. Its a demonstration protocol built under contract to = ARPA by=20 BB&N to facilitate the operations of the Air Force's data = exchange=20 network with military and academic institutions. It (TCP/IP) was never = built to=20 be secured or audited in the sense of something say like the services = provided=20 electronically from the Federal Reserve Bank or like entities. And YES = Frank I=20 still have one of Stanford's old Honnywell H316 IMP's in my garage = so...=20

By the way - inside = the DoD and=20 intelligence Community, CIPR and NIPR net's replaced the ARPA Net for = secured=20 communications so formally the US Military itself DOESNT rely on = publicly routed=20 TCP/IP like the rest of us do...



Compliance does not have to be built into the network = protocols,=20 nor would it be wise to try to do this.

Boy is that a = broken statement.=20 Sorry Frank you ARE wrong here - and that is part of the problem with = why the=20 Audit Community is estranged from this Standards Body. Compliance with=20 regulatory requirements happens at ALL levels and that is simply that. = The=20 problem with layering compliance on the Application Layer is that it = requires a=20 fully-functional station prior to compliance being determined. Which is = why=20 NEA's working at Layer-2/3 is so important. Application Layer = certification=20 means that the OS is already up and running on the client-node and that = means=20 that prior to its being authorized to participate in that network's = operations=20 it is already a threat to the integrity of the system...

And yes - we can = thank the design=20 of IP for that.

 

Compliance is something that happens at Layer 7, NEA is shooting at = about=20 Layer 2.

Frank... You = actually mean layer=20 4 right? See TCP/IP was not designed on the ISO OSI model but rather = prior to=20 the ISO's Seven Layer OSI Model's birth.



If you want to get into a discussion into legal aspects of=20 compliance, IBM has a few hundred lawyers who will engage and make = sure that=20 you never get anything meaningful done ever again (trust me, I've been = there).

Actually - I = formally presented=20 IBM's General Counsel with a set of compliance questions, and they = refused to=20 answer or even acknowledge that they had been asked. I asked Lou Lupin, = General=20 Counsel of Qualcomm the same Questions and Mark Chamber's, General = Counsel=20 of Cisco the same set. Cisco was the only one that answered the = questions by the=20 way, so again Frank I disagree.

Todd = Glassey




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

Second Life: Yehoo = Newall

'=20 src=3D"cid:00ce01c7e011$44d20970$174f7d40@home.glassey.com" width=3D16 = border=3D0>"TS Glassey" <tglassey@earthlink.net>


          "TS Glassey"=20 <tglassey@earthlink.net> =

          08/14/2007 05:53 = PM

3D""=20
To
 3D""=20
"Alan DeKok"=20 <aland@deployingradius.com>
3D""=20
cc
 3D""=20
nea@ietf.org
3D""=20
Subject
 3D""=20
Re: [Nea] NEA requirements = and=20 internationalization
3D""=20 3D""=20


Alan - pardon the tone of this. Nothing personal is meant = by these=20 responses
but AHAHAHAHAHAHAHAHAHAHAh -I haven't laughed that hard = in a=20 while... Now
that said - I am NOT against NEA just I want it to do = more=20 than what I
already have implemented with DHCP and several other = tools=20 including
Tripwire. Otherwise its doomed in my=20 estimation.

Todd
----- Original Message -----
From: = "Alan DeKok"=20 <aland@deployingradius.com>
To: "TS Glassey"=20 <tglassey@earthlink.net>
Cc: "Stephen Hanna"=20 <shanna@juniper.net>; <nea@ietf.org>
Sent: Sunday, = August 12,=20 2007 6:38 PM
Subject: Re: [Nea] NEA requirements and=20 internationalization


> TS Glassey wrote:
>>> =  MAY, rather than MUST.  Many sites will have a site-wide=20 configuration
>>> saying "language used by everyone=20 here."
>>
>> So then you are suggesting that as part = of the=20 entitlement-enablement
>> process that the client is = interactively=20 configured.
>
>  MAY be interactively configured. =  Or,=20 as many administrators do, th
> process may be=20 scripted.

scripting opens the system to security issues. It = also=20 enables many types of
script driven attacks = too.

>
>>=20 What I am saying is that based on new requirements from the Courts=20 (as
>> of May 4th 2007) in the US there are now five specific = tests=20 for ESI
>> (Electronicially Stored Information) into the = Court's as=20 evidence, and
>> what that means is that in any system that = 'may=20 produce content that may
>> come to be reviewed as evidence' = will=20 need to meet these new
>> = requirements.
>>
>> What=20 that means to us, is that if we are designing technologies to = meet
>>=20 specific control requirements, there are now new constraints on=20 those
>> systems which would come to be used in officia=20 capacities.
>
>  NEA is working on protocol level=20 requirements and design.  Logging,
> UI, and legal issues = are=20 (IMHO) out of scope.

its a good thing its just an opinion... = what I am=20 talking about is what is
required to place technologies into SOX = and other=20 regulated entities, and if
the IETF doesnt want to deal with those = then it=20 should specifically say that
in the scope statement to elminate = the issues=20 of legal compliance
requirements.

The problem is that most = techies=20 here have no idea what the law is doing to
IT requirements and yet = people=20 continue to design technologies intentionally
to fail to meet = those=20 requirements. The really funny thing to do is to
listen to the IT = Manager=20 try and talk their way out of being dinged by the
IT Auditor's for = running=20 unsecured and rediculously stupid code in their
system, and as it = happens=20 I think that NEA is the next one of these winners
to come out of = the=20 IETF.

The issues are simple - and that is if there is a desire = to=20 install a system
that can pre-qualify the security compliance and = platform=20 configuration
compliance into the IT world then it needs to do so = in=20 concert with the
Auditor's who will tell the IETF whether they are = willing=20 to put their names
and professional reputation/credentials on the = line by=20 using this protocol
as  their recommendation. Otherwise why=20 bother?

> An NEA requirement that
> systems MAY = transport=20 user-visible strings is fine.  However, certain
> = implementations=20 in certain jurisdictions MAY have additional
> requirements on = what is=20 done with those strings.

The EU Data Integrity "regulation" may = not=20 agree with you.

>
>  If we design NEA for the=20 lowest-common legal denominator, then we will
> have a system = that does=20 nothing.

No - but that is the typical claim from techies who = dont know=20 what they are
designing to. The problem with NEA is that there are = regulatory requirements
for this type of thing and the NEA WG = wants to=20 build something else that
doesnt address those but claims to=20 apparently.

>
>> That said, since there are new=20 'requirements' in operating official
>> systems, NEA should = address=20 those too... and that said, passing
>> plain-text about is a=20 no-no
>
>  I'm a little at a loss to see how we can = design an=20 access protocol
> that doesn't tell the user whether or not = they've been=20 granted access,
> or even if they've been denied.

Uh = simple - the=20 users NIC can easily be used to tell them all kinds of
things = including NO=20 CONNECTION.

> A list of canned status/error messages
> = isn't=20 good enough, as experience has shown.
>
>>>  I = would=20 like the ability for administrators to push messages to = end
>>>=20 users via NEA.  This involves the *capability* to=20 transport
>>> internationalized strings in NEA. =  However,=20 those strings are
>>> informative to the end user, and = opaque to=20 the rest of NEA.
>>
>> So do a table of messages = based on=20 the entitlement models supported and
>> then publish UTF-8 = strings of=20 them in whatever language you want to
>> = support.
>
>=20  Can we enumerate *enough* possible messages to be useful? =  I doubt=20 it.

Sure - a common set of messages is all that is necessary = and simple=20 UTF-8
Encoding to make those = transportable.

>
>>>=20  I can understand this on the wide open net.  For the = chartered=20 purpose
>>> (enterprises), I don't see why it's a=20 problem.
>>
>> Integrity of the Audit Process = running inside=20 the "Entity".  Think of
>> your average University for = instance.=20 How many would-be hackers are
>> inside the Entity=20 then.
>
>  Charter.  We have it.  We should = focus=20 on it.  Universities are out of
> scope.  Issues with=20 deploying NEA inside of Universities are out of
> scope. =  If=20 certain designs work in an enterprise, but not in a
> = university, then=20 issues with the university deployment are irrelevant.
> They are = canards, and out of scope.

Screw the Academic issues, as a = professional=20 auditor I believe that you nor
no one else here will install NEA = in its=20 current form in any regulated
networks period. I just wont fly = with what=20 you got now, whether you like
that or not, and whether you believe = it or=20 not...

>
>>> [ re: informational messages=20 ]
>>>  No.  They can be thrown away.  Many = PPP=20 implementations have done this
>>> for years.  It's = annoying,=20 but widely accepted practice.
>>
>> Depending what = type of=20 auditing and integrity of process model NEA is to
>>=20 support.
>
>  I'm not really sure what you mean by = that.=20  Informational messages
> are... informational.  They = have=20 little definitive meaning.

Uhh is NEA a tool for qualifying = systems=20 prior to accessing the entity
resources?

>
> =  In=20 contrast, messages like "you must upgrade now" are not
> = informational.=20  They impose normative requirements on the user, and
> = should be=20 logged, audited, etc.

Agreed as should any status message from = any=20 transaction.

>
>  Alan DeKok.=20



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

------=_NextPart_001_00D1_01C7DFD6.987A5D60-- ------=_NextPart_000_00D0_01C7DFD6.987A5D60 Content-Type: image/gif; name="graycol.gif" Content-Transfer-Encoding: base64 Content-ID: <00ce01c7e011$44d20970$174f7d40@home.glassey.com> R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 ------=_NextPart_000_00D0_01C7DFD6.987A5D60 Content-Type: image/gif; name="ecblank.gif" Content-Transfer-Encoding: base64 Content-ID: <00cf01c7e011$44d20970$174f7d40@home.glassey.com> R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 ------=_NextPart_000_00D0_01C7DFD6.987A5D60-- --===============2045335913== 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 --===============2045335913==-- From nea-bounces@ietf.org Thu Aug 16 12:03:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILhp6-0003Yg-VH; Thu, 16 Aug 2007 12:03:48 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1ILhTa-0003UX-3I for nea-confirm+ok@megatron.ietf.org; Thu, 16 Aug 2007 11:41:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILhTZ-0003UN-PG for nea@ietf.org; Thu, 16 Aug 2007 11:41:33 -0400 Received: from e31.co.us.ibm.com ([32.97.110.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILhTX-000291-JY for nea@ietf.org; Thu, 16 Aug 2007 11:41:33 -0400 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e31.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l7GFfUUZ011076 for ; Thu, 16 Aug 2007 11:41:30 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v8.5) with ESMTP id l7GFfNBT206082 for ; Thu, 16 Aug 2007 09:41:24 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l7GFfNoe018602 for ; Thu, 16 Aug 2007 09:41:23 -0600 Received: from d03nm129.boulder.ibm.com (d03nm129.boulder.ibm.com [9.17.195.155]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l7GFfMDX018594; Thu, 16 Aug 2007 09:41:22 -0600 In-Reply-To: <00d801c7e011$4cfcf2e0$174f7d40@home.glassey.com> Subject: Re: [Nea] NEA requirements and internationalization To: "todd glassey" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Frank Yeh Jr Date: Thu, 16 Aug 2007 08:40:39 -0700 X-MIMETrack: Serialize by Router on D03NM129/03/M/IBM(Release 7.0.2FP2HF51 | June 19, 2007) at 08/16/2007 09:41:22 MIME-Version: 1.0 X-Spam-Score: -4.0 (----) X-Scan-Signature: ad5310d4a40550521c18cacd3b6e7111 X-Mailman-Approved-At: Thu, 16 Aug 2007 12:03:47 -0400 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2010104989==" Errors-To: nea-bounces@ietf.org --===============2010104989== Content-type: multipart/related; Boundary="0__=07BBF9AADFC3516C8f9e8a93df938690918c07BBF9AADFC3516C" --0__=07BBF9AADFC3516C8f9e8a93df938690918c07BBF9AADFC3516C Content-type: multipart/alternative; Boundary="1__=07BBF9AADFC3516C8f9e8a93df938690918c07BBF9AADFC3516C" --1__=07BBF9AADFC3516C8f9e8a93df938690918c07BBF9AADFC3516C Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Todd, I am fine with not being in agreement. We just have a different philosophy when it comes to how this sho= uld all be approached. More in line below, this round's comments tagged with FYEH:. Regards, Frank Yeh Sr. Security & Privacy Integration Architect IBM Global Technology Services Security & Privacy Technology Integration Team Second Life: Yehoo Newall = "todd glassey" = = To Frank Yeh Jr/Irvine/IBM@IBMUS = 08/16/2007 07:25 = cc AM "Alan DeKok" = , = = Subj= ect Re: [Nea] NEA requirements and = internationalization = = = = = = = Sorry Frank, I disagree - more inline below... ----- Original Message ----- From: Frank Yeh Jr To: TS Glassey Cc: Alan DeKok ; nea@ietf.org Sent: Wednesday, August 15, 2007 9:33 PM Subject: Re: [Nea] NEA requirements and internationalization Greetings, Todd, based on your argument below, wouldn't we have to eliminate use = of TCP/IP in all deployments affected by compliance auditing? Not from my viewpoint. But the issue is in creating systems which use w= hat is available to accomplish those requirements. So "No... IP can be audited" it just takes an additional amount of overhead to do it. FYEH: My point is that TCP/IP was not designed for existence in a compliance and auditing driven environment and yet we contiunue to use = it today and will continue to do so into the future. Your observations abo= ut its history bear this out. We are not going to eliminate TCP/IP soon, s= o we are stuck with it and so is the audit community. Do you realistically t= hink we can replace TCP/IP with something the auditers are comfortable with?= How do we do that? Turn off the internet for a maintenance upgrade? Can we = work that into the IPv6 cutover? XNS by comparison, and even OSX/SPX were better protocols for that type= of thing. And remember what TCP/IP was designed to do. Its a demonstration= protocol built under contract to ARPA by BB&N to facilitate the operati= ons of the Air Force's data exchange network with military and academic institutions. It (TCP/IP) was never built to be secured or audited in t= he sense of something say like the services provided electronically from t= he Federal Reserve Bank or like entities. And YES Frank I still have one o= f Stanford's old Honnywell H316 IMP's in my garage so... FYEH: LOL! DUDE! It's time to move on! IBM has stopped investing in Tok= en Ring and SNA even though they offered a host of advantages over etherne= t and IP. The fact that you actually have the honeywell taking up space i= n your garage is a bit scary! Donate it to a museum and share this bit of= history with the public. By the way - inside the DoD and intelligence Community, CIPR and NIPR n= et's replaced the ARPA Net for secured communications so formally the US Military itself DOESNT rely on publicly routed TCP/IP like the rest of = us do... FYEH: CIPRnet and NIPRnet are both acronyms that include IPR which stan= ds for Internet Protocol Routers!!! CIPRNet is definitely not publicy rout= ed, NIPRNet is part of the publicly routed network, with access to many of = the .mil domains being routed through it, but this is a complete non-sequit= er. How you design a protocol and how people use it should not be confused.= The fact that CIPRNet depends on physcial separation probably lends credenc= e o the fact that TCP/IP is not designed for security or audit but that is = a unique case. The rest of us need to operate in the real world. Compliance does not have to be built into the network protocols, nor wo= uld it be wise to try to do this. Boy is that a broken statement. Sorry Frank you ARE wrong here - and th= at is part of the problem with why the Audit Community is estranged from t= his Standards Body. Compliance with regulatory requirements happens at ALL levels and that is simply that. The problem with layering compliance on= the Application Layer is that it requires a fully-functional station prior = to compliance being determined. Which is why NEA's working at Layer-2/3 is= so important. Application Layer certification means that the OS is already= up and running on the client-node and that means that prior to its being authorized to participate in that network's operations it is already a threat to the integrity of the system... And yes - we can thank the design of IP for that. FYEH: I will agree to disagree on this if you will. IMHO YOU are wrong!= !! ;-P I understand what you want at a philosophical level, but if we trie= d to build what you desire, we would never be done. You just can't build everything into a single protocol. We DEPEND on separation at different= layers and interafces between them. These are what the protocols do. Yo= u are right that with this segmentation, we have to prove compliance at a= number of different levels, but this is NOT what NEA is intended to do.= It will be used to provide a reasonably secure way for clients and servers= of applications that normally work at layer 7 to communicate at layer 2 to= establish some level of trust before allowing the network to provide La= yer 3 conntectivity. When you look at the TCG model, there is a whole set = of protocols and practices external to TNC (their version of what NEA is trying to standardize) to provide a trusted stack with compliance prove= n at every level and based on a hardware root of trust. Compliance is something that happens at Layer 7, NEA is shooting at ab= out Layer 2. Frank... You actually mean layer 4 right? See TCP/IP was not designed o= n the ISO OSI model but rather prior to the ISO's Seven Layer OSI Model's= birth. FYEH: Enough with the history lessons already! First of all, I will concede that PA and PB are probably higher than layer 2. In fact using = the right PT options will allow applications to communicate over the networ= k without end-to-end TCP/IP connectivity. So the tunnel's endpoints are probably best described at Layer 5. The protocols that PT will ride probably end up with a layer 2 endpoint on the client end but that is outside of scope. However, didn't you say above that NEA working at Lay= er 2/3 was important? If you want to get into a discussion into legal aspects of compliance,= IBM has a few hundred lawyers who will engage and make sure that you never= get anything meaningful done ever again (trust me, I've been there). Actually - I formally presented IBM's General Counsel with a set of compliance questions, and they refused to answer or even acknowledge th= at they had been asked. I asked Lou Lupin, General Counsel of Qualcomm the= same Questions and Mark Chamber's, General Counsel of Cisco the same se= t. Cisco was the only one that answered the questions by the way, so again= Frank I disagree. FYEH: I am all about keeping the lawyers out of the network protocols. Without seeing the set of questions you presented it is pretty hard to comment on why IBM declined to comment or acknowledge but as I have indicated, we have too many lawyers who are basically paid to keep us o= ut of litigation. They are a bit nervous and protective by nature. They al= ways err on the side of safety. Allowing compliance and auditing mindsets to= drive technology is a dangerous thing IMHO. Todd Glassey Regards, Frank Yeh Sr. Security & Privacy Integration Architect IBM Global Technology Services Security & Privacy Technology Integration Team Second Life: Yehoo Newall Inactive hide details for "TS Glassey" "TS Glassey" = "TS Glassey" = = = = To 08/14/2007 = 05:53 PM "Alan DeKok" = = = = cc = nea@ietf.org = = Subj= ect = Re: [Nea] NEA = requirements and = internationalizati= on = = = = = = Alan - pardon the tone of this. Nothing personal is meant by these responses but AHAHAHAHAHAHAHAHAHAHAh -I haven't laughed that hard in a while... = Now that said - I am NOT against NEA just I want it to do more than what I= already have implemented with DHCP and several other tools including Tripwire. Otherwise its doomed in my estimation. Todd ----- Original Message ----- From: "Alan DeKok" To: "TS Glassey" Cc: "Stephen Hanna" ; Sent: Sunday, August 12, 2007 6:38 PM Subject: Re: [Nea] NEA requirements and internationalization > TS Glassey wrote: >>> MAY, rather than MUST. Many sites will have a site-wide configuration >>> saying "language used by everyone here." >> >> So then you are suggesting that as part of the entitlement-enableme= nt >> process that the client is interactively configured. > > MAY be interactively configured. Or, as many administrators do, th= > process may be scripted. scripting opens the system to security issues. It also enables many ty= pes of script driven attacks too. > >> What I am saying is that based on new requirements from the Courts = (as >> of May 4th 2007) in the US there are now five specific tests for ES= I >> (Electronicially Stored Information) into the Court's as evidence, = and >> what that means is that in any system that 'may produce content tha= t may >> come to be reviewed as evidence' will need to meet these new >> requirements. >> >> What that means to us, is that if we are designing technologies to = meet >> specific control requirements, there are now new constraints on tho= se >> systems which would come to be used in officia capacities. > > NEA is working on protocol level requirements and design. Logging,= > UI, and legal issues are (IMHO) out of scope. its a good thing its just an opinion... what I am talking about is wha= t is required to place technologies into SOX and other regulated entities, = and if the IETF doesnt want to deal with those then it should specifically sa= y that in the scope statement to elminate the issues of legal compliance requirements. The problem is that most techies here have no idea what the law is doi= ng to IT requirements and yet people continue to design technologies intentionally to fail to meet those requirements. The really funny thing to do is to= listen to the IT Manager try and talk their way out of being dinged by= the IT Auditor's for running unsecured and rediculously stupid code in the= ir system, and as it happens I think that NEA is the next one of these winners to come out of the IETF. The issues are simple - and that is if there is a desire to install a system that can pre-qualify the security compliance and platform configuratio= n compliance into the IT world then it needs to do so in concert with th= e Auditor's who will tell the IETF whether they are willing to put their= names and professional reputation/credentials on the line by using this prot= ocol as their recommendation. Otherwise why bother? > An NEA requirement that > systems MAY transport user-visible strings is fine. However, certai= n > implementations in certain jurisdictions MAY have additional > requirements on what is done with those strings. The EU Data Integrity "regulation" may not agree with you. > > If we design NEA for the lowest-common legal denominator, then we w= ill > have a system that does nothing. No - but that is the typical claim from techies who dont know what the= y are designing to. The problem with NEA is that there are regulatory requirements for this type of thing and the NEA WG wants to build something else th= at doesnt address those but claims to apparently. > >> That said, since there are new 'requirements' in operating official= >> systems, NEA should address those too... and that said, passing >> plain-text about is a no-no > > I'm a little at a loss to see how we can design an access protocol > that doesn't tell the user whether or not they've been granted acces= s, > or even if they've been denied. Uh simple - the users NIC can easily be used to tell them all kinds of= things including NO CONNECTION. > A list of canned status/error messages > isn't good enough, as experience has shown. > >>> I would like the ability for administrators to push messages to e= nd >>> users via NEA. This involves the *capability* to transport >>> internationalized strings in NEA. However, those strings are >>> informative to the end user, and opaque to the rest of NEA. >> >> So do a table of messages based on the entitlement models supported= and >> then publish UTF-8 strings of them in whatever language you want to= >> support. > > Can we enumerate *enough* possible messages to be useful? I doubt = it. Sure - a common set of messages is all that is necessary and simple UT= F-8 Encoding to make those transportable. > >>> I can understand this on the wide open net. For the chartered purpose >>> (enterprises), I don't see why it's a problem. >> >> Integrity of the Audit Process running inside the "Entity". Think = of >> your average University for instance. How many would-be hackers are= >> inside the Entity then. > > Charter. We have it. We should focus on it. Universities are out= of > scope. Issues with deploying NEA inside of Universities are out of > scope. If certain designs work in an enterprise, but not in a > university, then issues with the university deployment are irrelevan= t. > They are canards, and out of scope. Screw the Academic issues, as a professional auditor I believe that yo= u nor no one else here will install NEA in its current form in any regulated= networks period. I just wont fly with what you got now, whether you li= ke that or not, and whether you believe it or not... > >>> [ re: informational messages ] >>> No. They can be thrown away. Many PPP implementations have done= this >>> for years. It's annoying, but widely accepted practice. >> >> Depending what type of auditing and integrity of process model NEA = is to >> support. > > I'm not really sure what you mean by that. Informational messages > are... informational. They have little definitive meaning. Uhh is NEA a tool for qualifying systems prior to accessing the entity= resources? > > In contrast, messages like "you must upgrade now" are not > informational. They impose normative requirements on the user, and > should be logged, audited, etc. Agreed as should any status message from any transaction. > > Alan DeKok. _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea = --1__=07BBF9AADFC3516C8f9e8a93df938690918c07BBF9AADFC3516C Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Todd,

I am fine with not being in agreement.

We just have a different philosophy when it comes to how this should a= ll be approached.

More in line below, this round's comments tagged with FYEH:.

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>

          08/16/2007 07:25 AM

 =
3D=
To
3D""
Frank Yeh Jr/Irvine/IBM@IBMUS
3D=
cc
3D""
"Alan DeKok" <aland@deployingradius.com&g= t;, <nea@ietf.org>
3D=
Subject
3D""
Re: [Nea] NEA requirements and internationalization
3D=3D""

Sorry Frank, I disagree - more inline be= low...

----- Original Message -----
From: Frank Ye= h Jr
To: TS = Glassey
Cc: = Alan DeKok ; nea@ietf.org<= /u>
Sent: Wednesday, August= 15, 2007 9:33 PM
Subject: Re: [Nea] NEA = requirements and internationalization

Greetings,

Todd, based on your argument below, wouldn't we have to eliminate use o= f TCP/IP in all deployments affected by compliance auditing?

Not from my viewpoint. But the issue = is in creating systems which use what is available to accomplish those = requirements. So "No... IP can be audited" it just takes an = additional amount of overhead to do it.

FYEH: My point is that TCP/IP was not= designed for existence in a compliance and auditing driven environment= and yet we contiunue to use it today and will continue to do so into t= he future. Your observations about its history bear this out. We are no= t going to eliminate TCP/IP soon, so we are stuck with it and so is the= audit community. Do you realistically think we can replace TCP/IP with= something the auditers are comfortable with? How do we do that? Turn o= ff the internet for a maintenance upgrade? Can we work that into the IP= v6 cutover?

XNS by comparison, and even OSX/SPX w= ere better protocols for that type of thing. And remember what TCP/IP w= as designed to do. Its a demonstration protocol built under contract to= ARPA by BB&N to facilitate the operations of the Air Force's data = exchange network with military and academic institutions. It (TCP/IP) w= as never built to be secured or audited in the sense of something say l= ike the services provided electronically from the Federal Reserve Bank = or like entities. And YES Frank I still have one of Stanford's old Honn= ywell H316 IMP's in my garage so...

FYEH: LOL! DUDE! It's time to move on= ! IBM has stopped investing in Token Ring and SNA even though they offe= red a host of advantages over ethernet and IP. The fact that you actual= ly have the honeywell taking up space in your garage is a bit scary! Do= nate it to a museum and share this bit of history with the public.

By the way - inside the DoD and intel= ligence Community, CIPR and NIPR net's replaced the ARPA Net for secure= d communications so formally the US Military itself DOESNT rely on publ= icly routed TCP/IP like the rest of us do...

FYEH: CIPRnet and NIPRnet are both acronyms that in= clude IPR which stands for Internet Protocol Routers!!! CIPRNet is defi= nitely not publicy routed, NIPRNet is part of the publicly routed netwo= rk, with access to many of the .mil domains being routed through it, bu= t this is a complete non-sequiter. How you design a protocol and how pe= ople use it should not be confused. The fact that CIPRNet depends on ph= yscial separation probably lends credence o the fact that TCP/IP is not= designed for security or audit but that is a unique case. The rest of = us need to operate in the real world.

Compliance does not have to be built into the network protocols, nor wo= uld it be wise to try to do this.

Boy is that a broken statement. Sorry= Frank you ARE wrong here - and that is part of the problem with why th= e Audit Community is estranged from this Standards Body. Compliance wit= h regulatory requirements happens at ALL levels and that is simply that= . The problem with layering compliance on the Application Layer is that= it requires a fully-functional station prior to compliance being deter= mined. Which is why NEA's working at Layer-2/3 is so important. Applica= tion Layer certification means that the OS is already up and running on= the client-node and that means that prior to its being authorized to p= articipate in that network's operations it is already a threat to the i= ntegrity of the system...

And yes - we can thank the design of = IP for that.

FYEH: I will agree to disagree on thi= s if you will. IMHO YOU are wrong!!! ;-P I understand what you want at = a philosophical level, but if we tried to build what you desire, we wou= ld never be done. You just can't build everything into a single protoco= l. We DEPEND on separation at different layers and interafces between t= hem. These are what the protocols do. You are right that with this segm= entation, we have to prove compliance at a number of different levels, = but this is NOT what NEA is intended to do. It will be used to provide = a reasonably secure way for clients and servers of applications that no= rmally work at layer 7 to communicate at layer 2 to establish some leve= l of trust before allowing the network to provide Layer 3 conntectivity= . When you look at the TCG model, there is a whole set of protocols an= d practices external to TNC (their version of what NEA is trying to sta= ndardize) to provide a trusted stack with compliance proven at every le= vel and based on a hardware root of trust.

Compliance is something that happens at Layer 7, NE= A is shooting at about Layer 2.

Frank... You actually mean layer 4 ri= ght? See TCP/IP was not designed on the ISO OSI model but rather prior = to the ISO's Seven Layer OSI Model's birth.

FYEH: Enough with the history lessons= already! First of all, I will concede that PA and PB are probably hig= her than layer 2. In fact using the right PT options will allow applica= tions to communicate over the network without end-to-end TCP/IP connect= ivity. So the tunnel's endpoints are probably best described at Layer 5= . The protocols that PT will ride probably end up with a layer 2 endpoi= nt on the client end but that is outside of scope. However, didn't you = say above that NEA working at Layer 2/3 was important?

If you want to get into a discussion into legal asp= ects of compliance, IBM has a few hundred lawyers who will engage and m= ake sure that you never get anything meaningful done ever again (trust = me, I've been there).

Actually - I formally presented IBM's= General Counsel with a set of compliance questions, and they refused t= o answer or even acknowledge that they had been asked. I asked Lou Lupi= n, General Counsel of Qualcomm the same Questions and Mark Chamber's, G= eneral Counsel of Cisco the same set. Cisco was the only one that answe= red the questions by the way, so again Frank I disagree.

FYEH: I am all about keeping the lawy= ers out of the network protocols. Without seeing the set of questions y= ou presented it is pretty hard to comment on why IBM declined to commen= t or acknowledge but as I have indicated, we have too many lawyers who = are basically paid to keep us out of litigation. They are a bit nervous= and protective by nature. They always err on the side of safety. Allow= ing compliance and auditing mindsets to drive technology is a dangerous= thing IMHO.

Todd Glassey




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

Second Life: Yehoo Newall

3D"Inactive"TS G= lassey" <tglassey@earthlink.net>

=
                  "TS Glassey" <tglassey@earthlink.net>

                  08/14/2007 05:53 PM

 =
To

"Alan DeKok" <aland@deployingradius.com>
cc

nea@ietf.org
Subject

Re: [Nea] NEA requirements and internationalization
=

Alan - pardon the tone of this. Nothing personal is meant by these resp= onses
but AHAHAHAHAHAHAHAHAHAHAh -I haven't laughed that hard in a while... N= ow
that said - I am NOT against NEA just I want it to do more than what I =
already have implemented with DHCP and several other tools including Tripwire. Otherwise its doomed in my estimation.

Todd
----- Original Message -----
From: "Alan DeKok" <aland@deployingradius.com>
To: "TS Glassey" <tglassey@earthlink.net>
Cc: "Stephen Hanna" <shanna@juniper.net>; <nea@ietf.= org>
Sent: Sunday, August 12, 2007 6:38 PM
Subject: Re: [Nea] NEA requirements and internationalization


> TS Glassey wrote:
>>>  MAY, rather than MUST.  Many sites will have a = site-wide configuration
>>> saying "language used by everyone here."
>>
>> So then you are suggesting that as part of the entitlement-ena= blement
>> process that the client is interactively configured.
>
>  MAY be interactively configured.  Or, as many administr= ators do, th
> process may be scripted.

scripting opens the system to security issues. It also enables many typ= es of
script driven attacks too.

>
>> What I am saying is that based on new requirements from the Co= urts (as
>> of May 4th 2007) in the US there are now five specific tests f= or ESI
>> (Electronicially Stored Information) into the Court's as evide= nce, and
>> what that means is that in any system that 'may produce conten= t that may
>> come to be reviewed as evidence' will need to meet these new <= br> >> requirements.
>>
>> What that means to us, is that if we are designing technologie= s to meet
>> specific control requirements, there are now new constraints o= n those
>> systems which would come to be used in officia capacities.
= >
>  NEA is working on protocol level requirements and design. &n= bsp;Logging,
> UI, and legal issues are (IMHO) out of scope.

its a good thing its just an opinion... what I am talking about is what= is
required to place technologies into SOX and other regulated entities, a= nd if
the IETF doesnt want to deal with those then it should specifically say= that
in the scope statement to elminate the issues of legal compliance
requirements.

The problem is that most techies here have no idea what the law is doin= g to
IT requirements and yet people continue to design technologies intentio= nally
to fail to meet those requirements. The really funny thing to do is to =
listen to the IT Manager try and talk their way out of being dinged by = the
IT Auditor's for running unsecured and rediculously stupid code in thei= r
system, and as it happens I think that NEA is the next one of these win= ners
to come out of the IETF.

The issues are simple - and that is if there is a desire to install a s= ystem
that can pre-qualify the security compliance and platform configuration=
compliance into the IT world then it needs to do so in concert with the=
Auditor's who will tell the IETF whether they are willing to put their = names
and professional reputation/credentials on the line by using this proto= col
as  their recommendation. Otherwise why bother?

> An NEA requirement that
> systems MAY transport user-visible strings is fine.  However,= certain
> implementations in certain jurisdictions MAY have additional
> requirements on what is done with those strings.

The EU Data Integrity "regulation" may not agree with you.
>
>  If we design NEA for the lowest-common legal denominator, th= en we will
> have a system that does nothing.

No - but that is the typical claim from techies who dont know what they= are
designing to. The problem with NEA is that there are regulatory require= ments
for this type of thing and the NEA WG wants to build something else tha= t
doesnt address those but claims to apparently.

>
>> That said, since there are new 'requirements' in operating off= icial
>> systems, NEA should address those too... and that said, passin= g
>> plain-text about is a no-no
>
>  I'm a little at a loss to see how we can design an access pr= otocol
> that doesn't tell the user whether or not they've been granted acc= ess,
> or even if they've been denied.

Uh simple - the users NIC can easily be used to tell them all kinds of =
things including NO CONNECTION.

> A list of canned status/error messages
> isn't good enough, as experience has shown.
>
>>>  I would like the ability for administrators to push = messages to end
>>> users via NEA.  This involves the *capability* to tra= nsport
>>> internationalized strings in NEA.  However, those str= ings are
>>> informative to the end user, and opaque to the rest of NEA= .
>>
>> So do a table of messages based on the entitlement models supp= orted and
>> then publish UTF-8 strings of them in whatever language you wa= nt to
>> support.
>
>  Can we enumerate *enough* possible messages to be useful? &n= bsp;I doubt it.

Sure - a common set of messages is all that is necessary and simple UTF= -8
Encoding to make those transportable.

>
>>>  I can understand this on the wide open net.  Fo= r the chartered purpose
>>> (enterprises), I don't see why it's a problem.
>>
>> Integrity of the Audit Process running inside the "Entity= ".  Think of
>> your average University for instance. How many would-be hacker= s are
>> inside the Entity then.
>
>  Charter.  We have it.  We should focus on it. &nbs= p;Universities are out of
> scope.  Issues with deploying NEA inside of Universities are = out of
> scope.  If certain designs work in an enterprise, but not in = a
> university, then issues with the university deployment are irrelev= ant.
> They are canards, and out of scope.

Screw the Academic issues, as a professional auditor I believe that you= nor
no one else here will install NEA in its current form in any regulated =
networks period. I just wont fly with what you got now, whether you lik= e
that or not, and whether you believe it or not...

>
>>> [ re: informational messages ]
>>>  No.  They can be thrown away.  Many PPP im= plementations have done this
>>> for years.  It's annoying, but widely accepted practi= ce.
>>
>> Depending what type of auditing and integrity of process model= NEA is to
>> support.
>
>  I'm not really sure what you mean by that.  Information= al messages
> are... informational.  They have little definitive meaning.
Uhh is NEA a tool for qualifying systems prior to accessing the entity =
resources?

>
>  In contrast, messages like "you must upgrade now" = are not
> informational.  They impose normative requirements on the use= r, and
> should be logged, audited, etc.

Agreed as should any status message from any transaction.

>
>  Alan DeKok.



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

= --1__=07BBF9AADFC3516C8f9e8a93df938690918c07BBF9AADFC3516C-- --0__=07BBF9AADFC3516C8f9e8a93df938690918c07BBF9AADFC3516C Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=07BBF9AADFC3516C8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=07BBF9AADFC3516C8f9e8a93df938690918c07BBF9AADFC3516C Content-type: image/gif; name="pic23158.gif" Content-Disposition: inline; filename="pic23158.gif" Content-ID: <2__=07BBF9AADFC3516C8f9e8a93df938@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__=07BBF9AADFC3516C8f9e8a93df938690918c07BBF9AADFC3516C Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <3__=07BBF9AADFC3516C8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=07BBF9AADFC3516C8f9e8a93df938690918c07BBF9AADFC3516C Content-type: image/gif; name="28926514.gif" Content-Disposition: inline; filename="28926514.gif" Content-ID: <4__=07BBF9AADFC3516C8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=07BBF9AADFC3516C8f9e8a93df938690918c07BBF9AADFC3516C Content-type: image/gif; name="28384070.gif" Content-Disposition: inline; filename="28384070.gif" Content-ID: <5__=07BBF9AADFC3516C8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=07BBF9AADFC3516C8f9e8a93df938690918c07BBF9AADFC3516C-- --===============2010104989== 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 --===============2010104989==-- From nea-bounces@ietf.org Thu Aug 16 13:48: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 1ILjRw-0007Cv-0l; Thu, 16 Aug 2007 13:48:00 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1ILiGf-0007Z2-6U for nea-confirm+ok@megatron.ietf.org; Thu, 16 Aug 2007 12:32:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILiGe-0007Yu-Sr for nea@ietf.org; Thu, 16 Aug 2007 12:32:16 -0400 Received: from elasmtp-banded.atl.sa.earthlink.net ([209.86.89.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILiGc-0003Ia-RE for nea@ietf.org; Thu, 16 Aug 2007 12:32:16 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=O20Y5LyGS6dlnXysvhS9xxVc78GNYuqqFqvxk19G+tWwC0eVbFHdLy1lYseiywdl; 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 1ILiGT-0003Gs-8n; Thu, 16 Aug 2007 12:32:05 -0400 Message-ID: <012801c7e022$fd69d5b0$174f7d40@home.glassey.com> From: "todd glassey" To: "Frank Yeh Jr" References: Subject: Re: [Nea] NEA requirements and internationalization Date: Thu, 16 Aug 2007 09:24:46 -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: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79d1dba9e70e30bedd6f2c1529f76a2086350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 64.125.79.23 X-Spam-Score: 1.0 (+) X-Scan-Signature: b43eaa29978e81774503cbe9ddd3bf8a X-Mailman-Approved-At: Thu, 16 Aug 2007 13:47:58 -0400 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0129024714==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============0129024714== Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0118_01C7DFE7.49547660" This is a multi-part message in MIME format. ------=_NextPart_000_0118_01C7DFE7.49547660 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0119_01C7DFE7.49547660" ------=_NextPart_001_0119_01C7DFE7.49547660 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Frank, Cool - everyone is entailed to an opinion. Mine is of a certified = auditor; so I am not just blowing smoke when I tell you that without = certain concessions to integrity and its ongoing demonstration, NEA = probably wont see the light of day in commercial networks; This claim is = based on what we have had to do to document compliance with PCAOB's AS-2 = and then later AS-4 and AS-5 standards for Auditing.=20 It (my opinion) is also based on what those customers have already paid = to their internal and external auditor's to certify what they already = have in place... so why would they want to make that expense something = that they redo again and again everytime there is a new NEA release or = standards specification? - their shareholders will kill them. Their = stakeholders will also say "no" too IMHO based on the continuously = increasing overhead. NEA has real possibilities as a base-line compliance messaging service = and that's its real value in the commercial world, whether the consensus = here in this WG says the same or not. This is not about standards and = the creation thereof its about what the Industry needs for its = operations and the compliance hurdles facing every major network = operator on the Globe today. That all said - my position is the same. = That being the above and that I feel that NEA's key value is then in = several of the things specifically noted as 'outside NEA's Scope'...=20 Todd's 2 Cents (as a private citizen, but one with CISM and CIFI = auditing credentials) ----- Original Message -----=20 From: Frank Yeh Jr=20 To: todd glassey=20 Cc: Alan DeKok ; nea@ietf.org=20 Sent: Thursday, August 16, 2007 8:40 AM Subject: Re: [Nea] NEA requirements and internationalization Todd, I am fine with not being in agreement. We just have a different philosophy when it comes to how this should = all be approached. More in line below, this round's comments tagged with FYEH:. Regards, Frank Yeh Sr. Security & Privacy Integration Architect IBM Global Technology Services Security & Privacy Technology Integration Team Second Life: Yehoo Newall "todd glassey" "todd glassey" =20 08/16/2007 07:25 AM =20 To=20 Frank Yeh Jr/Irvine/IBM@IBMUS=20 cc=20 "Alan DeKok" , =20 Subject=20 Re: [Nea] NEA requirements and internationalization=20 =20 =20 Sorry Frank, I disagree - more inline below...=20 ----- Original Message -----=20 From: Frank Yeh Jr=20 To: TS Glassey=20 Cc: Alan DeKok ; nea@ietf.org=20 Sent: Wednesday, August 15, 2007 9:33 PM Subject: Re: [Nea] NEA requirements and internationalization Greetings, Todd, based on your argument below, wouldn't we have to eliminate use = of TCP/IP in all deployments affected by compliance auditing?=20 Not from my viewpoint. But the issue is in creating systems which use = what is available to accomplish those requirements. So "No... IP can be = audited" it just takes an additional amount of overhead to do it.=20 FYEH: My point is that TCP/IP was not designed for existence in a = compliance and auditing driven environment and yet we contiunue to use = it today and will continue to do so into the future. Your observations = about its history bear this out. We are not going to eliminate TCP/IP = soon, so we are stuck with it and so is the audit community. Do you = realistically think we can replace TCP/IP with something the auditers = are comfortable with? How do we do that? Turn off the internet for a = maintenance upgrade? Can we work that into the IPv6 cutover?=20 XNS by comparison, and even OSX/SPX were better protocols for that = type of thing. And remember what TCP/IP was designed to do. Its a = demonstration protocol built under contract to ARPA by BB&N to = facilitate the operations of the Air Force's data exchange network with = military and academic institutions. It (TCP/IP) was never built to be = secured or audited in the sense of something say like the services = provided electronically from the Federal Reserve Bank or like entities. = And YES Frank I still have one of Stanford's old Honnywell H316 IMP's in = my garage so...=20 FYEH: LOL! DUDE! It's time to move on! IBM has stopped investing in = Token Ring and SNA even though they offered a host of advantages over = ethernet and IP. The fact that you actually have the honeywell taking up = space in your garage is a bit scary! Donate it to a museum and share = this bit of history with the public.=20 By the way - inside the DoD and intelligence Community, CIPR and NIPR = net's replaced the ARPA Net for secured communications so formally the = US Military itself DOESNT rely on publicly routed TCP/IP like the rest = of us do...=20 FYEH: CIPRnet and NIPRnet are both acronyms that include IPR which = stands for Internet Protocol Routers!!! CIPRNet is definitely not = publicy routed, NIPRNet is part of the publicly routed network, with = access to many of the .mil domains being routed through it, but this is = a complete non-sequiter. How you design a protocol and how people use it = should not be confused. The fact that CIPRNet depends on physcial = separation probably lends credence o the fact that TCP/IP is not = designed for security or audit but that is a unique case. The rest of us = need to operate in the real world.=20 Compliance does not have to be built into the network protocols, nor = would it be wise to try to do this.=20 Boy is that a broken statement. Sorry Frank you ARE wrong here - and = that is part of the problem with why the Audit Community is estranged = from this Standards Body. Compliance with regulatory requirements = happens at ALL levels and that is simply that. The problem with layering = compliance on the Application Layer is that it requires a = fully-functional station prior to compliance being determined. Which is = why NEA's working at Layer-2/3 is so important. Application Layer = certification means that the OS is already up and running on the = client-node and that means that prior to its being authorized to = participate in that network's operations it is already a threat to the = integrity of the system...=20 And yes - we can thank the design of IP for that.=20 FYEH: I will agree to disagree on this if you will. IMHO YOU are = wrong!!! ;-P I understand what you want at a philosophical level, but if = we tried to build what you desire, we would never be done. You just = can't build everything into a single protocol. We DEPEND on separation = at different layers and interafces between them. These are what the = protocols do. You are right that with this segmentation, we have to = prove compliance at a number of different levels, but this is NOT what = NEA is intended to do. It will be used to provide a reasonably secure = way for clients and servers of applications that normally work at layer = 7 to communicate at layer 2 to establish some level of trust before = allowing the network to provide Layer 3 conntectivity. When you look at = the TCG model, there is a whole set of protocols and practices external = to TNC (their version of what NEA is trying to standardize) to provide a = trusted stack with compliance proven at every level and based on a = hardware root of trust.=20 Compliance is something that happens at Layer 7, NEA is shooting at = about Layer 2.=20 Frank... You actually mean layer 4 right? See TCP/IP was not designed = on the ISO OSI model but rather prior to the ISO's Seven Layer OSI = Model's birth.=20 FYEH: Enough with the history lessons already! First of all, I will = concede that PA and PB are probably higher than layer 2. In fact using = the right PT options will allow applications to communicate over the = network without end-to-end TCP/IP connectivity. So the tunnel's = endpoints are probably best described at Layer 5. The protocols that PT = will ride probably end up with a layer 2 endpoint on the client end but = that is outside of scope. However, didn't you say above that NEA working = at Layer 2/3 was important?=20 If you want to get into a discussion into legal aspects of compliance, = IBM has a few hundred lawyers who will engage and make sure that you = never get anything meaningful done ever again (trust me, I've been = there).=20 Actually - I formally presented IBM's General Counsel with a set of = compliance questions, and they refused to answer or even acknowledge = that they had been asked. I asked Lou Lupin, General Counsel of Qualcomm = the same Questions and Mark Chamber's, General Counsel of Cisco the same = set. Cisco was the only one that answered the questions by the way, so = again Frank I disagree.=20 FYEH: I am all about keeping the lawyers out of the network protocols. = Without seeing the set of questions you presented it is pretty hard to = comment on why IBM declined to comment or acknowledge but as I have = indicated, we have too many lawyers who are basically paid to keep us = out of litigation. They are a bit nervous and protective by nature. They = always err on the side of safety. Allowing compliance and auditing = mindsets to drive technology is a dangerous thing IMHO.=20 Todd Glassey=20 Regards, Frank Yeh Sr. Security & Privacy Integration Architect IBM Global Technology Services Security & Privacy Technology Integration Team Second Life: Yehoo Newall "TS Glassey" "TS Glassey" =20 08/14/2007 05:53 PM =20 To=20 "Alan DeKok" =20 cc=20 nea@ietf.org=20 Subject=20 Re: [Nea] NEA requirements and internationalization=20 =20 =20 Alan - pardon the tone of this. Nothing personal is meant by these = responses=20 but AHAHAHAHAHAHAHAHAHAHAh -I haven't laughed that hard in a while... = Now=20 that said - I am NOT against NEA just I want it to do more than what I = already have implemented with DHCP and several other tools including=20 Tripwire. Otherwise its doomed in my estimation. Todd ----- Original Message -----=20 From: "Alan DeKok" To: "TS Glassey" Cc: "Stephen Hanna" ; Sent: Sunday, August 12, 2007 6:38 PM Subject: Re: [Nea] NEA requirements and internationalization > TS Glassey wrote: >>> MAY, rather than MUST. Many sites will have a site-wide = configuration >>> saying "language used by everyone here." >> >> So then you are suggesting that as part of the = entitlement-enablement >> process that the client is interactively configured. > > MAY be interactively configured. Or, as many administrators do, th > process may be scripted. scripting opens the system to security issues. It also enables many = types of=20 script driven attacks too. > >> What I am saying is that based on new requirements from the Courts = (as >> of May 4th 2007) in the US there are now five specific tests for = ESI >> (Electronicially Stored Information) into the Court's as evidence, = and >> what that means is that in any system that 'may produce content = that may >> come to be reviewed as evidence' will need to meet these new=20 >> requirements. >> >> What that means to us, is that if we are designing technologies to = meet >> specific control requirements, there are now new constraints on = those >> systems which would come to be used in officia capacities. > > NEA is working on protocol level requirements and design. Logging, > UI, and legal issues are (IMHO) out of scope. its a good thing its just an opinion... what I am talking about is = what is=20 required to place technologies into SOX and other regulated entities, = and if=20 the IETF doesnt want to deal with those then it should specifically = say that=20 in the scope statement to elminate the issues of legal compliance=20 requirements. The problem is that most techies here have no idea what the law is = doing to=20 IT requirements and yet people continue to design technologies = intentionally=20 to fail to meet those requirements. The really funny thing to do is to = listen to the IT Manager try and talk their way out of being dinged by = the=20 IT Auditor's for running unsecured and rediculously stupid code in = their=20 system, and as it happens I think that NEA is the next one of these = winners=20 to come out of the IETF. The issues are simple - and that is if there is a desire to install a = system=20 that can pre-qualify the security compliance and platform = configuration=20 compliance into the IT world then it needs to do so in concert with = the=20 Auditor's who will tell the IETF whether they are willing to put their = names=20 and professional reputation/credentials on the line by using this = protocol=20 as their recommendation. Otherwise why bother? > An NEA requirement that > systems MAY transport user-visible strings is fine. However, = certain > implementations in certain jurisdictions MAY have additional > requirements on what is done with those strings. The EU Data Integrity "regulation" may not agree with you. > > If we design NEA for the lowest-common legal denominator, then we = will > have a system that does nothing. No - but that is the typical claim from techies who dont know what = they are=20 designing to. The problem with NEA is that there are regulatory = requirements=20 for this type of thing and the NEA WG wants to build something else = that=20 doesnt address those but claims to apparently. > >> That said, since there are new 'requirements' in operating official >> systems, NEA should address those too... and that said, passing >> plain-text about is a no-no > > I'm a little at a loss to see how we can design an access protocol > that doesn't tell the user whether or not they've been granted = access, > or even if they've been denied. Uh simple - the users NIC can easily be used to tell them all kinds of = things including NO CONNECTION. > A list of canned status/error messages > isn't good enough, as experience has shown. > >>> I would like the ability for administrators to push messages to = end >>> users via NEA. This involves the *capability* to transport >>> internationalized strings in NEA. However, those strings are >>> informative to the end user, and opaque to the rest of NEA. >> >> So do a table of messages based on the entitlement models supported = and >> then publish UTF-8 strings of them in whatever language you want to >> support. > > Can we enumerate *enough* possible messages to be useful? I doubt = it. Sure - a common set of messages is all that is necessary and simple = UTF-8=20 Encoding to make those transportable. > >>> I can understand this on the wide open net. For the chartered = purpose >>> (enterprises), I don't see why it's a problem. >> >> Integrity of the Audit Process running inside the "Entity". Think = of >> your average University for instance. How many would-be hackers are >> inside the Entity then. > > Charter. We have it. We should focus on it. Universities are out = of > scope. Issues with deploying NEA inside of Universities are out of > scope. If certain designs work in an enterprise, but not in a > university, then issues with the university deployment are = irrelevant. > They are canards, and out of scope. Screw the Academic issues, as a professional auditor I believe that = you nor=20 no one else here will install NEA in its current form in any regulated = networks period. I just wont fly with what you got now, whether you = like=20 that or not, and whether you believe it or not... > >>> [ re: informational messages ] >>> No. They can be thrown away. Many PPP implementations have done = this >>> for years. It's annoying, but widely accepted practice. >> >> Depending what type of auditing and integrity of process model NEA = is to >> support. > > I'm not really sure what you mean by that. Informational messages > are... informational. They have little definitive meaning. Uhh is NEA a tool for qualifying systems prior to accessing the entity = resources? > > In contrast, messages like "you must upgrade now" are not > informational. They impose normative requirements on the user, and > should be logged, audited, etc. Agreed as should any status message from any transaction. > > Alan DeKok.=20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea ------=_NextPart_001_0119_01C7DFE7.49547660 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Frank,
Cool - everyone is entailed = to an=20 opinion. Mine is of a certified auditor; so I am not just blowing smoke when I tell you that without = certain=20 concessions to integrity and its ongoing demonstration, NEA probably = wont see=20 the light of day in commercial networks; This claim is based on what we have had to do to document = compliance=20 with PCAOB's AS-2 and then later AS-4 and AS-5 standards for Auditing.=20
 
It (my opinion)  is = also based on=20 what those customers have already paid to their internal and external = auditor's=20 to certify what they already have in place... so why would they want to = make=20 that expense something that they redo again and again everytime there is = a new=20 NEA release or standards specification? - their shareholders will kill = them.=20 Their stakeholders will also say "no" too IMHO based on the continuously = increasing overhead.
 
NEA has real possibilities = as a=20 base-line compliance messaging service and that's its real value in the=20 commercial world, whether the consensus here in this WG says the same or = not.=20 This is not about standards and the creation thereof its about what the = Industry=20 needs for its operations and the compliance hurdles facing every major = network=20 operator on the Globe today. That all said - my position is the same. = That being=20 the above and that I feel that NEA's key value is then in several of the = things=20 specifically noted as 'outside NEA's Scope'...
 
Todd's 2 Cents (as a = private=20 citizen, but one with CISM and CIFI auditing = credentials)
----- Original Message -----
From:=20 Frank Yeh = Jr
Sent: Thursday, August 16, 2007 = 8:40=20 AM
Subject: Re: [Nea] NEA = requirements and=20 internationalization

Todd,

I am fine with not being in agreement.

We just = have a=20 different philosophy when it comes to how this should all be=20 approached.

More in line below, this round's comments tagged = with=20 FYEH:.

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

Second Life: Yehoo = Newall

'=20 src=3D"cid:011401c7e021$f5a4f680$174f7d40@home.glassey.com" width=3D16 = border=3D0>"todd glassey" <tglassey@earthlink.net>
=

          "todd glassey" <tglassey@earthlink.net>

          08/16/2007 07:25 = AM

3D""=20
To
 3D""=20
Frank Yeh=20 Jr/Irvine/IBM@IBMUS
3D""=20
cc
 3D""=20
"Alan DeKok"=20 <aland@deployingradius.com>,=20 <nea@ietf.org>
3D""=20
Subject
 3D""=20
Re: [Nea] NEA requirements = and=20 internationalization
3D""=20 3D""=20

Sorry Frank, I disagree - more inline = below...=20

----- Original = Message -----=20
From: Frank Yeh=20 Jr
To: TS Glassey
Cc: Alan=20 DeKok ; nea@ietf.org =
Sent: Wednesday, August 15, 2007 = 9:33=20 PM
Subject: Re: = [Nea] NEA=20 requirements and internationalization

Greetings,

Todd, based on your argument = below, wouldn't=20 we have to eliminate use of TCP/IP in all deployments affected by = compliance=20 auditing?=20

Not from my viewpoint. But the issue = is in=20 creating systems which use what is available to accomplish those = requirements.=20 So "No... IP can be audited" it just takes an additional amount of = overhead to=20 do it.

FYEH: My point is that TCP/IP was = not designed=20 for existence in a compliance and auditing driven environment and yet = we=20 contiunue to use it today and will continue to do so into the future. = Your=20 observations about its history bear this out. We are not going to = eliminate=20 TCP/IP soon, so we are stuck with it and so is the audit community. Do = you=20 realistically think we can replace TCP/IP with something the auditers = are=20 comfortable with? How do we do that? Turn off the internet for a = maintenance=20 upgrade? Can we work that into the IPv6 cutover?=20

XNS by comparison, and even OSX/SPX = were=20 better protocols for that type of thing. And remember what TCP/IP was = designed=20 to do. Its a demonstration protocol built under contract to ARPA by = BB&N=20 to facilitate the operations of the Air Force's data exchange network = with=20 military and academic institutions. It (TCP/IP) was never built to be = secured=20 or audited in the sense of something say like the services provided=20 electronically from the Federal Reserve Bank or like entities. And YES = Frank I=20 still have one of Stanford's old Honnywell H316 IMP's in my garage = so...=20

FYEH: LOL! DUDE! It's time to move = on! IBM has=20 stopped investing in Token Ring and SNA even though they offered a = host of=20 advantages over ethernet and IP. The fact that you actually have the = honeywell=20 taking up space in your garage is a bit scary! Donate it to a museum = and share=20 this bit of history with the public.=20

By the way - inside the DoD and = intelligence=20 Community, CIPR and NIPR net's replaced the ARPA Net for secured=20 communications so formally the US Military itself DOESNT rely on = publicly=20 routed TCP/IP like the rest of us do...=20

FYEH: CIPRnet and NIPRnet are both acronyms that = include IPR=20 which stands for Internet Protocol Routers!!! CIPRNet is definitely = not=20 publicy routed, NIPRNet is part of the publicly routed network, with = access to=20 many of the .mil domains being routed through it, but this is a = complete=20 non-sequiter. How you design a protocol and how people use it should = not be=20 confused. The fact that CIPRNet depends on physcial separation = probably lends=20 credence o the fact that TCP/IP is not designed for security or audit = but that=20 is a unique case. The rest of us need to operate in the real world.=20

Compliance does not have to be built into the network = protocols, nor=20 would it be wise to try to do this.

Boy is that a broken statement. = Sorry Frank=20 you ARE wrong here - and that is part of the problem with why the = Audit=20 Community is estranged from this Standards Body. Compliance with = regulatory=20 requirements happens at ALL levels and that is simply that. The = problem with=20 layering compliance on the Application Layer is that it requires a=20 fully-functional station prior to compliance being determined. Which = is why=20 NEA's working at Layer-2/3 is so important. Application Layer = certification=20 means that the OS is already up and running on the client-node and = that means=20 that prior to its being authorized to participate in that network's = operations=20 it is already a threat to the integrity of the system...=20

And yes - we can thank the design of = IP for=20 that.=20

FYEH: I will agree to disagree on = this if you=20 will. IMHO YOU are wrong!!! ;-P I understand what you want at a = philosophical=20 level, but if we tried to build what you desire, we would never be = done. You=20 just can't build everything into a single protocol. We DEPEND on = separation at=20 different layers and interafces between them. These are what the = protocols do.=20 You are right that with this segmentation, we have to prove compliance = at a=20 number of different levels, but this is NOT what NEA is intended to = do. It=20 will be used to provide a reasonably secure way for clients and = servers of=20 applications that normally work at layer 7 to communicate at layer 2 = to=20 establish some level of trust before allowing the network to provide = Layer 3=20 conntectivity. When you look at the TCG model, there is a whole set of = protocols and practices external to TNC (their version of what NEA is = trying=20 to standardize) to provide a trusted stack with compliance proven at = every=20 level and based on a hardware root of trust.=20

Compliance is something that happens at Layer 7, NEA = is=20 shooting at about Layer 2.=20

Frank... You actually mean layer 4 = right? See=20 TCP/IP was not designed on the ISO OSI model but rather prior to the = ISO's=20 Seven Layer OSI Model's birth.=20

FYEH: Enough with the history = lessons already!=20 First of all, I will concede that PA and PB are probably higher than = layer 2.=20 In fact using the right PT options will allow applications to = communicate over=20 the network without end-to-end TCP/IP connectivity. So the tunnel's = endpoints=20 are probably best described at Layer 5. The protocols that PT will = ride=20 probably end up with a layer 2 endpoint on the client end but that is = outside=20 of scope. However, didn't you say above that NEA working at Layer 2/3 = was=20 important?

If you want to get into a discussion into legal = aspects of=20 compliance, IBM has a few hundred lawyers who will engage and make = sure that=20 you never get anything meaningful done ever again (trust me, I've been = there).=20

Actually - I formally presented = IBM's General=20 Counsel with a set of compliance questions, and they refused to answer = or even=20 acknowledge that they had been asked. I asked Lou Lupin, General = Counsel of=20 Qualcomm the same Questions and Mark Chamber's, General Counsel of = Cisco the=20 same set. Cisco was the only one that answered the questions by the = way, so=20 again Frank I disagree.

FYEH: I am all about keeping the = lawyers out=20 of the network protocols. Without seeing the set of questions you = presented it=20 is pretty hard to comment on why IBM declined to comment or = acknowledge but as=20 I have indicated, we have too many lawyers who are basically paid to = keep us=20 out of litigation. They are a bit nervous and protective by nature. = They=20 always err on the side of safety. Allowing compliance and auditing = mindsets to=20 drive technology is a dangerous thing IMHO.=20

Todd Glassey=20




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

Second Life: Yehoo=20 Newall

3D'Inactive'=20 src=3D"cid:011601c7e021$f5a4f680$174f7d40@home.glassey.com" = width=3D16>"TS Glassey" <tglassey@earthlink.net>

                  "TS Glassey" = <tglassey@earthlink.net>=20

                  08/14/2007 05:53 = PM
To
"Alan DeKok" = <aland@deployingradius.com>
cc
nea@ietf.org
Subject
Re: [Nea] NEA requirements and=20 internationalization

Alan - pardon the tone of this. Nothing personal is meant = by these=20 responses
but AHAHAHAHAHAHAHAHAHAHAh -I haven't laughed that hard = in a=20 while... Now
that said - I am NOT against NEA just I want it to do = more=20 than what I
already have implemented with DHCP and several other = tools=20 including
Tripwire. Otherwise its doomed in my=20 estimation.

Todd
----- Original Message -----
From: = "Alan DeKok"=20 <aland@deployingradius.com>
To: "TS Glassey"=20 <tglassey@earthlink.net>
Cc: "Stephen Hanna"=20 <shanna@juniper.net>; <nea@ietf.org>
Sent: Sunday, = August 12,=20 2007 6:38 PM
Subject: Re: [Nea] NEA requirements and=20 internationalization


> TS Glassey wrote:
>>> =  MAY, rather than MUST.  Many sites will have a site-wide=20 configuration
>>> saying "language used by everyone=20 here."
>>
>> So then you are suggesting that as part = of the=20 entitlement-enablement
>> process that the client is = interactively=20 configured.
>
>  MAY be interactively configured. =  Or,=20 as many administrators do, th
> process may be=20 scripted.

scripting opens the system to security issues. It = also=20 enables many types of
script driven attacks = too.

>
>>=20 What I am saying is that based on new requirements from the Courts=20 (as
>> of May 4th 2007) in the US there are now five specific = tests=20 for ESI
>> (Electronicially Stored Information) into the = Court's as=20 evidence, and
>> what that means is that in any system that = 'may=20 produce content that may
>> come to be reviewed as evidence' = will=20 need to meet these new
>> = requirements.
>>
>> What=20 that means to us, is that if we are designing technologies to = meet
>>=20 specific control requirements, there are now new constraints on=20 those
>> systems which would come to be used in officia=20 capacities.
>
>  NEA is working on protocol level=20 requirements and design.  Logging,
> UI, and legal issues = are=20 (IMHO) out of scope.

its a good thing its just an opinion... = what I am=20 talking about is what is
required to place technologies into SOX = and other=20 regulated entities, and if
the IETF doesnt want to deal with those = then it=20 should specifically say that
in the scope statement to elminate = the issues=20 of legal compliance
requirements.

The problem is that most = techies=20 here have no idea what the law is doing to
IT requirements and yet = people=20 continue to design technologies intentionally
to fail to meet = those=20 requirements. The really funny thing to do is to
listen to the IT = Manager=20 try and talk their way out of being dinged by the
IT Auditor's for = running=20 unsecured and rediculously stupid code in their
system, and as it = happens=20 I think that NEA is the next one of these winners
to come out of = the=20 IETF.

The issues are simple - and that is if there is a desire = to=20 install a system
that can pre-qualify the security compliance and = platform=20 configuration
compliance into the IT world then it needs to do so = in=20 concert with the
Auditor's who will tell the IETF whether they are = willing=20 to put their names
and professional reputation/credentials on the = line by=20 using this protocol
as  their recommendation. Otherwise why=20 bother?

> An NEA requirement that
> systems MAY = transport=20 user-visible strings is fine.  However, certain
> = implementations=20 in certain jurisdictions MAY have additional
> requirements on = what is=20 done with those strings.

The EU Data Integrity "regulation" may = not=20 agree with you.

>
>  If we design NEA for the=20 lowest-common legal denominator, then we will
> have a system = that does=20 nothing.

No - but that is the typical claim from techies who = dont know=20 what they are
designing to. The problem with NEA is that there are = regulatory requirements
for this type of thing and the NEA WG = wants to=20 build something else that
doesnt address those but claims to=20 apparently.

>
>> That said, since there are new=20 'requirements' in operating official
>> systems, NEA should = address=20 those too... and that said, passing
>> plain-text about is a=20 no-no
>
>  I'm a little at a loss to see how we can = design an=20 access protocol
> that doesn't tell the user whether or not = they've been=20 granted access,
> or even if they've been denied.

Uh = simple - the=20 users NIC can easily be used to tell them all kinds of
things = including NO=20 CONNECTION.

> A list of canned status/error messages
> = isn't=20 good enough, as experience has shown.
>
>>>  I = would=20 like the ability for administrators to push messages to = end
>>>=20 users via NEA.  This involves the *capability* to=20 transport
>>> internationalized strings in NEA. =  However,=20 those strings are
>>> informative to the end user, and = opaque to=20 the rest of NEA.
>>
>> So do a table of messages = based on=20 the entitlement models supported and
>> then publish UTF-8 = strings of=20 them in whatever language you want to
>> = support.
>
>=20  Can we enumerate *enough* possible messages to be useful? =  I doubt=20 it.

Sure - a common set of messages is all that is necessary = and simple=20 UTF-8
Encoding to make those = transportable.

>
>>>=20  I can understand this on the wide open net.  For the = chartered=20 purpose
>>> (enterprises), I don't see why it's a=20 problem.
>>
>> Integrity of the Audit Process = running inside=20 the "Entity".  Think of
>> your average University for = instance.=20 How many would-be hackers are
>> inside the Entity=20 then.
>
>  Charter.  We have it.  We should = focus=20 on it.  Universities are out of
> scope.  Issues with=20 deploying NEA inside of Universities are out of
> scope. =  If=20 certain designs work in an enterprise, but not in a
> = university, then=20 issues with the university deployment are irrelevant.
> They are = canards, and out of scope.

Screw the Academic issues, as a = professional=20 auditor I believe that you nor
no one else here will install NEA = in its=20 current form in any regulated
networks period. I just wont fly = with what=20 you got now, whether you like
that or not, and whether you believe = it or=20 not...

>
>>> [ re: informational messages=20 ]
>>>  No.  They can be thrown away.  Many = PPP=20 implementations have done this
>>> for years.  It's = annoying,=20 but widely accepted practice.
>>
>> Depending what = type of=20 auditing and integrity of process model NEA is to
>>=20 support.
>
>  I'm not really sure what you mean by = that.=20  Informational messages
> are... informational.  They = have=20 little definitive meaning.

Uhh is NEA a tool for qualifying = systems=20 prior to accessing the entity
resources?

>
> =  In=20 contrast, messages like "you must upgrade now" are not
> = informational.=20  They impose normative requirements on the user, and
> = should be=20 logged, audited, etc.

Agreed as should any status message from = any=20 transaction.

>
>  Alan DeKok.=20



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

------=_NextPart_001_0119_01C7DFE7.49547660-- ------=_NextPart_000_0118_01C7DFE7.49547660 Content-Type: image/gif; name="graycol.gif" Content-Transfer-Encoding: base64 Content-ID: <011401c7e021$f5a4f680$174f7d40@home.glassey.com> R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 ------=_NextPart_000_0118_01C7DFE7.49547660 Content-Type: image/gif; name="ecblank.gif" Content-Transfer-Encoding: base64 Content-ID: <011501c7e021$f5a4f680$174f7d40@home.glassey.com> R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 ------=_NextPart_000_0118_01C7DFE7.49547660 Content-Type: image/gif; name="28926514.gif" Content-Transfer-Encoding: base64 Content-ID: <011601c7e021$f5a4f680$174f7d40@home.glassey.com> R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 ------=_NextPart_000_0118_01C7DFE7.49547660 Content-Type: image/gif; name="28384070.gif" Content-Transfer-Encoding: base64 Content-ID: <011701c7e021$f5a4f680$174f7d40@home.glassey.com> R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 ------=_NextPart_000_0118_01C7DFE7.49547660-- --===============0129024714== 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 --===============0129024714==-- From nea-bounces@ietf.org Fri Aug 17 10:29: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 1IM2pL-00070A-76; Fri, 17 Aug 2007 10:29:27 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IM2pK-000704-5F for nea-confirm+ok@megatron.ietf.org; Fri, 17 Aug 2007 10:29:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IM2pJ-0006zw-Q3 for nea@ietf.org; Fri, 17 Aug 2007 10:29:25 -0400 Received: from elasmtp-banded.atl.sa.earthlink.net ([209.86.89.70]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IM2pI-0000TO-Ev for nea@ietf.org; Fri, 17 Aug 2007 10:29:25 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=THhjfQtaNsdZAyH11lylrPf7SO8mzX3+TAuHwkTfdIdYmlGK3k6lBLgxQXjs0/+A; 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 [24.23.176.93] (helo=tsg1) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1IM2p9-0004ao-OZ; Fri, 17 Aug 2007 10:29:16 -0400 Message-ID: <000f01c7e0da$fe2505c0$6501a8c0@tsg1> From: "TS Glassey" To: "Paul Sangster" , "Stephen Hanna" , "Tim Polk" References: <90062D95-8D05-41D2-B8E8-2E8CDE7460E8@nist.gov> Date: Fri, 17 Aug 2007 07:29:10 -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: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec7985ab5e9fad59b07357f4e2bc4fe38a85350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.23.176.93 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1df8e4abc9851cb4adb45bd64d8514ae Cc: nea@ietf.org Subject: [Nea] Possible NEA usage.... X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org FYI - In the US and in many other countries the DoE does a number of key things with what are called SCADA systems. SCADA is "Systems Control and Data Acquisition" & fwiw NEA would be a good qualification tool for SCADA and other types of control/analytical systems. This opens a new opportunity which I hadnt looked at myself, but which would support NEA's deployment at a national level. Tim Polk may want to investigate this as well within NIST as there was just a new push in Congress to expand NIST's budgets as well as set up a eDARPA (for energy and energy control related technologies) enetity to push research there. Just a thought. Todd ----- Original Message ----- From: "Paul Sangster" To: "Stephen Hanna" ; "Tim Polk" Cc: Sent: Tuesday, August 14, 2007 5:50 PM Subject: RE: [Nea] comments on draft-ietf-nea-requirements-03 Would anyone like to argue that the diagrams (figure 2 and 3) are important to remain (justifying their use of nearly 1 page of the spec)? > -----Original Message----- > From: Stephen Hanna [mailto:shanna@juniper.net] > Sent: Tuesday, August 14, 2007 9:57 AM > To: Paul Sangster; Tim Polk; Kaushik Narayan > Cc: nea@ietf.org > Subject: RE: [Nea] comments on draft-ietf-nea-requirements-03 > > I'm in favor of dropping the diagrams. I agree it's hard to > match up the diagrams to the steps in the text. Using ASCII > art, I think it will be hard to make this work. And without > this correspondence, I don't think the diagrams add very > much. In fact, they confuse things. > > That's just my personal opinion, BTW. > > Thanks, > > Steve > > -----Original Message----- > From: Paul Sangster [mailto:Paul_Sangster@symantec.com] > Sent: Monday, August 13, 2007 6:09 PM > To: Tim Polk; Kaushik Narayan > Cc: nea@ietf.org > Subject: RE: [Nea] comments on draft-ietf-nea-requirements-03 > > Catching up on this thread and doing the discussed editing ... > > Some additional comments in-lined with [PS] prefix: > > > -----Original Message----- > > From: Tim Polk [mailto:tim.polk@nist.gov] > > Sent: Friday, August 10, 2007 1:52 PM > > To: Kaushik Narayan > > Cc: nea@ietf.org > > Subject: Re: [Nea] comments on draft-ietf-nea-requirements-03 > > > > Hi Kaushik, > > > > Thanks for the prompt and enlightening response. In general, I am > > fine with your responses, so I deleted most of the quoted > > conversation. Responses on the remaining issues are inline. > > > > On Aug 10, 2007, at 3:18 PM, Kaushik Narayan wrote: > > > > > Hi Tim, > > > > > > Thanks for your comments. Please find my response inline. > > > > > > > > > On 8/9/07 2:27 PM, "Tim Polk" wrote: > > > > > >> Section 2.0 Terminology > > >> > > >> Numerous terms are defined in terms of Posture Collectors > > and Posture > > >> Validators, but these terms are not defined until section 5. > > >> > > > > > > > > > > > > > > > The definitions currently cover all terms expect for the > > components of > > > the NEA client and NEA server stack defined in the > reference model. > > > There might > > > not be sufficient context before Section 2.0 to properly > > define terms > > > such as Posture Collector, Posture Broker etc. We could > > certainly try > > > to add these definitions for the sake of completeness. > > > > > > Did you find lack of these definitions in Section 2.0 as > > effecting the > > > readability of the document. > > > > > > > Personally, I thought the definitions would be cleaner if > the Posture > > Collector, Posture Broker, and Posture Validator were not > addressed in > > the terminology section. > > [PS] Presume you would prefer we not mention those components > in the terminology but instead try to be descriptive. We > could try this or create terminology entries for the couple > that we use. The challenge is several folks have asked for > more precise term definitions so we used those names. We > could also include references "Posture Collector (see section > 5.1.1.1)"... > > > > > This is a stylistic question, though; the effect on readability was > > negligible. > > [PS] Sounds like its not worth a big change but we'll try to > make a minor change to improve the situation. > > > > > > > > > > > > > > >> > > >> 5.1.1.2 Posture Broker Client > > >> > > >> Question 2: Does the WG envision a set of result attributes that > > >> are mandatory to support for a posture broker client? This is > > >> implied by the fourth bullet... > > >> > > > > > > > > > > > > Yes. The document talks about the global posture assessment > > > attribute which is mandatory to support for posture > broker clients > > > and servers. > > > > > > > > > > > > > That makes sense to me, but it doesn't seem to be clearly > specified as > > a requirement. I don't think that is a significant problem, but if > > the WG has consensus on this maybe we should clearly state it. > > [PS] We currently defined just the protocol capability > (normative) requirements as these affect the WG protocol > selection process (e.g. > PB-1 says protocol must be able to carry the result > attributes). We didn't define NEA Client/Server processing > requirements such as what the Posture Broker Client must be > able to do with different types of error/success result > attributes. Hopefully this was the right decision as we > didn't want to state requirements for all the semantics that > NEA components would need to provide. When a PB protocol is > selected and the result attributes defined they will describe > their syntax and semantics. > > > > > >> > > >> > > >> Section 6. > > >> > > >> The example seems to assume that the OS is known. > Stating that up > > >> front would be helpful. > > >> > > >> Figure 2 and the text in 6.1.1.2 should be tightly > > coupled. The text > > >> contains 13 numbered steps, but the figure has either 14 or 17 > > >> steps (depending on how I count the flows between the pt > client and > > >> pt broker server). > > >> > > > > > > > > > > > > Figure 2 is common to both examples of initial assessment, i.e. > > > Section > > > 6.1.1 & 6.1.2. We did not intend a co-relation to a > specific example > > > and that's why you notice the difference in steps. > > > > > > We will add text before Figure 2 to make this clear. > > > > > > > > > > > > > If a tight coupling between the figure and examples is not > intended, > > more information may be needed in Figure 2. For example > "Pos Req" or > > a variant of that is the label on five arrows. Those five arrows > > correspond to > > > > (1) Posture validator(s) send PA messages containing the desired > > attributes to the Posture Broker Server. > > (2), (3) Posture Broker Server aggregates the PA messages and sends > > them to the NEA client via the Posture Transport Server. > > (4) The Posture Transport Client sends the aggregated PA > messages to > > the Posture Broker Client. > > (5) The Posture Broker Client de-mulitplexes the PA messages and > > delivers them to the appropriate Posture Collector(s). > > > > We are asking a lot from the reader to sort all this out on > their own! > > [PS] As Kaushik mentioned the diagram was supposed to be > generic covering all initial assessment cases but as a result > don't correspond well with the detailed use cases defined. > We included the illustrations with the understanding that if > they caused confusion we would consider removing them. We > didn't feel strongly that they were needed but until now > noone had mentioned that they were confusing. Do folks > believe we should try to repair them or just drop both form > the document (saving a page)? > > > > > > > > > > > >> 7.3 > > >> > > >> Requirement PB-4 > > >> > > >> If the posture broker needs to protect global assessment > > information > > >> (see comments on 5.2.2), then MAY is too weak. MUST or > > possibly MAY > > >> would be needed... > > >> > > > > > > > > > > > > You mean MUST or SHOULD. This was discussed at the Prague IETF > > > meeting and moved from a SHOULD to a MAY. > > > > > > We certainly open this discussion within the WG. > > > > > > > > > > > > > No need to reopen discussion on this item. MAY is > consistent with the > > rationale provided for my comment on 5.2.2. I am satisfied > that the > > WG has considered the issue. > > [PS] Ok, their hasn't been strong support to move this back > to SHOULD yet but if this occurs we could consider it. Note > this is a requirement that applies to our protocol selection > (the WG can still select a PB protocol that has strong > security capabilities) even with a MAY in this requirement. > > > > > > > > >> 8.1.2 > > >> > > >> The last sentence in this section seems to establish a > > requirement > > >> for > > >> the NEA protocols. This material needs to be presented > earlier and > > >> represented as a section 7 requirement. > > >> > > >> Section 9.2, next to last paragraph: > > >> > > >> "For example, an enterprise might ask about the OS > > >> version in the initial message dialog and after learning the > > >> system is a Linux system, ask for a different/smaller set of > > >> attributes specific to Linux then it would if the > > endpoint was a > > >> Windows system. " > > >> > > >> This text answered a nagging question for me, when I > > encountered it. > > >> While I was glad to learn how the wg intended to address the OS > > >> identification problem, page 48 was a little too late. > I believe > > >> the possibility of a bootstrapping ought to be addressed > earlier, > > >> and we should clearly state which component (PB Client or PC?) > > >> resolves this type of question... > > > > > > > > > > > > > > > Would this be a requirement or update to the reference model to > > > state that the OS discovery would be handled by the Posture > > > Collector. I am not sure about the motivation to special > case the OS > > > type different > > from any > > > other > > > standard attribute. > > > > > > Regards, > > > kaushik > > > > > > > > > > > > > Once again, I was unintentionally vague.... > > > > Interrogating an endpoint with respect to its OS seems inconsistent > > with the definitions of posture and posture attribute in 2., so I > > couldn't figure out how the posture validator(s) knew which OS a > > system ran. Without that knowledge, the posture validator(s) can't > > know which attributes to request. > > > > There are a couple of solutions: (1) request all possibly > interesting > > posture attributes for all recognized OSes, and sort out > the results; > > or (2) interrogate the endpoint and request teh attributes > that make > > sense. > > > > From the text in the security considerations, I deduced that > > discovery may be performed by requesting posture attributes that > > describe the OS, etc. but that this step was omitted from > the example > > since multiple round trips complicate the base concepts. This also > > implies the definitions of posture and posture attribute could be > > expanded... > > > > So, maybe it isn't a new requirement, its just an extra > clause in the > > definition of posture. > > We could add a couple clauses in the examples to make it more > clear that the OS version is treated like other component > (e.g. firewall) versions on the endpoint. > > > > > Thanks again, > > > > Tim Polk > > > > > > > > _______________________________________________ > > Nea mailing list > > Nea@ietf.org > > https://www1.ietf.org/mailman/listinfo/nea > > > > > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea > > > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea > _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Aug 23 01:32:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IO5Ir-0002lP-5F; Thu, 23 Aug 2007 01:32:21 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IO5Ip-0002lE-Le for nea-confirm+ok@megatron.ietf.org; Thu, 23 Aug 2007 01:32:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IO5Ip-0002l6-11 for nea@ietf.org; Thu, 23 Aug 2007 01:32:19 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IO5In-00059I-K0 for nea@ietf.org; Thu, 23 Aug 2007 01:32:19 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 22 Aug 2007 22:32:17 -0700 X-IronPort-AV: i="4.19,297,1183359600"; d="scan'208"; a="204937836:sNHT66038868" 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 l7N5WHiZ022645; Wed, 22 Aug 2007 22:32:17 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7N5WGM9006857; Thu, 23 Aug 2007 05:32:17 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Aug 2007 22:32:16 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] Comments on draft-ietf-nea-requirements-03.txt Date: Wed, 22 Aug 2007 22:32:18 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] Comments on draft-ietf-nea-requirements-03.txt Thread-Index: AcfbqpkR2RO3Mv6hQ9aJC7GjQxG3nwDD1O2AAaJJFVA= From: "Joseph Salowey \(jsalowey\)" To: "Paul Sangster" , X-OriginalArrivalTime: 23 Aug 2007 05:32:16.0815 (UTC) FILETIME=[F79E0BF0:01C7E546] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10725; t=1187847137; x=1188711137; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20[Nea]=20Comments=20on=20draft-ietf-nea-requirements-0 3.txt |Sender:=20; bh=KdqwCvhcjEts30s2nPyCcS5Pc/RbLpGFf1Ij+w2W324=; b=LDnoDZhFkEjvfwKUQMHNyIAGGNlaJp7B9fABdKEeaVOIPDUx8+OqQie1/xzRw8cAHq/D6iep aXGDd945XcCFc3hhpr0xSsTQKxmetf+dsEQwmvqG4YVgpE+eEir0Qwrg; Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 162d87dc0b780d17da9b1934777fd451 Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Hi Paul,=20 Inline below:=20 > -----Original Message----- > From: Paul Sangster [mailto:Paul_Sangster@symantec.com]=20 > Sent: Tuesday, August 14, 2007 3:41 PM > To: Joseph Salowey (jsalowey); nea@ietf.org > Subject: RE: [Nea] Comments on draft-ietf-nea-requirements-03.txt >=20 > Thanks for the comments on the draft, some feedback is in-lined...=20 >=20 > > -----Original Message----- > > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > > Sent: Friday, August 10, 2007 5:00 PM > > To: nea@ietf.org > > Subject: [Nea] Comments on draft-ietf-nea-requirements-03.txt > >=20 > > In general the document looks pretty good, but I do have a few=20 > > comments. > >=20 > >=20 > > Comments on Section 2 > >=20 > > - I expected to see a term along the lines of "Network Endpoint=20 > > Assessment Authority." This is the entity who is trusted=20 > to perform=20 > > the endpoint assessment. This is often related to the=20 > device owner in=20 > > that it is either specific entities that are part of the=20 > device owner=20 > > or a third party that has been delegated the authority to perform=20 > > assessment by the device owner. >=20 > I presume by "device owner" your referring to the owner of=20 > the endpoint (device being assessed). Would you envision=20 > this authority being someone other than the NEA Server for=20 > this document? We discuss the trust relationships in section=20 > 8.1 and I suspect the NEA Server is fulfilling the role your=20 > describing. >=20 > Did the lack of a term take away from readibility of the document? >=20 [Joe] I had envisioned the NEA server being the authority, however I'm not sure that the rest of the document supported this. There seems to be many trust relationships involved.=20 > >=20 > > Comments on Section 3 > >=20 > > - Is the case where an device is owned by an individual who=20 > contracts=20 > > out compliance assessment to a third party in scope? >=20 > No, our scope is pretty narrow as dictated by our charter. =20 > Section 3.2 paragraph 2 and 3 discusses the scope regarding=20 > ownership of the endpoint (device) vs. the network which is=20 > primarily about when both the endpoint and network are owned=20 > by the same entity. >=20 [Joe] OK >=20 > >=20 > > Comment on Section 5 > >=20 > > Section 5.1.1.1 > >=20 > > - The last paragraph is asking the reader to "Recall that=20 > this is not=20 > > a set of requirements for what each Posture Collector=20 > implementation=20 > > must support." Where is the reader recalling this from? Also does=20 > > this apply to the other sections. >=20 > Will fix the text (recall isn't the best word). I'll review=20 > the other NEA component descriptions to see if a similar note=20 > is required. Its particularly important for the collector=20 > and validator where we expect many to exist and likely be=20 > pretty simple so not every responsibility listed may be applicable. >=20 > >=20 > > Section 5.1.1.1,2,3 > >=20 > > - 5.1.1.1 and 5.1.1.3 describe cryptographic protection at the=20 > > transport, the collector, why wouldn't the broker be able=20 > to provide=20 > > cryptographic protection as well? What are the goals of the=20 > > cryptographic protection cited? >=20 > Each layer provides different cryptographic security=20 > services. The PA layer security is providing true end to end=20 > protection even when the Posture Validator is located on a=20 > different system then the Posture Broker Server. This=20 > enables the end Posture Validator to cryptographically=20 > authenticate the Posture Collector and even provide private=20 > (encrypted) messages spanning multiple systems. This=20 > mentioned later in the document and in requirement PA-5 but=20 > we could make it more clear if you think it would help. > =20 [Joe] This is where I get worried. This is requiring a trust relationship between each posture validator and posture collector. Is this really necessary. This is introducing a lot of trust management and key management issues that are not well discussed in the rest of the document. I would expect that mot deployable solutions would require cryptographic protection of the transport or at the broker. I think requiring standardized protection at this layer introduces a lot of complexity and I'm not exactly sure how it would help. =20 > >=20 > > Section 5.2.1 > >=20 > > - Is the application of cryptographic protection a matter=20 > of policy as=20 > > in 5.2.3? >=20 > Yes, we talk about this in section 8.2. >=20 > >=20 > > Section 6 > >=20 > > Section 6.1.1.x > >=20 > > - In this case it is not clear when network access is given=20 > or not, or=20 > > really what it means to have network access. It is also not clear=20 > > that the NEA client itself would the component that=20 > requests network=20 > > access. >=20 > Not sure I follow. For example, in 6.1.1.x it's the last=20 > sentence of the last paragraph of 6.1.1.1 and step 16 in=20 > 6.1.1.2. Does this need to be more clear or were you=20 > referring to something to something else. =20 >=20 > I agree its possible the NEA client doesn't necessarily=20 > directly request network access but it would be tied into the=20 > sequence of events during the entrance to the network. We=20 > expect their may be lower layer protocols below the NEA=20 > client that might directly request network access. One might=20 > argue they are part of the carrier protocol which we define=20 > to be part of PT (in the NEA Client) but some portion may be=20 > below it without damaging the model. >=20 [Joe] OK, I think I understand. However it seems to me that in step 13 the client is downloading patches, etc. while they are not connected to the network. How is this supposed to happen? =20 > >=20 > > Section 7 > >=20 > > - C-5 - It seems that it might be advantageous for the PA and PB=20 > > protocols to have knowledge of which transport they are=20 > running over. > > This may help in determining which mode from c-10 to run in.=20 >=20 > Agreed. We're reworded C-5 which should help as it might be=20 > helpful for PA/PB to know information about bandwidth, MTU,=20 > latency in order to optimize its payload sizes. We didn't=20 > want the PA or PB message formats to change for different PT=20 > protocols. Its now says: >=20 > "The PA and PB protocols MUST be capable of operating over=20 > any PT protocol." The 2nd sentence remains as it was. >=20 [Joe] OK, sounds good.=20 > >=20 > > - PA-6 - It seems that different posture collectors may use=20 > different=20 > > mechanisms to protect their attributes based on there requirements=20 > > necessary to protect their data and the type of security=20 > relationship=20 > > their components have. Is it necessary to specify=20 > protection at this=20 > > layer? These different layers of cryptography introduce=20 > complexities=20 > > around key management suggest multiple trust relationships. >=20 > The PA candidate protocols will specify how they provide=20 > these cryptographic protections to attributes if desired by a=20 > collector/validator. I'm not sure about 'different=20 > mechanisms' as they will all use what ever the PA protocol=20 > the NEA WG selects offers. The WG did discuss the=20 > cryptography at multiple layers issue a few times most=20 > recently in Prague and agreed we wanted support for end to=20 > end security even when the Posture Validator was remote from=20 > the Posture Broker Server. (We did however downgrade the PB=20 > protocol to a MAY for having to provide such cryptographic=20 > mechanisms). > =20 [Joe] As I stated above, I don't think this is a good approach. You are requiring key management and associated trust relationships above the NEA server level. This introduces multiple authorities and the need to manage them. I think this adds a lot of complexity. In most of the rest of the document you describe relationships between the NEA client and NEA server. I think this is more manageable. Requiring cryptography at the PA layer introduces requirements that are not discussed in this document.=20 > >=20 > > - PT-6 What does "This MAY occur by leveraging by-products (e.g.,=20 > > keys) supplied by the PB protocol authentication." > > mean and is it important at this level of requirements. >=20 > This text was removed from the next version of the I-D, but=20 > it used to refer to cryptographic binding between protocol=20 > layers by exposing by-products (derived) keying material to=20 > higher layers (also might be nice for channel binding if=20 > desired). The text is now gone based on other feedback. Of=20 > course candidate protocols may offer this feature. > =20 [Joe] OK > >=20 > > Section 8 > >=20 > > - Section 8.1 - the discussion of trust left me a bit unsatisfied. > > There are lots of components (PC,PV,etc.) in the NEA system=20 > that have=20 > > the requirement for a cryptographic basis for trust. This section=20 > > glosses over trust between components in favor of discussing a NEA=20 > > Client and NEA Server. Since the document treats these as=20 > composed of=20 > > separate components with apparently their own trust=20 > relationships the=20 > > should be discussed in this section. >=20 > Not sure how to address your comment. Do you have any=20 > proposed text or even specific boundaries to make this more=20 > clear? I'm not opposed to doing this particularly if it's a=20 > key trust boundary. The trust section focuses on the key=20 > boundaries between components where trust is essential. We=20 > didn't focus on trust issues between some components that we=20 > expected (or even assumed by charter) to be co-located. >=20 [Joe] Unfortunately the rest of the document introduces trust relationships between these components. I really would rather see this section as it is, but it does not reflect what comes before. =20 > >=20 > > Section 9 > >=20 > > - Just a comment that there may be benefit to the endpoint user to=20 > > have their compliance checked, NEA should be as much about=20 > protecting=20 > > the end point rather than protecting the client. Most of=20 > the document=20 > > seems OK with the respect, but it something to keep in mind. >=20 > Agree, so you suggesting we highlight this elsewhere in the=20 > spec (since its not a privacy topic)? We did try to mention=20 > this including in use case example section 6.1.2.1. >=20 {Joe] Yes, this was really just a rant. Section 6.1.2.1 does cover this. =20 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Aug 24 23:01:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOlth-0005lf-O2; Fri, 24 Aug 2007 23:01:13 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IOltg-0005lH-1z for nea-confirm+ok@megatron.ietf.org; Fri, 24 Aug 2007 23:01:12 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IOltf-0005l9-Ly for nea@ietf.org; Fri, 24 Aug 2007 23:01:11 -0400 Received: from extu-mxob-2.symantec.com ([216.10.194.135]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IOlte-0002uM-M3 for nea@ietf.org; Fri, 24 Aug 2007 23:01:11 -0400 Received: from tus1opsmtapin02.ges.symantec.com ([192.168.214.44]:53707) by extu-mxob-2.symantec.com with esmtp (Exim 4.66) (envelope-from ) id 1IOlte-0004Fl-4y for nea@ietf.org; Fri, 24 Aug 2007 20:01:10 -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 1IOlte-0004HP-15 for nea@ietf.org; Fri, 24 Aug 2007 20:01:10 -0700 Received: from TUS1XCHEVSPIN05.enterprise.veritas.com ([155.64.231.27]) by TUS1XCHECNPIN02.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Aug 2007 20:01:09 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 24 Aug 2007 20:01:08 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FYI: draft-ietf-nea-requirements-04 submitted for publication Thread-Index: AcfmxC+YndnZRlTUTBOrhSfgmTQ7bQ== From: "Paul Sangster" To: X-OriginalArrivalTime: 25 Aug 2007 03:01:09.0860 (UTC) FILETIME=[301E0240:01C7E6C4] X-Brightmail-Tracker: AAAAAQAAAUA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Subject: [Nea] FYI: draft-ietf-nea-requirements-04 submitted for publication X-BeenThere: nea@ietf.org X-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="===============1404178493==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============1404178493== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7E6C4.2FF5F6C2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7E6C4.2FF5F6C2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just wanted to update the WG that we have submitted an updated version (-04) of the Overview and Requirements I-D to the IETF for publication. We=20 expect this version will be available next week. =20 Version -04 has a number of improvements over -03 based on feedback from the WG particularly during the WGLC period (note that we did not get to=20 incorporate comments made post-WGLC in this revision). Based on these comments=20 we felt it was necessary to make some significant enough changes that=20 would warrent another WGLC period on the -04 version. We also have one remaining significant issue we would like the WG to discuss prior to starting=20 WGLC (more on this next week). =20 In summary, the editors made the following non-editorial changes in -04: o Rewrote introduction initial paragraph to avoid potential confusion about our scope. o Emphasized requirements section is only normative section in I-D o Removed term 'component' and reworded several sections to de-emphasize word causing some confusion. o Clarified discussion of Posture Collector and Validator identities o Removed figures considered inconsistent and confusing * Clarified and simplified many of the requirements. Please review these changes and send comments. Specifically the changes were: - Simplified C-1 - Merged intent of C-2 and C-3 (covering initiating assessment or reassessment from NEA client or server) making both a SHOULD (instead of just re-assessment) in a single requirement (C-2 in -04 I-D). - Simplified wording of C-4 (formerly C-5 in -03 I-D) - Replaced/simplified former C-9 and C-10 with words clarifying their=20 intent - Added new C-9 which covers PA-8 from -03 I-D (I18N of strings) - Removed former PA-3 (not necessary) - Clarified wording of PA-4 - PA-8 from -03 I-D moved and reworded into new C-9 - Added new PB-2 (not interpret PA contents) - Replace/reworded former PB-3 to clarify its intention - Removed PT-1 and PT-2 which are covered by other reqs (e.g. new C-8) - Mergered PT-4 and PT-6 from -03 I-D (security requirements) in new PT-2 - Added new PT-4 and PT-5 focused on where PT SHOULD be able to run o Made numerous editorial changes based on comments from: Alan DeKok, Lauren Giroux, Steve Hanna, Paul Hoffman, Leif Johansson, Tim Polk, Joe Salowey, Chris Salter, Mauricio Sanchez, Susan Thomson, Nancy Winget =20 * - Significant change needing most review =20 As you can tell the bulk of the non-editorial work went into the requirements section which has changed significantly. We would like to encourage WG members to closely review section 7 and send feedback ASAP so we can proceed towards another WGLC. Clearly the list will make more sense once the I-D is published :). =20 Thanks, =20 Paul ------_=_NextPart_001_01C7E6C4.2FF5F6C2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Just wanted to update the WG that we = have submitted=20 an updated version (-04)
of the Overview and Requirements I-D to the = IETF for=20 publication.  We
expect this version will be available next=20 week.
 
Version -04 has a number of = improvements over -03=20 based on feedback from
the WG particularly during the WGLC period = (note that=20 we did not get to
incorporate comments made post-WGLC in this=20 revision).  Based on these comments
we felt it was necessary to = make=20 some significant enough changes that
would warrent another WGLC = period on=20 the -04 version.  We also have one
remaining significant issue = we would=20 like the WG to discuss prior to starting
WGLC (more on this next=20 week).
 
In summary, the editors made the = following=20 non-editorial changes in -04:
   o Rewrote introduction = initial=20 paragraph to avoid potential confusion
     about = our=20 scope.
   o Emphasized requirements section is only = normative=20 section in I-D
   o Removed term 'component' and reworded = several=20 sections to de-emphasize
     word causing some=20 confusion.
   o Clarified discussion of Posture Collector = and=20 Validator identities
   o Removed figures considered = inconsistent=20 and confusing
   * Clarified and simplified many of the=20 requirements.  Please review
     these = changes and=20 send comments. Specifically the changes = were:
       - Simplified=20 C-1
     =20  - Merged intent of C-2 and C-3 (covering initiating = assessment=20 or
         reassessment from = NEA client=20 or server) making both a SHOULD=20 (instead
         of just re-assessment) in = a single=20 requirement (C-2 in -04 I-D).
  =20     - Simplified wording of C-4 (formerly C-5 in = -03=20 I-D)
     =   -=20 Replaced/simplified former C-9 and C-10 with words clarifying=20 their 
         intent
       - = Added new C-9=20 which covers PA-8 from -03 I-D (I18N of strings)
       - Removed former = PA-3 (not=20 necessary)
     =20  - Clarified wording of = PA-4
       - PA-8 from -03 I-D moved and = reworded=20 into new C-9
    =20   - Added new PB-2 (not interpret PA=20 contents)
     =20  - Replace/reworded former PB-3 to clarify its=20 intention
     =20  - Removed PT-1 and PT-2 which are covered by other reqs = (e.g. new=20 C-8)
     =20  - Mergered PT-4 and PT-6 from -03 I-D (security = requirements) in=20 new PT-2
     =20  - Added new PT-4 and PT-5 focused on where PT SHOULD be = able to=20 run
   o Made numerous editorial changes based on comments = from:=20 Alan DeKok,
     Lauren Giroux, Steve Hanna, = Paul=20 Hoffman, Leif Johansson, Tim Polk,
     Joe = Salowey,=20 Chris Salter, Mauricio Sanchez, Susan Thomson, Nancy Winget
 
* - Significant change needing most=20 review
 
As you can tell the bulk of the = non-editorial work=20 went into the requirements
section which has changed = significantly.  We=20 would like to encourage WG
members to closely review section = 7 and send=20 feedback ASAP so we can proceed
towards another WGLC.  Clearly the list will make more sense = once the=20 I-D is
published=20 :).
 
Thanks,
 
Paul
------_=_NextPart_001_01C7E6C4.2FF5F6C2-- --===============1404178493== 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 --===============1404178493==-- From nea-bounces@ietf.org Tue Aug 28 16:15: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 1IQ7TD-0006Nf-22; Tue, 28 Aug 2007 16:15:27 -0400 Received: from nea by megatron.ietf.org with local (Exim 4.43) id 1IQ7Sq-0005eJ-30 for nea-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 16:15:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ7Sp-0005e4-Mw; Tue, 28 Aug 2007 16:15:03 -0400 Received: from ns1.neustar.com ([2001:503:c779:1a::9c9a:108a]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQ7So-0008Fb-FS; Tue, 28 Aug 2007 16:15:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns1.neustar.com (Postfix) with ESMTP id 5DA1126E73; Tue, 28 Aug 2007 20:15:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IQ7So-0006wV-6J; Tue, 28 Aug 2007 16:15:02 -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: Tue, 28 Aug 2007 16:15:02 -0400 X-Spam-Score: -1.4 (-) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: nea@ietf.org Subject: [Nea] I-D ACTION:draft-ietf-nea-requirements-04.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-04.txt Pages : 50 Date : 2007-8-28 This document defines the problem statement, scope and 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 such as: anti-virus and host-based firewall software. In order to provide context for the requirements, a reference model and terminology are introduced. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nea-requirements-04.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-04.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-04.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-8-28152304.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nea-requirements-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nea-requirements-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-8-28152304.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--