From nea-bounces@ietf.org Tue Jan 09 16:02:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4O6W-00029L-7y; Tue, 09 Jan 2007 16:01:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4O6U-00028s-Sx for nea@ietf.org; Tue, 09 Jan 2007 16:01:54 -0500 Received: from extu-mxob-2.symantec.com ([216.10.194.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4O6I-00011x-0M for nea@ietf.org; Tue, 09 Jan 2007 16:01:54 -0500 Received: from extu-mxob-2.symantec.com (unknown [127.0.0.1]) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id 2AACC38C095 for ; Tue, 9 Jan 2007 13:06:26 -0800 (PST) X-AuditID: d80ac287-a3969bb000002536-3c-45a403d15a05 Received: from tus1opsmtapin02.ges.symantec.com (tus1opsmtapin02.ges.symantec.com [192.168.214.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id E0DC8348002 for ; Tue, 9 Jan 2007 13:06:25 -0800 (PST) Received: from [10.137.18.178] (helo=SVL1XCHECNPIN01.enterprise.veritas.com) by tus1opsmtapin02.ges.symantec.com with esmtp (Exim 4.52) id 1H4OEi-0003Uj-Rv for nea@ietf.org; Tue, 09 Jan 2007 13:10:24 -0800 Received: from SVL1XCHEVSPIN01.enterprise.veritas.com ([166.98.169.12]) by SVL1XCHECNPIN01.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 Jan 2007 13:01:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 9 Jan 2007 13:01:40 -0800 Message-ID: <5A58F967CBEBBB4A82DF126CF8A9596A021B8E5C@SVL1XCHCLUPIN02.enterprise.veritas.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-nea-requirements-00.txt submitted Thread-Index: Acc0MVvYE9xCLHQpTyWi8MW3lRKTJw== From: "Paul Sangster" To: X-OriginalArrivalTime: 09 Jan 2007 21:01:40.0864 (UTC) FILETIME=[5C392800:01C73431] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Subject: [Nea] draft-ietf-nea-requirements-00.txt submitted X-BeenThere: nea@ietf.org X-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="===============0775735290==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============0775735290== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73431.5C1E25F0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C73431.5C1E25F0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Just wanted to send out an update to the WG to let you know the NEA Design Team has been hard at work (even over the holidays) creating the -00 requirements I-D that we could use as a starting point for our discussion. We understand this doesn't reflect WG consensus at this point but wanted to provide something the group could review and use to help focus the discussions to work towards consensus. We look forward to constructive discussions on how to fix its many errors ;). =20 Creating this document during December was a significant challenge and required a real time commitment from the team to get this out by our early January milestone. I'd like to thank the other members of the design team (Hormuzd Khosravi, Mahalingam Mani, Kaushik Narayan, and Joe Tardo) for all their time and effort over a busy holiday filled month. The result of our work draft-ietf-nea-requirements-00.txt was submitted yesterday for publication, so we hope it will appear in the drafts directory later this week (or next.) =20 The document is substantial is size (45 pages) and content (problem statement, applicability, reference model, requirements, ...) so it was our hope that when issued we could start a more organized e-review of the document sections to help work towards consensus on context before diving into more depth. We'll send out some suggestion on how this might work tomorrow. =20 Paul ------_=_NextPart_001_01C73431.5C1E25F0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Just = wanted to send=20 out an update to the WG to let you know the NEA Design Team has been = hard at=20 work (even over the holidays) creating the -00 requirements I-D = that we=20 could use as a starting point for our discussion.  We understand = this=20 doesn't reflect WG consensus at this point but wanted to provide = something=20 the group could review and use to help focus the discussions = to work=20 towards consensus.  We look forward to constructive discussions on = how to=20 fix its many errors ;).
 
Creating this=20 document during December was a significant challenge and required a real = time=20 commitment from the team to get this out by our early January = milestone. =20 I'd like to thank the other members of the design team (Hormuzd = Khosravi,=20 Mahalingam Mani, Kaushik Narayan, and Joe Tardo) for all their time = and=20 effort over a busy holiday filled month.  The result of our work=20 draft-ietf-nea-requirements-00.txt was submitted yesterday for = publication, so=20 we hope it will appear in the drafts directory later this week (or=20 next.)
 
The document is substantial is size (45 pages) = and=20 content (problem statement, applicability, reference model, = requirements,=20 ...) so it was our hope that when issued we could start a more = organized=20 e-review of the document sections to help work towards consensus on = context=20 before diving into more depth.  We'll send out some suggestion on = how this=20 might work tomorrow.
 
Paul
------_=_NextPart_001_01C73431.5C1E25F0-- --===============0775735290== 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 --===============0775735290==-- From nea-bounces@ietf.org Wed Jan 10 15:50:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4kPC-0003MJ-M9; Wed, 10 Jan 2007 15:50:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4kP3-00036M-KY; Wed, 10 Jan 2007 15:50:33 -0500 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H4kP3-0001C8-96; Wed, 10 Jan 2007 15:50:33 -0500 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id ECA9217619; Wed, 10 Jan 2007 20:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1H4kOY-0001Xu-HB; Wed, 10 Jan 2007 15:50:02 -0500 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 10 Jan 2007 15:50:02 -0500 X-Spam-Score: -2.5 (--) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: nea@ietf.org Subject: [Nea] I-D ACTION:draft-ietf-nea-requirements-00.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 : Requirements for Network Endpoint Assessment (NEA) Author(s) : P. Sangster, et al. Filename : draft-ietf-nea-requirements-00.txt Pages : 46 Date : 2007-1-10 This document defines the problem statement, scope and interface (protocol) requirements between the components of the NEA (Network Endpoint Assessment) reference model. NEA provides owners of networks (e.g. an enterprise offering remote access) a mechanism to evaluate the posture of a system. This may take place during the request for network access and/or subsequently at any time while connected to the network. The learned posture information can then be applied to a variety of compliance oriented decisions. The posture information is frequently useful for detecting systems that are lacking (or have out of date) security protective mechanisms (e.g. anti-virus, firewall.) In order to provide context for the requirements, a reference model and terminology are introduced. This model is provided for informational purposes but is based on the models used by NAC [CNAC], NAP[NAP] and TNC[TNC]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-nea-requirements-00.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-00.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-00.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-1-10112109.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-nea-requirements-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-nea-requirements-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-1-10112109.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea --NextPart-- From nea-bounces@ietf.org Wed Jan 10 15:58:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4kWQ-0002xs-62; Wed, 10 Jan 2007 15:58:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4kWO-0002wR-Np for nea@ietf.org; Wed, 10 Jan 2007 15:58:08 -0500 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4kWN-0007FN-8j for nea@ietf.org; Wed, 10 Jan 2007 15:58:08 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by borg.juniper.net with ESMTP; 10 Jan 2007 12:54:09 -0800 X-IronPort-AV: i="4.13,168,1167638400"; d="scan'208"; a="654092314:sNHT35787799220" X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Jan 2007 15:57:52 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Initial Discussion of the Requirements Draft Thread-index: Acc0+f6gclybHylvRL+Zv/ehamEcKg== From: "Stephen Hanna" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [Nea] Initial Discussion of the Requirements Draft X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Thanks to the design team that put together the first draft=20 of the NEA Requirements document. They accomplished a lot in=20 a very short period of time. They even worked through the=20 holidays. We appreciate their hard work. As noted earlier, this first draft of the NEA Requirements=20 document is just a basis for discussion. Now comes the most important part of the IETF process, discussing the document and (eventually) coming to rough consensus in the WG. Please help us start this process by reviewing the document promptly and sending your comments to the nea@ietf.org list. We expect that there will be considerable discussion on many=20 different topics. Instead of sending mammoth emails with many diverse comments, please break up your comments by section or topic and use good subject lines (like "Comments on Problem Statement" or "What About Endpoints That Don't Support NEA?") so threads hang together. Of course, a long email with many diverse comments may be appropriate for typos and other minor comments that probably won't need much discussion. Just use a subject line like "Typos" or some such. Section 7 of the document lists detailed requirements for the=20 protocols and section 6 provides detailed flows for use cases. Please ignore these sections for now. We need to agree on the Problem Statement, Applicability, Reference Model, and other sections before we start discussing details. So please concentrate on those sections (especially the Problem Statement, which is most basic). Thanks, Steve Hanna Susan Thomson _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Jan 10 23:16:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4rLq-0008UH-QM; Wed, 10 Jan 2007 23:15:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4rLo-0008M2-Mj for nea@ietf.org; Wed, 10 Jan 2007 23:15:40 -0500 Received: from www.deployingradius.com ([216.240.42.17] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4rLm-0007YA-AM for nea@ietf.org; Wed, 10 Jan 2007 23:15:40 -0500 Received: from [192.168.123.100] (bas1-ottawa23-1128766007.dsl.bell.ca [67.71.154.55]) by book.deployingradius.com (Postfix) with ESMTP id 638F6A71D5 for ; Wed, 10 Jan 2007 20:15:24 -0800 (PST) Message-ID: <45A5B908.7030503@deployingradius.com> Date: Wed, 10 Jan 2007 23:11:52 -0500 From: Alan DeKok User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: nea@ietf.org X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Nea] REQ: Abstract and Section 1 X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 abstract and introduction are long, and use terminology defined later in section 2. It seems that an assumption of the document is that people are already familiar with the models and terminology of NAP, NAC, TNC, etc. While that may be true for the draft authors, it would be best to have the introduction describe the space using more neutral terminology. Parts of the introduction are lifted directly from the charter. I'm not sure that's necessary. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Jan 10 23:26:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4rWG-0004Zx-3C; Wed, 10 Jan 2007 23:26:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4rWE-0004Zr-4H for nea@ietf.org; Wed, 10 Jan 2007 23:26:26 -0500 Received: from www.deployingradius.com ([216.240.42.17] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4rWC-0001dH-NL for nea@ietf.org; Wed, 10 Jan 2007 23:26:26 -0500 Received: from [192.168.123.100] (bas1-ottawa23-1128766007.dsl.bell.ca [67.71.154.55]) by book.deployingradius.com (Postfix) with ESMTP id 77DF3A71D5 for ; Wed, 10 Jan 2007 20:26:18 -0800 (PST) Message-ID: <45A5BB97.4090401@deployingradius.com> Date: Wed, 10 Jan 2007 23:22:47 -0500 From: Alan DeKok User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: nea@ietf.org X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Nea] REQ: Section 2 X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Each term is defined in a way that references the other pieces of the terminology, and assumes in passing the architecture, and a detailed familiarity with the architecture. I understand that there's a lot of terminology involved in describing the NEA architecture, but the sheer number of terms defined without minimal background makes the section very opaque. I suggest solving that problem by expanding section 1 to include a short introduction to the NEA architecture, with explanations of the actors and their roles. The terminology used there should be standard networking terms (client, server, request, response), to permit people without prior experience in NAC/NAP/NEA to understand the NEA document. One alternative would be to move Section 4 (problem statement) to above the terminology section. Perhaps a better alternative would be to split the document into a "model" document, and a "requirements" document. The model could serve as the introduction to NEA, and it would define the terminology for the space. The "requirements" document would then use those terms, and could assume that the reader has read the model. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Jan 10 23:51:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4ruL-0007ZJ-P0; Wed, 10 Jan 2007 23:51:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4ruK-0007ZE-2A for nea@ietf.org; Wed, 10 Jan 2007 23:51:20 -0500 Received: from www.deployingradius.com ([216.240.42.17] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4ruI-0005bV-9U for nea@ietf.org; Wed, 10 Jan 2007 23:51:20 -0500 Received: from [192.168.123.100] (bas1-ottawa23-1128766007.dsl.bell.ca [67.71.154.55]) by book.deployingradius.com (Postfix) with ESMTP id D65B6A71D5 for ; Wed, 10 Jan 2007 20:51:11 -0800 (PST) Message-ID: <45A5C16B.4080009@deployingradius.com> Date: Wed, 10 Jan 2007 23:47:39 -0500 From: Alan DeKok User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: nea@ietf.org X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Subject: [Nea] REQ: Section 3 X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 comments in Section 3.1 about lying endpoints should reference section 8.1.1, and state that the issue is dealt with in more detail there. Without additional explanation, the current text seems to be saying "we'll secure the system by asking it questions... but it can lie. Oh well." Adding a reference to the security section indicates that there may be mitigating circumstances. Much of Section 3.2 appears to directly contradict the charter. ... the use of NEA technologies may not apply in a variety of situations possible on the Internet The charter says that "NEA is applicable to computing enterprise environments, ... All other cases are outside the scope of the NEA charte= r," Therefore, this section discusses some of the scenarios where NEA is most likely to be applicable and some where it may not. No, the charter says that NEA is applicable only to certain scenarios. The requirements document MUST says that all non-charter scenarios are outside of the scope of the NEA applicability. The requirements document SHOULD say that the ISP, etc. scenarios are explicitely not being considered. The document SHOULD say that NEA SHOULD NOT be used in those scenarios. ... Environments where the Endpoint is owned by a party (possibly even the User) where the party has explicitly expressed a desire to conform to the policies established by a network or service provider No. The charter states that NEA is not applicable to the network provider or service provider market. This text can mislead the reader into believing that NEA is applicable to scenarios where the charter says it is not applicable. ... Conversely, some environments where NEA is not expected to be applicable would be environments where the Endpoint is owned by a User and has not agreed to conform to a network provider=EF=BF=BDs policies. This text (and other similar text) appears to confuse the issue of NEA or posture assesment with network access. If I choose to not conform with a network's policies by (say) not providing a correct password, the network provider will not permit me to access the network. This scenario should be explicitely mentioned in the document: You do not have to do NEA. You do not have to agree to the network owners policies. But the network owner does not have to give you access. i.e. It's confusing to say "NEA is not applicable" when some does not agree to use NEA. NEA *is* applicable if it meets the charter requirements, and the network owner demands that NEA be used. Instead, the document should say "NEA may be applicable, but MUST NOT be used if the Endpoint does not agree to an NEA protocol exchange". Text like that would simplify much of the discussion around the various scenarios. It would cover legacy systems not running NEA, systems running NEA but from a differing network, and systems running NEA where the owner of the endpoint chooses not to comply. ... 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=EF=BF=BDs laptop. No, that is forbidden by the charter. Privacy is not the issue. The charter states "... we do not know that NEA would be useful in such cases= ." i.e. Non-charter scenarios have many issues, some of which are unknown. Non-charter use of NEA is forbidden outright, and should not be discussed in the document other than to say it is forbidden. Other environments are more difficult to determine whether NEA is a good fit, so the NEA WG intends to steer clear of such areas. Again, it is forbidden by charter. Saying the WG has intentions is saying we might steer clear... or we might not. ... In particular environments where the Owners of the Endpoint, the network infrastructure and/or the network service provider are different and do not have a strong binding contract(s) establishing their expectations for conformance and willingness to disclose information to each other security policies. I'm not sure what that sentence is saying. Maybe a missing comma? ... In particular, environments where the Owners of the Endpoint, the network infrastructure and/or the network service provider are different and do not have a strong binding contract(s) establishing their expectations for conformance and willingness to disclose information to each other security policies. I suggest splitting the sentence into two or more shorter sentences. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Jan 11 00:18:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4sKn-0003cN-Fw; Thu, 11 Jan 2007 00:18:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4sKl-0003Xs-Qu for nea@ietf.org; Thu, 11 Jan 2007 00:18:39 -0500 Received: from www.deployingradius.com ([216.240.42.17] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4sKk-0003D9-2G for nea@ietf.org; Thu, 11 Jan 2007 00:18:39 -0500 Received: from [192.168.123.100] (bas1-ottawa23-1128765625.dsl.bell.ca [67.71.152.185]) by book.deployingradius.com (Postfix) with ESMTP id A0847A71D5 for ; Wed, 10 Jan 2007 21:18:31 -0800 (PST) Message-ID: <45A5C7D2.7050704@deployingradius.com> Date: Thu, 11 Jan 2007 00:14:58 -0500 From: Alan DeKok User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: nea@ietf.org X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Subject: [Nea] REQ: Section 4 X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org NEA technology may be used for several purposes. One use ... One use is documented, I can't find others. Maybe re-assesment? But that's just part of NEA, and not a different purpose. The purpose of NEA could be stated simply: knowing who is on the network, and knowing what they are running. (Since remediation is out of scope) Without NEA technology, ensuring compliance of Endpoints to corporate policy is a time-consuming and difficult task. What about normal OS updates, as Bernard pointed out? A toy idea for implementing NEA would be an software integrated with a client-side firewall that downloaded software updates every time the system connected to a network. I understand that much of the on-list discussion happened while the authors were busy writing the requirements document, but the points raised are serious enough to warrant a response from the authors. Is there *ever* a need in NEA for anything other than "get me all of the latest updates"? Why would a system *ever* ask for less than all of the updates? At most, I could see the updates being version dependent (updates for OS v1.2.3 versus OS v2.3.4). But once that information is propagated to the machine sourcing the updates, the next step is *still* "download all updates". ... With NEA technology, the network is able to assess an Endpoint as soon as it requests access to the network or at any time after joining the network So we're assuming that the network will control what software is running on the endpoint, but won't keep track of that information? Why bother asking the Endpoint what it has, when the network could simply consult it's database, and say "machine X isn't up to date", and then go tell it "download all of the latest updates". The assessment SHOULD NOT include querying. I have not seen a scenario where querying of endpoints is useful. In fact, querying is extremely inefficient, compared to simply telling the endpoint "download all updates". Of course, the net result of that design is that most of the complexity of NEA gets pushed into the remediation network, but that's not necessarily a bad thing. ... This provides the corporation an opportunity to monitor compliance I don't understand "monitor compliance". If a machine does NEA when it connects, it is compliant. If later changes mean a connected machine is no longer compliant to the new policy, the network MUST know, or MUST have a way to tell the machines to become compliant. "monitoring compliance" to me seems to indicate pro-active querying of machines, as in "are you still compliant?". Such querying is inefficient and unnecessary. The decision of how to handle non-compliant Endpoints can be made by the network administrator ... s/can/MUST/, or s/can/can only/ ... For example, re-assessment may be triggered by a NEA Client if a User disables a security application such as a host firewall on the Endpoint. I don't understand that. If the network policy says he MUST run a firewall, disabling the firewall MUST result in being kicked off of the network. I don't see why re-assessment is necessary: the user has declared he is no longer in compliance. ... Re- assessment also assists in keeping Endpoints connected to the network up to date with fixes and patches published by security application vendors. As opposed to simple downloads of the updates? It's a lot easier for many endpoints to periodically query a server, than it is for a server to poll many endpoints. Performing re-assessment to me indicates that NEA won't scale. ... Another use of NEA technology may be to supplement information in inventory databases. Is this a charter goal? If not, why are we discussing it? NEA *may* result in additional information being available to the network admin, but the maintenance and use of that information is out of scope of NEA. ... In organizations that attempt to keep track of their assets, inventory databases tend to be incomplete and out-of-date. NEA technology may be used to verify or supplement information stored about an organization's assets. I suggest deleting that text entirely. ... NEA technology can also be used to monitor and report compliance for Endpoints when they try to access certain mission critical applications within an enterprise by employing application triggered Assessment. Why? The endpoint knows what posture it satisfies, and the network admin knows the same thing if he caches the posture assessment from the initial network access. If the application knows what posture it requires, why ask the potentially compromised host, when can instead ask a trusted source: the network admin? This approach could also catch the case of lying endpoints. If the network determines that an endpoint is lying (i.e. by observing network traffic), it can update it's view of the endpoints posture, and inform others on the network that the device is not to be trusted. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Jan 11 00:44:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4sju-0006QH-9p; Thu, 11 Jan 2007 00:44:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4sjs-0006QC-OR for nea@ietf.org; Thu, 11 Jan 2007 00:44:36 -0500 Received: from outbound-mail.lax.untd.com ([64.136.28.164]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H4sjq-0001Ou-AW for nea@ietf.org; Thu, 11 Jan 2007 00:44:36 -0500 Received: from webmail07.lax.untd.com (webmail07.lax.untd.com [10.131.27.147]) by smtpout04.lax.untd.com with SMTP id AABC4MVWTAH2XQXS for (sender ); Wed, 10 Jan 2007 21:43:45 -0800 (PST) X-UNTD-OriginStamp: AcganUYbgVGZ0C6nm/9IPatablCmMCeKfJmiJG6sSSIHzgc0QSvhYw== Received: (from fergdawg@netzero.net) by webmail07.lax.untd.com (jqueuemail) id MBSHYGDW; Wed, 10 Jan 2007 21:43:21 PST Received: from [24.23.201.115] by webmail07.lax.untd.com with HTTP: Thu, 11 Jan 2007 05:42:28 GMT X-Originating-IP: [24.23.201.115] Mime-Version: 1.0 From: "Fergie" Date: Thu, 11 Jan 2007 05:42:28 GMT To: aland@deployingradius.com Subject: Re: [Nea] REQ: Section 3 X-Mailer: Webmail Version 4.0 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Content-Type: text/plain Message-Id: <20070110.214321.808.1025882@webmail07.lax.untd.com> X-ContentStamp: 8:4:1692011944 X-MAIL-INFO: 5dcf9b3b5a379b373713cf77f7070fe7e72b7ffee7a767f77b8f4303e3fbfb9bdbbfba3b X-UNTD-Peer-Info: 10.131.27.147|webmail07.lax.untd.com|webmail07.lax.untd.com|fergdawg@netzero.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Alan DeKok wrote: >The comments in Section 3.1 about lying endpoints should reference >section 8.1.1, and state that the issue is dealt with in more detail >there. Without additional explanation, the current text seems to be >saying "we'll secure the system by asking it questions... but it can >lie. Oh well." Adding a reference to the security section indicates >that there may be mitigating circumstances. > [many good comments elided] Yes, I agree -- I was going to point out a couple of these myself, as several things appear to be contradictory to one another... - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.5.2 (Build 4075) wj8DBQFFpc45q1pz9mNUZTMRApvMAJ9I6Lb0DbQiQoAlu8NA56B1fpwZtwCg9s6A SJQqK458jGZs+XF0GHxSfX0=3D =3DK9yx -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Jan 11 03:56:58 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4vjq-0003Je-6P; Thu, 11 Jan 2007 03:56:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H4vjo-0003JJ-HT for nea@ietf.org; Thu, 11 Jan 2007 03:56:44 -0500 Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H4vjl-00043q-S0 for nea@ietf.org; Thu, 11 Jan 2007 03:56:44 -0500 Received: from mail2.siemens.de (localhost [127.0.0.1]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id l0B8ua4R014664; Thu, 11 Jan 2007 09:56:36 +0100 Received: from mchp771a.ww002.siemens.net (mchp771a.ww002.siemens.net [139.25.131.189]) by mail2.siemens.de (8.12.6/8.12.6) with ESMTP id l0B8uaIR003975; Thu, 11 Jan 2007 09:56:36 +0100 Received: from MCHP7R6A.ww002.siemens.net ([139.25.131.164]) by mchp771a.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 09:56:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: AW: [Nea] draft-ietf-nea-requirements-00.txt submitted Date: Thu, 11 Jan 2007 09:56:35 +0100 Message-ID: <6F0CB04509C11D46A54232E852E390AC0257A6C7@MCHP7R6A.ww002.siemens.net> In-Reply-To: <5A58F967CBEBBB4A82DF126CF8A9596A021B8E5C@SVL1XCHCLUPIN02.enterprise.veritas.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] draft-ietf-nea-requirements-00.txt submitted Thread-Index: Acc0MVvYE9xCLHQpTyWi8MW3lRKTJwBLOELw From: "Tschofenig, Hannes" To: "Paul Sangster" , X-OriginalArrivalTime: 11 Jan 2007 08:56:36.0270 (UTC) FILETIME=[664A6CE0:01C7355E] X-Spam-Score: 0.1 (/) X-Scan-Signature: 29dc808194f5fb921c09d0040806d6eb 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="===============1804093271==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============1804093271== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7355E.6600E591" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7355E.6600E591 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The work of a design team has to be approved by the working group before it becomes a working group document.=20 =20 Has this happened? I have never seen a hum.=20 =20 Ciao Hannes =20 ________________________________ Von: Paul Sangster [mailto:Paul_Sangster@symantec.com]=20 Gesendet: Dienstag, 9. Januar 2007 22:02 An: nea@ietf.org Betreff: [Nea] draft-ietf-nea-requirements-00.txt submitted =09 =09 Just wanted to send out an update to the WG to let you know the NEA Design Team has been hard at work (even over the holidays) creating the -00 requirements I-D that we could use as a starting point for our discussion. We understand this doesn't reflect WG consensus at this point but wanted to provide something the group could review and use to help focus the discussions to work towards consensus. We look forward to constructive discussions on how to fix its many errors ;). =20 Creating this document during December was a significant challenge and required a real time commitment from the team to get this out by our early January milestone. I'd like to thank the other members of the design team (Hormuzd Khosravi, Mahalingam Mani, Kaushik Narayan, and Joe Tardo) for all their time and effort over a busy holiday filled month. The result of our work draft-ietf-nea-requirements-00.txt was submitted yesterday for publication, so we hope it will appear in the drafts directory later this week (or next.) =20 The document is substantial is size (45 pages) and content (problem statement, applicability, reference model, requirements, ...) so it was our hope that when issued we could start a more organized e-review of the document sections to help work towards consensus on context before diving into more depth. We'll send out some suggestion on how this might work tomorrow. =20 Paul ------_=_NextPart_001_01C7355E.6600E591 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The work of a design team has to be approved by = the working=20 group before it becomes a working group document.
 
Has this happened? I have never seen a hum.=20
 
Ciao
Hannes
 

Von: Paul Sangster=20 [mailto:Paul_Sangster@symantec.com]
Gesendet: Dienstag, 9. = Januar=20 2007 22:02
An: nea@ietf.org
Betreff: [Nea]=20 draft-ietf-nea-requirements-00.txt submitted

Just = wanted to=20 send out an update to the WG to let you know the NEA Design Team has = been hard=20 at work (even over the holidays) creating the -00 requirements = I-D that=20 we could use as a starting point for our discussion.  We = understand this=20 doesn't reflect WG consensus at this point but wanted to provide=20 something the group could review and use to help focus the discussions = to work towards consensus.  We look forward to constructive=20 discussions on how to fix its many errors ;).
 
Creating this=20 document during December was a significant challenge and required a = real time=20 commitment from the team to get this out by our early January = milestone. =20 I'd like to thank the other members of the design team (Hormuzd = Khosravi,=20 Mahalingam Mani, Kaushik Narayan, and Joe Tardo) for all their = time and=20 effort over a busy holiday filled month.  The result of our work=20 draft-ietf-nea-requirements-00.txt was submitted yesterday for = publication, so=20 we hope it will appear in the drafts directory later this week (or=20 next.)
 
The document is substantial = is size (45=20 pages) and content (problem statement, applicability, reference model, = requirements, ...) so it was our hope that when issued we could = start a=20 more organized e-review of the document sections to help work towards=20 consensus on context before diving into more depth.  We'll send = out some=20 suggestion on how this might work tomorrow.
 
Paul
------_=_NextPart_001_01C7355E.6600E591-- --===============1804093271== 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 --===============1804093271==-- From nea-bounces@ietf.org Thu Jan 11 11:49:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5378-00040X-6D; Thu, 11 Jan 2007 11:49:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H536j-0003bX-TL for nea@ietf.org; Thu, 11 Jan 2007 11:48:53 -0500 Received: from www.deployingradius.com ([216.240.42.17] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H531x-0006M5-2f for nea@ietf.org; Thu, 11 Jan 2007 11:44:04 -0500 Received: from [192.168.123.100] (bas1-ottawa23-1128678796.dsl.bell.ca [67.70.69.140]) by book.deployingradius.com (Postfix) with ESMTP id 1686FA71D5 for ; Thu, 11 Jan 2007 08:43:46 -0800 (PST) Message-ID: <45A6686A.5050608@deployingradius.com> Date: Thu, 11 Jan 2007 11:40:10 -0500 From: Alan DeKok User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: nea@ietf.org X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Subject: [Nea] REQ: Section 5, why is this here? X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org I think the document is out of order. The reference model is described BEFORE the requirements in Section 7. And the requirements in Section 7 use the terminology and model from Section 5. My understanding of a requirements document is that it would detail requirements, rather than a detailed model. The charter does have a limited architecture description, but it is significantly simpler than what is in Section 5. In addition, the charter says: The NEA Requirements document will include a problem statement, definition of terms, requirements for the PA and PB protocols, and an overall security analysis. I read this to mean that the requirements document should list the requirements to solve the problem statement, and not include a detailed solution. Instead, the requirements document lists the requirements for implementing a particular solution to the problem statement. In other words, the problem statement is about network administrators, machines, and end users. I would expect that the document cover at least requirements that those parties have. I see no such list of requirements in the document. We therefore have no idea whether or not the model described in section 5 actually satisfies the problem statement. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Jan 11 12:37:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H53rx-0004hH-HJ; Thu, 11 Jan 2007 12:37:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H53ru-0004f0-PO for nea@ietf.org; Thu, 11 Jan 2007 12:37:38 -0500 Received: from extu-mxob-2.symantec.com ([216.10.194.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H53nx-0008Qf-0z for nea@ietf.org; Thu, 11 Jan 2007 12:33:35 -0500 Received: from extu-mxob-2.symantec.com (unknown [127.0.0.1]) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id 2AAC538C368; Thu, 11 Jan 2007 09:38:40 -0800 (PST) X-AuditID: d80ac287-98a9bbb000005dd5-71-45a6761fd3a9 Received: from tus1opsmtapin02.ges.symantec.com (tus1opsmtapin02.ges.symantec.com [192.168.214.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id EA73F348003; Thu, 11 Jan 2007 09:38:39 -0800 (PST) Received: from [10.137.18.178] (helo=SVL1XCHECNPIN01.enterprise.veritas.com) by tus1opsmtapin02.ges.symantec.com with esmtp (Exim 4.52) id 1H53wo-00018s-9f; Thu, 11 Jan 2007 09:42:42 -0800 Received: from SVL1XCHEVSPIN01.enterprise.veritas.com ([166.98.169.12]) by SVL1XCHECNPIN01.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 09:33:29 -0800 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] REQ: Abstract and Section 1 Date: Thu, 11 Jan 2007 09:33:28 -0800 Message-ID: <5A58F967CBEBBB4A82DF126CF8A9596A021EB18A@SVL1XCHCLUPIN02.enterprise.veritas.com> In-Reply-To: <45A5B908.7030503@deployingradius.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] REQ: Abstract and Section 1 Thread-Index: Acc1N0KuTEVltrR4QfKQRlhLgEVdwAAaanPQ From: "Paul Sangster" To: "Alan DeKok" , X-OriginalArrivalTime: 11 Jan 2007 17:33:29.0838 (UTC) FILETIME=[9BD158E0:01C735A6] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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 many sets of comments organized by section. I presume the bulk of this thread is about the introduction. We tried to keep the use of terminology to a minimum but are happy to reduce it even further (some of the use of capitalization is a bug.) Maybe you could help us spot the words whose more generic meeting do not fit the text (without clearer definition as per the terminology section.) Comments below... > -----Original Message----- > From: Alan DeKok [mailto:aland@deployingradius.com]=20 > Sent: Wednesday, January 10, 2007 8:12 PM > To: nea@ietf.org > Subject: [Nea] REQ: Abstract and Section 1 >=20 > The abstract and introduction are long, and use terminology=20 > defined later in section 2. It seems that an assumption of Upon review of the abstract, we used "posture" in several places would the abstract be clear enough if we used a different word or phrase (e.g. "system configuration")?=20 In the introduction: P3 contains "Posture" and "Validator" which could be replaced P4 contains "Endpoint" and "Assessment" which should be lower case. - hopefully these words are generic enough for use in the intro but we could select alternatives if desired Are their other words whose generic definition are insufficient to use so early in the document? At a minimum the P3 and P4 words should not be capitalized (thus referring to a term not yet defined.) =20 > the document is that people are already familiar with the=20 > models and terminology of NAP, NAC, TNC, etc. While that may=20 > be true for the draft authors, it would be best to have the=20 > introduction describe the space using more neutral terminology. Agreed we want the intro to use neutral terminology. The only word I see that is commonly associated with NAP, NAC or TNC is "Posture" and possibly "admission." These word seemed useful as its traditional meaning is in line with our usage in the document but possibly not before its been defined as a NEA term (which might differ from NAC.) As for the models of the other architectures, I would hope the NEA Requirements spec could create enough context that it could stand alone and just reference prior work (like any paper) that might be relevant for background and to show the discussion is based on understood approaches and not starting from scratch. The text in earlier paragraphs (particularly 3,4) tried to describe in neutral way the general model common to those existing technologies. The word Validator needs to be replaced or augmented with some text though. >=20 > Parts of the introduction are lifted directly from the=20 > charter. I'm not sure that's necessary. The goal was creating some readible text so lifting text from other documents was likely because it was well written. If the text is a problem we could fix it, I agree we don't need to repeat the charter. >=20 > Alan DeKok. > -- > http://deployingradius.com - The web site of the book > http://deployingradius.com/blog/ - The blog >=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 Jan 11 12:50:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H544g-0003fX-Lg; Thu, 11 Jan 2007 12:50:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H544e-0003bl-M9 for nea@ietf.org; Thu, 11 Jan 2007 12:50:48 -0500 Received: from excu-mxob-1.symantec.com ([198.6.49.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H544c-00034u-87 for nea@ietf.org; Thu, 11 Jan 2007 12:50:48 -0500 Received: from excu-mxob-1.symantec.com (unknown [127.0.0.1]) by excu-mxob-1.symantec.com (Symantec Mail Security) with ESMTP id 7043113035E; Thu, 11 Jan 2007 09:57:53 -0800 (PST) X-AuditID: c606310c-9cc9cbb0000048e2-f1-45a67aa19841 Received: from tus1opsmtapin02.ges.symantec.com (tus1opsmtapin02.ges.symantec.com [192.168.214.44]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by excu-mxob-1.symantec.com (Symantec Mail Security) with ESMTP id 3048AEC003; Thu, 11 Jan 2007 09:57:53 -0800 (PST) Received: from [10.137.18.178] (helo=SVL1XCHECNPIN01.enterprise.veritas.com) by tus1opsmtapin02.ges.symantec.com with esmtp (Exim 4.52) id 1H54DT-00031Z-Fj; Thu, 11 Jan 2007 09:59:55 -0800 Received: from SVL1XCHEVSPIN01.enterprise.veritas.com ([166.98.169.12]) by SVL1XCHECNPIN01.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 09:50:42 -0800 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] REQ: Section 5, why is this here? Date: Thu, 11 Jan 2007 09:50:40 -0800 Message-ID: <5A58F967CBEBBB4A82DF126CF8A9596A021EB1BB@SVL1XCHCLUPIN02.enterprise.veritas.com> In-Reply-To: <45A6686A.5050608@deployingradius.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] REQ: Section 5, why is this here? Thread-Index: Acc1oIEjRLuCPY/qR3CIoAU34WjEewABmURA From: "Paul Sangster" To: "Alan DeKok" , X-OriginalArrivalTime: 11 Jan 2007 17:50:42.0872 (UTC) FILETIME=[038DD380:01C735A9] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Comments below...=20 > -----Original Message----- > From: Alan DeKok [mailto:aland@deployingradius.com]=20 > Sent: Thursday, January 11, 2007 8:40 AM > To: nea@ietf.org > Subject: [Nea] REQ: Section 5, why is this here? >=20 > I think the document is out of order. The reference model=20 > is described BEFORE the requirements in Section 7. And the=20 > requirements in Section 7 use the terminology and model from=20 > Section 5. The reference model described is provided to establish context and additional terminology (some terms can't be described in a few sentences.) This model is not an implementation model nor architecture. I believe the NEA WG showed support for this model at the San Diego meeting (and was discussed at the BOFs) so was adopted to help establish context for the requirements. If the model is found to be overly restrictive for describing the context we could change it. I'll note that this model is sufficently general that it seems to accommodate the existing NAP, NAC and TNC approaches collectively which have very different implementations. >=20 > My understanding of a requirements document is that it=20 > would detail requirements, rather than a detailed model. The=20 > charter does have a limited architecture description, but it=20 > is significantly simpler than what is in Section 5. >=20 > In addition, the charter says: >=20 > The NEA Requirements document will include a problem statement, > definition of terms, requirements for the PA and PB=20 > protocols, and an > overall security analysis. >=20 > I read this to mean that the requirements document should=20 > list the requirements to solve the problem statement, and not=20 > include a detailed solution. Instead, the requirements=20 > document lists the requirements for implementing a particular=20 > solution to the problem statement. I don't believe the document provides a detailed solution (see above.) If we find that the model is so detailed it interferes with our ability to express and describe the desired requirements we could change it to be more general. We wouldn't want the model to cause confusion to the WG during candidate protocol selection (based on the requirements.) >=20 > In other words, the problem statement is about network=20 > administrators, machines, and end users. I would expect that=20 > the document cover at least requirements that those parties=20 > have. I see no such list of requirements in the document. =20 > We therefore have no idea whether or not the model described=20 > in section 5 actually satisfies the problem statement. As per chair direction, we'll get to the requirements after we better clarify the context setting sections. I will point out that we're expressing requirements for protocols in those sections so one might expect those requirements to reflect things visible at the those protocol layers. >=20 > Alan DeKok. > -- > http://deployingradius.com - The web site of the book > http://deployingradius.com/blog/ - The blog >=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 Jan 11 13:48:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H54yS-0003M1-PL; Thu, 11 Jan 2007 13:48:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H54yP-0003GJ-UA for nea@ietf.org; Thu, 11 Jan 2007 13:48:25 -0500 Received: from www.deployingradius.com ([216.240.42.17] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H54vz-0007yY-BK for nea@ietf.org; Thu, 11 Jan 2007 13:45:58 -0500 Received: from [192.168.123.100] (bas1-ottawa23-1128678604.dsl.bell.ca [67.70.68.204]) by book.deployingradius.com (Postfix) with ESMTP id 1133CA71D5; Thu, 11 Jan 2007 10:45:50 -0800 (PST) Message-ID: <45A68509.3090902@deployingradius.com> Date: Thu, 11 Jan 2007 13:42:17 -0500 From: Alan DeKok User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Paul Sangster Subject: Re: [Nea] REQ: Section 5, why is this here? References: <5A58F967CBEBBB4A82DF126CF8A9596A021EB1BB@SVL1XCHCLUPIN02.enterprise.veritas.com> In-Reply-To: <5A58F967CBEBBB4A82DF126CF8A9596A021EB1BB@SVL1XCHCLUPIN02.enterprise.veritas.com> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Paul Sangster wrote: > The reference model described is provided to establish context and > additional terminology (some terms can't be described in a few > sentences.) This model is not an implementation model nor architecture. I understand. Many network protocols involve nothing more than a client-server relationship, so there's little need for a model or for architecture diagrams. NEA is more complicated, so there's more need to describe the model in detail. However, the detail of this model will strongly influence the choice of architecture. > I believe the NEA WG showed support for this model at the San Diego > meeting (and was discussed at the BOFs) so was adopted to help establish > context for the requirements. The people proposing the model at San Diego supported it, but the minutes show a number of questions surrounding the model. Prior discussion on the mailing list raised a number of questions that this document does not address. The requirements draft authors have *not* been significantly involved in the detailed discussions, either before or after they were chosen to be authors of the draft. This means that there has been little overlap between discussions on the list, and this document. The WG needs consensus, and it needs active participation on the list. > If the model is found to be overly restrictive for describing the > context we could change it. I'll note that this model is sufficently > general that it seems to accommodate the existing NAP, NAC and TNC > approaches collectively which have very different implementations. My concern is not about the restrictiveness or the utility of the model. My concern is that the model has been dropped as-is into the requirements document, with little discussion or justification. As such, there is no reason apparent in the document for choosing that model. Anyone reading the document cannot understand why that model was chosen. > As per chair direction, we'll get to the requirements after we better > clarify the context setting sections. The model is a presented as a requirement, because there is no apparent reason for choosing that model. There is therefore no context apparent for the model, other than it's self-definition. > I will point out that we're > expressing requirements for protocols in those sections so one might > expect those requirements to reflect things visible at the those > protocol layers. Yes, however the problem statement does *not* involve the complexity and number of participants that are presented in the model. I would therefore appreciate additional text in the document detailing where the model came from, and how it satisfies the high-level problem statement. I would also appreciate the requirements document addressing the issues raised on the list in the last few months. I will try to detail those in a separate message or document. Again, protocols are simply a means to an end. We can define any number of complex models and scenarios, and then determine requirements for the related protocols. But that doesn't mean those models will be applicable to the real world, and it doesn't mean the protocols will be useful to anyone. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Jan 11 14:54:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H560T-0000u0-LO; Thu, 11 Jan 2007 14:54:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H560S-0000rP-5R for nea@ietf.org; Thu, 11 Jan 2007 14:54:36 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H560P-0001pF-Ks for nea@ietf.org; Thu, 11 Jan 2007 14:54:36 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 11 Jan 2007 11:54:33 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l0BJsXm2002433; Thu, 11 Jan 2007 11:54:33 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l0BJsNnZ003841; Thu, 11 Jan 2007 11:54:33 -0800 (PST) Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 11:54:28 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [Nea] REQ: Section 4 Date: Thu, 11 Jan 2007 11:54:26 -0800 Message-ID: <618694EF0B657246A4D55A97E38274C302CE70B3@xmb-sjc-22d.amer.cisco.com> In-Reply-To: <45A5C7D2.7050704@deployingradius.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] REQ: Section 4 Thread-Index: Acc1QAkjOe7gACPuQEOR2Yw+2HdKFwAcuFXA From: "Kaushik Narayan \(kaushik\)" To: "Alan DeKok" , X-OriginalArrivalTime: 11 Jan 2007 19:54:28.0206 (UTC) FILETIME=[4D65E0E0:01C735BA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=9151; t=1168545273; x=1169409273; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kaushik@cisco.com; z=From:=20=22Kaushik=20Narayan=20\(kaushik\)=22=20 |Subject:=20RE=3A=20[Nea]=20REQ=3A=20Section=204 |Sender:=20; bh=W1THr6SNezi4M7EFL47NpihsqMBJlMpNnq9e+Pa8qyE=; b=n8Hi5GtVv9fzfQ9o7jEy86DMpZLj/X8yNl0Ok+fulSZ44KLe11O/w5uHw0dOMhZKebJU6iiF ecSysdh3cqqDipM/a3vZNigXTD0up2JqeSjuqHzXUOViOjVgyp1RxAC+; Authentication-Results: sj-dkim-7; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba 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 Alan, Thanks for your comments. Please find my response inline.=20 -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com]=20 Sent: Wednesday, January 10, 2007 9:15 PM To: nea@ietf.org Subject: [Nea] REQ: Section 4 NEA technology may be used for several purposes. One use ... One use is documented, I can't find others. Maybe re-assesment? But that's just part of NEA, and not a different purpose. The purpose of NEA could be stated simply: knowing who is on the network, and knowing what they are running. (Since remediation is out of scope) The use cases provide further detail about the usage of NEA technology,the primary driver is assessment but deployments can use an incremental approach; for e.g. certain deployments might start with endpoint detection and creation of an inventory of endpoints before they start to apply policies for assessment. This usage of NEA was discussed during the last IETF meeting. Without NEA technology, ensuring compliance of Endpoints to corporate policy is a time-consuming and difficult task. What about normal OS updates, as Bernard pointed out? A toy idea for implementing NEA would be an software integrated with a client-side firewall that downloaded software updates every time the system connected to a network. I understand that much of the on-list discussion happened while the authors were busy writing the requirements document, but the points raised are serious enough to warrant a response from the authors. Is there *ever* a need in NEA for anything other than "get me all of the latest updates"? Why would a system *ever* ask for less than all of the updates? At most, I could see the updates being version dependent (updates for OS v1.2.3 versus OS v2.3.4). But once that information is propagated to the machine sourcing the updates, the next step is *still* "download all updates". =20 I am not sure this statement really constraints the use of NEA; it is conceivable that deployments have security policies around OS versions and patch levels. However I would like to point out that general purpose software distribution is not intended to a primary driver for NEA and there are other technologies that deal with problem of patch management. ... With NEA technology, the network is able to assess an Endpoint as soon as it requests access to the network or at any time after joining the network So we're assuming that the network will control what software is running on the endpoint, but won't keep track of that information? Why bother asking the Endpoint what it has, when the network could simply consult it's database, and say "machine X isn't up to date", and then go tell it "download all of the latest updates". The assessment SHOULD NOT include querying. I have not seen a scenario where querying of endpoints is useful. In fact, querying is extremely inefficient, compared to simply telling the endpoint "download all updates". Of course, the net result of that design is that most of the complexity of NEA gets pushed into the remediation network, but that's not necessarily a bad thing. =20 I think there is a fundamental assumption in your statement that all assessment use cases are tied to software updates, that's certainly not true. There might compliance policies dealing with certain applications such as host firewalls, P2P applications being enabled/disabled on endpoints that are admitted to the network, in such a scenario the NEA server is required to request endpoint with specific Posture Attributes that deal with such applications.=20 I am not sure of your statement that "the network won't keep track of the information about a prior assessment", we have described the use of assertions as a means to re-use information from prior assessments. ... This provides the corporation an opportunity to monitor compliance I don't understand "monitor compliance". If a machine does NEA when it connects, it is compliant. If later changes mean a connected machine is no longer compliant to the new policy, the network MUST know, or MUST have a way to tell the machines to become compliant. "monitoring compliance" to me seems to indicate pro-active querying of machines, as in "are you still compliant?". Such querying is inefficient and unnecessary. =20 The term "monitor compliance" does not intend to convey that the network is actively polling the endpoint. It is intended to cover the use case wherein the reassessment can be triggered while the endpoint is connected to the network either via a trigger from the NEA client or the NEA server. There are use cases are described in section 6.2.1 and 6.2.2 We will try to use an alternative term. The decision of how to handle non-compliant Endpoints can be made by the network administrator ... s/can/MUST/, or s/can/can only/ ... For example, re-assessment may be triggered by a NEA Client if a User disables a security application such as a host firewall on the Endpoint. I don't understand that. If the network policy says he MUST run a firewall, disabling the firewall MUST result in being kicked off of the network. I don't see why re-assessment is necessary: the user has declared he is no longer in compliance. =20 The disabling of the firewall represents a change in posture, the NEA server is required to assess the compliance of the endpoint in the light of the modified posture which is why reassessment is necessary. The network access layer (which is out of scope for NEA discussions) may use the decision of the reassessment to implement a policy to boot the user from the network.=20 Section 6.2.1 describes such a use case. =20 ... Re- assessment also assists in keeping Endpoints connected to the network up to date with fixes and patches published by security application vendors. As opposed to simple downloads of the updates? It's a lot easier for many endpoints to periodically query a server, than it is for a server to poll many endpoints. =20 The document describes two models of reassessment, i.e. NEA client triggered and NEA server triggered, it is upto deployments to determine the most optimum mechanism to employ. Performing re-assessment to me indicates that NEA won't scale. ... Another use of NEA technology may be to supplement information in inventory databases. Is this a charter goal? If not, why are we discussing it? NEA *may* result in additional information being available to the network admin, but the maintenance and use of that information is out of scope of NEA. =20 The text purely reflecting a usage of NEA technology to detect endpoints and supplement inventory information. I don't think the text intends to suggest that the NEA will describe the definition and maintaince of inventory databases. Building an inventory of endpoints is an important pre-cursor in enterprise deployments of NEA technology.=20 ... In organizations that attempt to keep track of their assets, inventory databases tend to be incomplete and out-of-date. NEA technology may be used to verify or supplement information stored about an organization's assets. I suggest deleting that text entirely. Please refer to above comment=20 ... NEA technology can also be used to monitor and report compliance for Endpoints when they try to access certain mission critical applications within an enterprise by employing application triggered Assessment. Why? The endpoint knows what posture it satisfies, and the network admin knows the same thing if he caches the posture assessment from the initial network access. If the application knows what posture it requires, why ask the potentially compromised host, when can instead ask a trusted source: the network admin? This approach could also catch the case of lying endpoints. If the network determines that an endpoint is lying (i.e. by observing network traffic), it can update it's view of the endpoints posture, and inform others on the network that the device is not to be trusted. =20 This text is not intended to suggest the exchange of posture information between the NEA server and applications. This text covers use cases wherein assessment can be triggered when Layer 5-7 services are accessed; Section 6.1.2 provides an example of this use case. Regards, kaushik Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Jan 11 16:14:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H57G4-0006JD-JC; Thu, 11 Jan 2007 16:14:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H57G3-0006Ic-GI for nea@ietf.org; Thu, 11 Jan 2007 16:14:47 -0500 Received: from extu-mxob-2.symantec.com ([216.10.194.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H57F8-00052x-0r for nea@ietf.org; Thu, 11 Jan 2007 16:14:47 -0500 Received: from extu-mxob-2.symantec.com (unknown [127.0.0.1]) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id 4315538C135; Thu, 11 Jan 2007 13:19:01 -0800 (PST) X-AuditID: d80ac287-9f4cabb000005dd5-71-45a6a9c567ff Received: from tus1opsmtapin01.ges.symantec.com (tus1opsmtapin01.ges.symantec.com [192.168.214.43]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by extu-mxob-2.symantec.com (Symantec Mail Security) with ESMTP id F30D5348002; Thu, 11 Jan 2007 13:19:00 -0800 (PST) Received: from [10.137.18.178] (helo=SVL1XCHECNPIN01.enterprise.veritas.com) by tus1opsmtapin01.ges.symantec.com with esmtp (Exim 4.52) id 1H57Fb-0000b4-BR; Thu, 11 Jan 2007 13:14:19 -0800 Received: from SVL1XCHEVSPIN01.enterprise.veritas.com ([166.98.169.12]) by SVL1XCHECNPIN01.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 13:13:38 -0800 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] REQ: Section 3 Date: Thu, 11 Jan 2007 13:13:37 -0800 Message-ID: <5A58F967CBEBBB4A82DF126CF8A9596A021EB4B4@SVL1XCHCLUPIN02.enterprise.veritas.com> In-Reply-To: <45A5C16B.4080009@deployingradius.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] REQ: Section 3 Thread-Index: Acc1PDdazmbb4IhDRxuVsKSEIX1dTwAguJsg From: "Paul Sangster" To: "Alan DeKok" , X-OriginalArrivalTime: 11 Jan 2007 21:13:38.0028 (UTC) FILETIME=[5C8332C0:01C735C5] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186 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 =20 > -----Original Message----- > From: Alan DeKok [mailto:aland@deployingradius.com]=20 > Sent: Wednesday, January 10, 2007 8:48 PM > To: nea@ietf.org > Subject: [Nea] REQ: Section 3 >=20 > The comments in Section 3.1 about lying endpoints should=20 > reference section 8.1.1, and state that the issue is dealt=20 > with in more detail there. Without additional explanation,=20 > the current text seems to be saying "we'll secure the system=20 > by asking it questions... but it can lie. Oh well." Adding=20 > a reference to the security section indicates that there may=20 > be mitigating circumstances. Adding a reference makes sense. As you know this section just describes our specified scope so we need to say this is out of scope since a reader might expect otherwise, but I agree its useful to reference 8.1.1 that might provide additive approaches to addressing the issue. >=20 > Much of Section 3.2 appears to directly contradict the charter. >=20 > ... the use of NEA > technologies may not apply in a variety of situations possible > on the Internet >=20 > The charter says that "NEA is applicable to computing=20 > enterprise environments, ... All other cases are outside the=20 > scope of the NEA charter," If we look at the "..." text that wasn't included we might find how some of the other text made it into -00. The charter actually says: "NEA is applicable to computing enterprise environments, where endpoints accessing the enterprise's network are owned and/or expected to conform to the policies set forth by the organization that owns and operates the network." For -00 it seemed reasonable to talk about both sides of the "and/or" so the WG could decide whether to allow it to remain. Please note the "or expected to conform to the policies set forth by the organization" phrase. We certainly welcome dialog on whether the spec went to far (or not far enough) in this regard. With this in mind, we should discuss which scenarios discussed as in-scope are considered out of scope by WG consensus so we can update the spec. =20 Does the WG believe we should not claim that scenarios where the Endpoint is Owned by a different party then the Owner of the network must always be out of scope? We could decide this, but I do not see this as a hard rule in the charter as long as the Owner of the Endpoint establishes is "expected to conform to the policies set forth by the organization that owns and operates the network." Thoughts? >=20 > Therefore, this section discusses some of > the scenarios where NEA is most likely to be applicable and > some where it may not. >=20 > No, the charter says that NEA is applicable only to certain=20 > scenarios. > The requirements document MUST says that all non-charter=20 > scenarios are outside of the scope of the NEA applicability.=20 See above. =20 > The requirements document SHOULD say that the ISP, etc.=20 > scenarios are explicitely not being considered. The document=20 > SHOULD say that NEA SHOULD NOT be used in those scenarios. The text gives an ISP oriented example in paragraph 4 and says "NEA is not expected to be applicable" We could consider making the language stronger if necessary. >=20 > ... Environments where > the Endpoint is owned by a party (possibly even the User) > where the party has explicitly expressed a desire to conform > to the policies established by a network or service provider >=20 > No. The charter states that NEA is not applicable to the=20 > network provider or service provider market. This text can=20 > mislead the reader into believing that NEA is applicable to=20 > scenarios where the charter says it is not applicable. See above. >=20 > ... Conversely, some environments where NEA is not=20 > expected to be > applicable would be environments where the Endpoint is owned > by a User and has not agreed to conform to a network > provider s policies. >=20 > This text (and other similar text) appears to confuse the=20 > issue of NEA or posture assesment with network access. If I=20 > choose to not conform with a network's policies by (say) not=20 > providing a correct password, the network provider will not=20 > permit me to access the network. This scenario should be=20 > explicitely mentioned in the document: You do not have to do=20 > NEA. You do not have to agree to the network owners=20 > policies. But the network owner does not have to give you access. This is mentioned in several places in the document, but we could add a phrase here if it helps. >=20 > i.e. It's confusing to say "NEA is not applicable" when=20 > some does not agree to use NEA. NEA *is* applicable if it=20 > meets the charter requirements, and the network owner demands=20 > that NEA be used. Instead, the document should say "NEA may=20 > be applicable, but MUST NOT be used if the Endpoint does not=20 > agree to an NEA protocol exchange". Its my impression that this document provides context and requirements for NEA protocol selection by the NEA WG. The text suggested reads like a normative requirement applying to the deployer and not to the NEA WG selection of appropriate protocols for NEA. Could this be reworded to state the NEA WG intentions for how we envision NEA's use (and what it was designed for) without 2119 language? >=20 > Text like that would simplify much of the discussion around=20 > the various scenarios. It would cover legacy systems not=20 > running NEA, systems running NEA but from a differing=20 > network, and systems running NEA where the owner of the=20 > endpoint chooses not to comply. >=20 > ... 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. Again expanding the "..." which seems to be causing confusion the "..." reads: "Conversely, some environments where NEA is not expected to be applicable would be environments where the Endpoint is owned by a User and has not agreed to conform to a network provider's policies. An example might include" >=20 > No, that is forbidden by the charter. Privacy is not the=20 > issue. The charter states "... we do not know that NEA would=20 > be useful in such cases." That is what this text (see the expanded "..." text above) says. We're stating where NEA is not applicable in this paragraph. I'm open to mentioning the charter of our WG if that adds clarity to our NEA protocol selection process. >=20 > i.e. Non-charter scenarios have many issues, some of which=20 > are unknown. Non-charter use of NEA is forbidden outright,=20 > and should not be discussed in the document other than to say=20 > it is forbidden. >=20 > Other environments are more difficult to determine whether NEA > is a good fit, so the NEA WG intends to steer clear of such > areas. >=20 > Again, it is forbidden by charter. Saying the WG has=20 > intentions is saying we might steer clear... or we might not. Can you suggest a different word then "intends" which make it more clear that we aren't planning to include this in our scope. We could change the last phrase to "so the NEA WG will not address such areas." >=20 > ... In particular environments where the Owners of the > Endpoint, the network infrastructure and/or the network > service provider are different and do not have a strong > binding contract(s) establishing their expectations for > conformance and willingness to disclose information to each > other security policies. >=20 > I'm not sure what that sentence is saying. Maybe a missing comma? >=20 > ... In particular, environments where the Owners of the > Endpoint, the network infrastructure and/or the network > service provider are different and do not have a strong > binding contract(s) establishing their expectations for > conformance and willingness to disclose information to each > other security policies. >=20 > I suggest splitting the sentence into two or more shorter sentences. Ok, it was trying to say there are 3 parties involved and if they have different owners they need to have a contract-based expectation of conformance and willingness to expose information with each other or this scenario is not applicable. Will reword. >=20 > Alan DeKok. > -- > http://deployingradius.com - The web site of the book > http://deployingradius.com/blog/ - The blog >=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 Jan 11 17:35:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H58WH-000581-32; Thu, 11 Jan 2007 17:35:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H58WF-00057r-9g for nea@ietf.org; Thu, 11 Jan 2007 17:35:35 -0500 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H58WD-0001b0-LG for nea@ietf.org; Thu, 11 Jan 2007 17:35:34 -0500 Received: from unknown (HELO proton.jnpr.net) ([10.10.2.37]) by kremlin.juniper.net with ESMTP; 11 Jan 2007 14:31:47 -0800 X-IronPort-AV: i="4.13,175,1167638400"; d="scan'208"; a="638244495:sNHT30210828" X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Jan 2007 17:35:32 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: Why is draft-ietf-nea-requirements-00.txt a WG draft? Thread-index: Acc1r9lUVX0nyVwxQqy6RQaIc6Zt+wABGSyQAAG+0QAAAJu88AABcmcw From: "Stephen Hanna" To: "Tschofenig, Hannes" X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: nea@ietf.org Subject: [Nea] Re: Why is draft-ietf-nea-requirements-00.txt a WG draft? X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Hannes Tschofenig wrote: > The work of a design team has to be approved by the working group before > it becomes a working group document.=20 > > Has this happened? I have never seen a hum. We discussed the process on the list and with our ADs before the holidays. RFC 2418 says "The output of a design team is always subject to approval, rejection or modification by the WG as a whole." That's what we're doing now. The document will be revised or even completely replaced according to WG consensus. The process for making a document a working group draft is described briefly in RFC 4677, which says "Working Group drafts are usually reviewed by the Working Group before being accepted as a WG item, although the chairs have the final say." Since our charter clearly calls for us to create a requirements document, Susan and I decided that it would be simplest to bring the document in as a working group draft from the start. In the end, I don't think there's much benefit to spending a lot of time talking about this process issue. We should focus on the content of the document and make sure that's right. Whether it's a WG draft or not doesn't make much difference at this point. We will end up with a WG draft on requirements. We might as well start with this one and revise it to make it what we want. Let's focus on that. Thanks, Steve _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Jan 11 17:53:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H58nc-0000i7-Vb; Thu, 11 Jan 2007 17:53:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H58nb-0000hk-F1 for nea@ietf.org; Thu, 11 Jan 2007 17:53:31 -0500 Received: from e36.co.us.ibm.com ([32.97.110.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H58nY-0004nz-W7 for nea@ietf.org; Thu, 11 Jan 2007 17:53:31 -0500 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e36.co.us.ibm.com (8.13.8/8.12.11) with ESMTP id l0BMrRZ1001610 for ; Thu, 11 Jan 2007 17:53:27 -0500 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id l0BMrR8Z537480 for ; Thu, 11 Jan 2007 15:53:27 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0BMrQvh022541 for ; Thu, 11 Jan 2007 15:53:27 -0700 Received: from d03nm129.boulder.ibm.com (d03nm129.boulder.ibm.com [9.17.195.155]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0BMrQjG022538; Thu, 11 Jan 2007 15:53:26 -0700 In-Reply-To: <618694EF0B657246A4D55A97E38274C302CE70B3@xmb-sjc-22d.amer.cisco.com> Subject: RE: [Nea] REQ: Section 4 To: "Kaushik Narayan \(kaushik\)" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Frank Yeh Jr Date: Thu, 11 Jan 2007 14:53:17 -0800 X-MIMETrack: Serialize by Router on D03NM129/03/M/IBM(Release 7.0.2HF32 | October 17, 2006) at 01/11/2007 15:53:26 MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: da25f8b06103d7bf154dc8a57ee01bb3 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="===============1278860198==" Errors-To: nea-bounces@ietf.org --===============1278860198== Content-type: multipart/related; Boundary="0__=07BBF8F3DFE97CB98f9e8a93df938690918c07BBF8F3DFE97CB9" --0__=07BBF8F3DFE97CB98f9e8a93df938690918c07BBF8F3DFE97CB9 Content-type: multipart/alternative; Boundary="1__=07BBF8F3DFE97CB98f9e8a93df938690918c07BBF8F3DFE97CB9" --1__=07BBF8F3DFE97CB98f9e8a93df938690918c07BBF8F3DFE97CB9 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Greetings, Please see my comments also inserted in line. Regards, Frank Yeh Corporate Security Strategy Team IBM Tivoli Software = "Kaushik Narayan = \(kaushik\)" = "Alan DeKok" = , = 01/11/2007 11:54 = AM = cc = Subj= ect RE: [Nea] REQ: Section 4 = = = = = = = Hi Alan, Thanks for your comments. Please find my response inline. -----Original Message----- From: Alan DeKok [mailto:aland@deployingradius.com] Sent: Wednesday, January 10, 2007 9:15 PM To: nea@ietf.org Subject: [Nea] REQ: Section 4 NEA technology may be used for several purposes. One use ... One use is documented, I can't find others. Maybe re-assesment? But that's just part of NEA, and not a different purpose. The purpose of NEA could be stated simply: knowing who is on the network, and knowing what they are running. (Since remediation is out of scope) The use cases provide further detail about the usage of NEA technology,the primary driver is assessment but deployments can use an incremental approach; for e.g. certain deployments might start with endpoint detection and creation of an inventory of endpoints before the= y start to apply policies for assessment. This usage of NEA was discussed= during the last IETF meeting. Without NEA technology, ensuring compliance of Endpoints to corporate policy is a time-consuming and difficult task. What about normal OS updates, as Bernard pointed out? A toy idea for= implementing NEA would be an software integrated with a client-side firewall that downloaded software updates every time the system connected to a network. I understand that much of the on-list discussion happened while the authors were busy writing the requirements document, but the points raised are serious enough to warrant a response from the authors. Is there *ever* a need in NEA for anything other than "get me all of the latest updates"? Why would a system *ever* ask for less than all of th= e updates? At most, I could see the updates being version dependent (updates for OS v1.2.3 versus OS v2.3.4). But once that information is= propagated to the machine sourcing the updates, the next step is *still= * "download all updates". I am not sure this statement really constraints the use of NEA; it is conceivable that deployments have security policies around OS versions= and patch levels. However I would like to point out that general purpos= e software distribution is not intended to a primary driver for NEA and there are other technologies that deal with problem of patch management= . IMHO, trying to drive the requirements of the protocol based on a= ll of the anticipated potential uses of the protocol is a fool's errand. The fundamental value of the protocol is to allow the transmissio= n of any conceivable data on a client to a server that can validate that dat= a against some set of rules and to do in a secure way that can preclude highler levels of access. Being able to do this at layer 2 allows us to= constrain layer 3 traffic until the admission decision is made. People will find all sorts of ways to use the protocol for uses t= hat it was not intended for. All we need to do is create a way for them to = pass their data from one endpoint of the tunnel to the other, and provide a means for the network to allow or deny access based on the decision tha= t is made on the server side of that tunnel. What types of data are passed, how it is consumed anc acted on, a= re not within the scope of the protocol. ... With NEA technology, the network is able to assess an Endpoint as soon as it requests access to the network or at any time after joining the network So we're assuming that the network will control what software is running on the endpoint, but won't keep track of that information? Why= bother asking the Endpoint what it has, when the network could simply consult it's database, and say "machine X isn't up to date", and then g= o tell it "download all of the latest updates". The assessment SHOULD NOT include querying. I have not seen a scenario where querying of endpoints is useful. In fact, querying is extremely inefficient, compared to simply telling the endpoint "downloa= d all updates". Of course, the net result of that design is that most of the complexity of NEA gets pushed into the remediation network, but that's not necessarily a bad thing. I think there is a fundamental assumption in your statement that all assessment use cases are tied to software updates, that's certainly not= true. There might compliance policies dealing with certain applications= such as host firewalls, P2P applications being enabled/disabled on endpoints that are admitted to the network, in such a scenario the NEA server is required to request endpoint with specific Posture Attributes= that deal with such applications. I am not sure of your statement that "the network won't keep track of the information about a prior assessment", we have described the use of= assertions as a means to re-use information from prior assessments. Even in the context of software and patch management, a single "apply a= ll patches and updates" profile is extremely limiting. Large organizations= need a little more granularity than this. The assumption that all endpo= ints will have the exact same requirements for Software and patches is not a= sound one. Making the network keep track of this is also not a real scalable idea. ... This provides the corporation an opportunity to monitor compliance I don't understand "monitor compliance". If a machine does NEA when it connects, it is compliant. If later changes mean a connected machin= e is no longer compliant to the new policy, the network MUST know, or MUS= T have a way to tell the machines to become compliant. "monitoring compliance" to me seems to indicate pro-active querying of machines, as= in "are you still compliant?". Such querying is inefficient and unnecessary. The term "monitor compliance" does not intend to convey that the networ= k is actively polling the endpoint. It is intended to cover the use case wherein the reassessment can be triggered while the endpoint is connected to the network either via a trigger from the NEA client or th= e NEA server. There are use cases are described in section 6.2.1 and 6.2.= 2 We will try to use an alternative term. Another term is seriously needed her. First of all, we are not enabling companies to monitor compliance= with this protocol, we are giving them the ability to constrain network= access based on a compliance decision. There are any number of ways to monitor compliance that have nothing to do with NEA or the network at a= ll. The decision of how to handle non-compliant Endpoints can be made by the network administrator ... s/can/MUST/, or s/can/can only/ ... For example, re-assessment may be triggered by a NEA Client if a User disables a security application such as a host firewall on the Endpoint. I don't understand that. If the network policy says he MUST run a firewall, disabling the firewall MUST result in being kicked off of the= network. I don't see why re-assessment is necessary: the user has declared he is no longer in compliance. The disabling of the firewall represents a change in posture, the NEA server is required to assess the compliance of the endpoint in the ligh= t of the modified posture which is why reassessment is necessary. The network access layer (which is out of scope for NEA discussions) may us= e the decision of the reassessment to implement a policy to boot the user= from the network. Section 6.2.1 describes such a use case. ReAssessment is typically a post-admission event. We are not talk= ing about users who though to be non-compliant coming baclk to retry the admission, we are talking about users who are thought to be compliant a= nd have already been admitted. ... Re- assessment also assists in keeping Endpoints connected to the network up to date with fixes and patches published by security application vendors. As opposed to simple downloads of the updates? It's a lot easier for= many endpoints to periodically query a server, than it is for a server to poll many endpoints. The document describes two models of reassessment, i.e. NEA client triggered and NEA server triggered, it is upto deployments to determine= the most optimum mechanism to employ. Performing re-assessment to me indicates that NEA won't scale. ... Another use of NEA technology may be to supplement information in inventory databases. Is this a charter goal? If not, why are we discussing it? NEA *may*= result in additional information being available to the network admin, but the maintenance and use of that information is out of scope of NEA.= The text purely reflecting a usage of NEA technology to detect endpoint= s and supplement inventory information. I don't think the text intends to= suggest that the NEA will describe the definition and maintaince of inventory databases. Building an inventory of endpoints is an important= pre-cursor in enterprise deployments of NEA technology. And it is not the normal realm of the Network Amdinistrator. What= will be required is for one group to manage the identities and policy reqiurements and another to manage the network and the various levels o= f network access. Then the two will have to agree on how to set policies = so that each host is sent to the right network based on identity and compliance. ... In organizations that attempt to keep track of their assets, inventory databases tend to be incomplete and out-of-date. NEA technology may be used to verify or supplement information stored about an organization's assets. I suggest deleting that text entirely. Please refer to above comment I agree with deleting the text. It is far too presumptious! ... NEA technology can also be used to monitor and report compliance for Endpoints when they try to access certain mission critical applications within an enterprise by employing application triggered Assessment. Why? The endpoint knows what posture it satisfies, and the network admin knows the same thing if he caches the posture assessment from the= initial network access. If the application knows what posture it requires, why ask the potentially compromised host, when can instead as= k a trusted source: the network admin? This approach could also catch th= e case of lying endpoints. If the network determines that an endpoint is= lying (i.e. by observing network traffic), it can update it's view of the endpoints posture, and inform others on the network that the device= is not to be trusted. IMHO this perspective places far too much responsibility and authority on the "network admin". In most large organizations, there ar= e teams of network admins each responsible for different sections of the network. Expecting these tea0s to suddenly become the arbiters of who o= n which endpoint should be running what is completely unrealistic. There = a other departments that deal with that data and it should be left to the= m. This text is not intended to suggest the exchange of posture informatio= n between the NEA server and applications. This text covers use cases wherein assessment can be triggered when Layer 5-7 services are accessed; Section 6.1.2 provides an example of this use case. Regards, kaushik Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea = --1__=07BBF8F3DFE97CB98f9e8a93df938690918c07BBF8F3DFE97CB9 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Greetings,

Please see my comments also inserted in line.

Regards,
Frank Yeh
Corporate Security Strategy Team
IBM
Tivoli Software

3D"Inactive"Kau= shik Narayan \(kaushik\)" <kaushik@cisco.com>


=
          "Kaushik Narayan \(kaushik\)" <kau= shik@cisco.com>

          01/11/2007 11:54 AM

 =
3D=
To
3D""
"Alan DeKok" <aland@deployingradius.com&g= t;, <nea@ietf.org>
3D=
cc
3D""
3D=
Subject
3D""
RE: [Nea] REQ: Section 4
3D=3D""

Hi Alan,

Thanks for your comments. Please find my response inline.

-----Original Message-----
From: Alan DeKok [mailto:a= land@deployingradius.com]
Sent: Wednesday, January 10, 2007 9:15 PM
To: nea@ietf.org
Subject: [Nea] REQ: Section 4

    NEA technology may be used for several purposes.  O= ne use ...

One use is documented, I can't find others.  Maybe re-assesment? =  But
that's just part of NEA, and not a different purpose.  The purpose= of
NEA could be stated simply: knowing who is on the network, and knowing<= br> what they are running.  (Since remediation is out of scope)

<Kaushik> The use cases provide further detail about the usage of= NEA
technology,the primary driver is assessment but deployments can use an<= br> incremental approach; for e.g. certain deployments might start with
= endpoint detection and creation of an inventory of endpoints before the= y
start to apply policies for assessment. This usage of NEA was discussed=
during the last IETF meeting.


     Without NEA technology, ensuring compliance of End= points to
     corporate policy is a time-consuming and difficult= task.

 What about normal OS updates, as Bernard pointed out?  A to= y idea for
implementing NEA would be an software integrated with a client-side
= firewall that downloaded software updates every time the system
connected to a network.

 I understand that much of the on-list discussion happened while = the
authors were busy writing the requirements document, but the points
= raised are serious enough to warrant a response from the authors.  = ;Is
there *ever* a need in NEA for anything other than "get me all of = the
latest updates"?  Why would a system *ever* ask for less than= all of the
updates?  At most, I could see the updates being version dependent=
(updates for OS v1.2.3 versus OS v2.3.4).  But once that informati= on is
propagated to the machine sourcing the updates, the next step is *still= *
"download all updates".

<Kaushik>


I am not sure this statement really constraints the use of NEA; it is conceivable that deployments have security  policies around OS ver= sions
and patch levels. However I would like to point out that general purpos= e
software distribution is not intended to a primary driver for NEA and there are other technologies that deal with problem of patch management= .

</Kaushik>

<FYeh>

IMHO, trying to drive the requirements of the protocol based on al= l of the anticipated potential uses of the protocol is a fool's errand.=

The fundamental value of the protocol is to allow the transmission= of any conceivable data on a client to a server that can validate that= data against some set of rules and to do in a secure way that can prec= lude highler levels of access. Being able to do this at layer 2 allows = us to constrain layer 3 traffic until the admission decision is made.

People will find all sorts of ways to use the protocol for uses th= at it was not intended for. All we need to do is create a way for them = to pass their data from one endpoint of the tunnel to the other, and pr= ovide a means for the network to allow or deny access based on the deci= sion that is made on the server side of that tunnel.

What types of data are passed, how it is consumed anc acted on, ar= e not within the scope of the protocol.

<?FYeh>

     ... With NEA technology, the network is
     able to assess an Endpoint as soon as it requests = access to
     the network or at any time after joining the netwo= rk

 So we're assuming that the network will control what software is=
running on the endpoint, but won't keep track of that information? &nbs= p;Why
bother asking the Endpoint what it has, when the network could simply consult it's database, and say "machine X isn't up to date", = and then go
tell it "download all of the latest updates".

 The assessment SHOULD NOT include querying.  I have not see= n a
scenario where querying of endpoints is useful.  In fact, querying= is
extremely inefficient, compared to simply telling the endpoint "do= wnload
all updates".

 Of course, the net result of that design is that most of the
= complexity of NEA gets pushed into the remediation network, but that's<= br> not necessarily a bad thing.

<Kaushik>  

I think there is a fundamental assumption in your statement that all assessment use cases are tied to software updates, that's certainly not=
true. There might compliance policies dealing with certain applications=
such as host firewalls, P2P applications being enabled/disabled on
endpoints that are admitted to the network, in such a scenario the NEA<= br> server is required to request endpoint with specific Posture Attributes=
that deal with such applications.

I am not sure of your statement that "the network won't keep track= of
the information about a prior assessment", we have described the u= se of
assertions as a means to re-use information from prior assessments.
=
</Kaushik>

<FYeh>

Even in the context of software and patch management, a single &quo= t;apply all patches and updates" profile is extremely limiting. La= rge organizations need a little more granularity than this. The assumpt= ion that all endpoints will have the exact same requirements for Softwa= re and patches is not a sound one. Making the network keep track of thi= s is also not a real scalable idea.

</FYeh>


      ... This
     provides the corporation an opportunity to monitor= compliance

 I don't understand "monitor compliance".  If a ma= chine does NEA when
it connects, it is compliant.  If later changes mean a connected m= achine
is no longer compliant to the new policy, the network MUST know, or MUS= T
have a way to tell the machines to become compliant.  "monito= ring
compliance" to me seems to indicate pro-active querying of machine= s, as
in "are you still compliant?".  Such querying is ineffic= ient and
unnecessary.


<Kaushik>

The term "monitor compliance" does not intend to convey that = the network
is actively polling the endpoint. It is intended to cover the use case<= br> wherein the reassessment can be triggered while the endpoint is
connected to the network either via a trigger from the NEA client or th= e
NEA server. There are use cases are described in section 6.2.1 and 6.2.= 2

We will try to use an alternative term.

</Kaushik>

<FYeh>

Another term is seriously needed her.

First of all, we are not enabling companies to monitor compliance = with this protocol, we are giving them the ability to constrain network= access based on a compliance decision. There are any number of ways to= monitor compliance that have nothing to do with NEA or the network at = all.

</FYeh>

     The decision of how to handle non-compliant Endpoi= nts can be
     made by the network administrator ...

 s/can/MUST/, or s/can/can only/

     ... For example, re-assessment
     may be triggered by a NEA Client if a User disable= s a security
     application such as a host firewall on the Endpoin= t.

 I don't understand that.  If the network policy says he MUS= T run a
firewall, disabling the firewall MUST result in being kicked off of the=
network.  I don't see why re-assessment is necessary: the user has=
declared he is no longer in compliance.


<Kaushik>

The disabling of the firewall represents a change in posture, the NEA server is required to assess the compliance of the endpoint in the ligh= t
of the modified posture which is why reassessment is necessary. The
= network access layer (which is out of scope for NEA discussions) may us= e
the decision of the reassessment to implement a policy to boot the user=
from the network.

Section 6.2.1 describes such a use case.


</Kaushik>

<FYeh>

ReAssessment is typically a post-admission event. We are not talki= ng about users who though to be non-compliant coming baclk to retry the= admission, we are talking about users who are thought to be compliant = and have already been admitted.

</FYeh>

     ... Re-
     assessment also assists in keeping Endpoints conne= cted to the
     network up to date with fixes and patches publishe= d by
     security application vendors.

 As opposed to simple downloads of the updates?  It's a lot = easier for
many endpoints to periodically query a server, than it is for a server<= br> to poll many endpoints.


<Kaushik>

The document describes two models of reassessment, i.e. NEA client
triggered and NEA server triggered, it is upto deployments to determine=
the most optimum mechanism to employ.

</Kaushik>


 Performing re-assessment to me indicates that NEA won't scale.
     ... Another use of NEA technology
     may be to supplement information in inventory data= bases.

 Is this a charter goal?  If not, why are we discussing it? =  NEA *may*
result in additional information being available to the network admin,<= br> but the maintenance and use of that information is out of scope of NEA.=


<Kaushik>

The text purely reflecting a usage of NEA technology to detect endpoint= s
and supplement inventory information. I don't think the text intends to=
suggest that the NEA will describe the definition and maintaince of
= inventory databases. Building an inventory of endpoints is an important=
pre-cursor in enterprise deployments of NEA technology.

</Kaushik>

<FYeh>

And it is not the normal realm of the Network Amdinistrator. What = will be required is for one group to manage the identities and policy r= eqiurements and another to manage the network and the various levels of= network access. Then the two will have to agree on how to set policies= so that each host is sent to the right network based on identity and c= ompliance.

</FYeh>


     ... In
     organizations that attempt to keep track of their = assets,
     inventory databases tend to be incomplete and out-= of-date.
     NEA technology may be used to verify or supplement= information
     stored about an organization's assets.

 I suggest deleting that text entirely.

<Kaushik>

Please refer to above comment

</Kaushik>

<FYeh>

I agree with deleting the text. It is far too presumptious!
</FYeh>

     ... NEA
     technology can also be used to monitor and report = compliance
     for Endpoints when they try to access certain miss= ion critical
     applications within an enterprise by employing app= lication
     triggered Assessment.

 Why?  The endpoint knows what posture it satisfies, and the= network
admin knows the same thing if he caches the posture assessment from the=
initial network access.  If the application knows what posture it<= br> requires, why ask the potentially compromised host, when can instead as= k
a trusted source: the network admin?  This approach could also cat= ch the
case of lying endpoints.  If the network determines that an endpoi= nt is
lying (i.e. by observing network traffic), it can update it's view of the endpoints posture, and inform others on the network that the device=
is not to be trusted.

<FYeh>

IMHO this perspective places far too much responsibility and autho= rity on the "network admin". In most large organizations, the= re are teams of network admins each responsible for different sections = of the network. Expecting these tea0s to suddenly become the arbiters o= f who on which endpoint should be running what is completely unrealisti= c. There a other departments that deal with that data and it should be = left to them.

</FYeh>

<Kaushik>

This text is not intended to suggest the exchange of posture informatio= n
between the NEA server and applications. This text covers use cases
= wherein assessment can be triggered when Layer 5-7 services are
accessed; Section 6.1.2 provides an example of this use case.

Regards,
 kaushik

</Kaushik>



 Alan DeKok.
--
 http://deploying= radius.com       - The web site of the= book
 http://dep= loyingradius.com/blog/ - The blog

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

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

= --1__=07BBF8F3DFE97CB98f9e8a93df938690918c07BBF8F3DFE97CB9-- --0__=07BBF8F3DFE97CB98f9e8a93df938690918c07BBF8F3DFE97CB9 Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=07BBF8F3DFE97CB98f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=07BBF8F3DFE97CB98f9e8a93df938690918c07BBF8F3DFE97CB9 Content-type: image/gif; name="pic32272.gif" Content-Disposition: inline; filename="pic32272.gif" Content-ID: <2__=07BBF8F3DFE97CB98f9e8a93df938@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__=07BBF8F3DFE97CB98f9e8a93df938690918c07BBF8F3DFE97CB9 Content-type: image/gif; name="ecblank.gif" Content-Disposition: inline; filename="ecblank.gif" Content-ID: <3__=07BBF8F3DFE97CB98f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7 --0__=07BBF8F3DFE97CB98f9e8a93df938690918c07BBF8F3DFE97CB9-- --===============1278860198== 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 --===============1278860198==-- From nea-bounces@ietf.org Thu Jan 11 22:37:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5DDq-0004Cq-Gc; Thu, 11 Jan 2007 22:36:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5DDo-00045R-Oi for nea@ietf.org; Thu, 11 Jan 2007 22:36:52 -0500 Received: from www.deployingradius.com ([216.240.42.17] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5DDn-0007EC-00 for nea@ietf.org; Thu, 11 Jan 2007 22:36:52 -0500 Received: from [192.168.123.100] (bas1-ottawa23-1177638353.dsl.bell.ca [70.49.85.209]) by book.deployingradius.com (Postfix) with ESMTP id 2B21CA71D5; Thu, 11 Jan 2007 19:36:41 -0800 (PST) Message-ID: <45A70175.10003@deployingradius.com> Date: Thu, 11 Jan 2007 22:33:09 -0500 From: Alan DeKok User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: "Kaushik Narayan (kaushik)" Subject: Re: [Nea] REQ: Section 4 References: <618694EF0B657246A4D55A97E38274C302CE70B3@xmb-sjc-22d.amer.cisco.com> In-Reply-To: <618694EF0B657246A4D55A97E38274C302CE70B3@xmb-sjc-22d.amer.cisco.com> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e 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 Kaushik Narayan (kaushik) wrote: > The use cases provide further detail about the usage of NEA > technology,the primary driver is assessment but deployments can use an > incremental approach; for e.g. certain deployments might start with > endpoint detection and creation of an inventory of endpoints before they > start to apply policies for assessment. This usage of NEA was discussed > during the last IETF meeting. As I asked before, is inventory control part of the charter? If not, why is it being discussed? The potential costs, benefits and risks of using NEA for inventory control are a large subject in themselves, and I don't think we have time to cover that in addition to the charter work. > I am not sure this statement really constraints the use of NEA; it is > conceivable that deployments have security policies around OS versions > and patch levels. Can you give concrete examples? > However I would like to point out that general purpose > software distribution is not intended to a primary driver for NEA and > there are other technologies that deal with problem of patch management. My comments were not about patch management. My request was for scenarios where the endpoint did anything *other* than download all available updates. Do you have a concrete response to that request? > I think there is a fundamental assumption in your statement that all > assessment use cases are tied to software updates, that's certainly not > true. There might compliance policies dealing with certain applications > such as host firewalls, P2P applications being enabled/disabled on > endpoints that are admitted to the network, in such a scenario the NEA > server is required to request endpoint with specific Posture Attributes > that deal with such applications. My assumption was not about *software* updates, so much as *policy* updates. One policy is to download all software updates. Another policy might contain rule updates for a firewall, as you pointed out. Again, is there a need for the endpoint to do anything other than download and apply all of the policies associated with a firewall or P2P application? Who cares what policy the endpoint has *prior* to it's network connection attempt? As has been discussed on the list at length, there appears to be little need for querying of the endpoints. > I am not sure of your statement that "the network won't keep track of > the information about a prior assessment", we have described the use of > assertions as a means to re-use information from prior assessments. I can't find such a statement in my message. I am therefore not sure what comment you are addressing. > The disabling of the firewall represents a change in posture, the NEA > server is required to assess the compliance of the endpoint in the light > of the modified posture which is why reassessment is necessary. The > network access layer (which is out of scope for NEA discussions) may use > the decision of the reassessment to implement a policy to boot the user > from the network. It would be simpler to say that non-compliant endpoints MUST not be permitted full network access until the NEA server has assessed their posture. A system MAY become non-compliant as a result of configuration changes while it is (or is not) connected. > The document describes two models of reassessment, i.e. NEA client > triggered and NEA server triggered, it is upto deployments to determine > the most optimum mechanism to employ. I'm not sure how an NEA client triggered re-assesment is different from a client requesting network access for the first time after a long disconnection > ... In > organizations that attempt to keep track of their assets, > inventory databases tend to be incomplete and out-of-date. > NEA technology may be used to verify or supplement information > stored about an organization's assets. > > I suggest deleting that text entirely. > > > > Please refer to above comment Discussions of inventory control concern me, as I detailed in my first paragraph of this message. > This text is not intended to suggest the exchange of posture information > between the NEA server and applications. This text covers use cases > wherein assessment can be triggered when Layer 5-7 services are > accessed; Section 6.1.2 provides an example of this use case. The network should know the current posture of the device before it accesses an application. If the posture is sufficient to access the application, no assessment is necessary. If the posture is insufficient, then the initial posture assessment could have included requests for sufficient information to make later decisions about application access. The alternative is a security violation: When someone accesses an application, they get contacted, and asked if they're running software X, Y, and Z, which are prerequisites for access. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Thu Jan 11 23:28:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5E21-00015a-PO; Thu, 11 Jan 2007 23:28:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5E21-00015N-0V for nea@ietf.org; Thu, 11 Jan 2007 23:28:45 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5E1w-0003lR-AU for nea@ietf.org; Thu, 11 Jan 2007 23:28:44 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 11 Jan 2007 20:28:39 -0800 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l0C4SdQG024420; Thu, 11 Jan 2007 20:28:39 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l0C4SZnF003858; Thu, 11 Jan 2007 20:28:39 -0800 (PST) Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jan 2007 20:28:33 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Nea] REQ: Section 4 Date: Thu, 11 Jan 2007 20:28:31 -0800 Message-ID: <618694EF0B657246A4D55A97E38274C302CE72B8@xmb-sjc-22d.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] REQ: Section 4 Thread-Index: Acc101dxnrGSeYDgS3GdBNhHWRo4TgAAfafw From: "Kaushik Narayan \(kaushik\)" To: "Frank Yeh Jr" X-OriginalArrivalTime: 12 Jan 2007 04:28:33.0603 (UTC) FILETIME=[1EAFF130:01C73602] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=37064; t=1168576119; x=1169440119; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kaushik@cisco.com; z=From:=20=22Kaushik=20Narayan=20\(kaushik\)=22=20 |Subject:=20RE=3A=20[Nea]=20REQ=3A=20Section=204 |Sender:=20; bh=xFV+LzNp39sVhG8u3ZV4yjfTnJiu4JHpjzsB6NCVssA=; b=UHCrpC/FbVhlDYu1ogbb9mLecsx7Tu9WWHI4gWYKBzDpN0Ysx/fTPSulhOSY3P2ILhN/+0cr 1lmeEn1gmnRDAggtLWtnUL+H0iqvRe1P11JX1Vtszpvocw3JbeNYpP6B; Authentication-Results: sj-dkim-6; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: e09ca23b1e78625a9f2987ce57451043 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="===============1852762986==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============1852762986== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73602.1E8A8C86" This is a multi-part message in MIME format. ------_=_NextPart_001_01C73602.1E8A8C86 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Frank, =20 Please find my response inline. I have used the tag =20 =20 =20 NEA technology may be used for several purposes. One use ... One use is documented, I can't find others. Maybe re-assesment? But that's just part of NEA, and not a different purpose. The purpose of NEA could be stated simply: knowing who is on the network, and knowing what they are running. (Since remediation is out of scope) The use cases provide further detail about the usage of NEA technology,the primary driver is assessment but deployments can use an incremental approach; for e.g. certain deployments might start with endpoint detection and creation of an inventory of endpoints before they start to apply policies for assessment. This usage of NEA was discussed during the last IETF meeting. Without NEA technology, ensuring compliance of Endpoints to corporate policy is a time-consuming and difficult task. What about normal OS updates, as Bernard pointed out? A toy idea for implementing NEA would be an software integrated with a client-side firewall that downloaded software updates every time the system connected to a network. I understand that much of the on-list discussion happened while the authors were busy writing the requirements document, but the points raised are serious enough to warrant a response from the authors. Is there *ever* a need in NEA for anything other than "get me all of the latest updates"? Why would a system *ever* ask for less than all of the updates? At most, I could see the updates being version dependent (updates for OS v1.2.3 versus OS v2.3.4). But once that information is propagated to the machine sourcing the updates, the next step is *still* "download all updates". =20 I am not sure this statement really constraints the use of NEA; it is conceivable that deployments have security policies around OS versions and patch levels. However I would like to point out that general purpose software distribution is not intended to a primary driver for NEA and there are other technologies that deal with problem of patch management. IMHO, trying to drive the requirements of the protocol based on all of the anticipated potential uses of the protocol is a fool's errand. The fundamental value of the protocol is to allow the transmission of any conceivable data on a client to a server that can validate that data against some set of rules and to do in a secure way that can preclude highler levels of access. Being able to do this at layer 2 allows us to constrain layer 3 traffic until the admission decision is made. People will find all sorts of ways to use the protocol for uses that it was not intended for. All we need to do is create a way for them to pass their data from one endpoint of the tunnel to the other, and provide a means for the network to allow or deny access based on the decision that is made on the server side of that tunnel. What types of data are passed, how it is consumed anc acted on, are not within the scope of the protocol. =20 =20 =20 =20 I think we are in agreement; as I mentioned in my previous email, NEA protocols cannot limit what attributes that get validated since that is part of the policies of the organization that deploys NEA. My statement about patch management was that use cases from that area are not going to primarily drive protocol requirements. =20 =20 =20 ... With NEA technology, the network is able to assess an Endpoint as soon as it requests access to the network or at any time after joining the network So we're assuming that the network will control what software is running on the endpoint, but won't keep track of that information? Why bother asking the Endpoint what it has, when the network could simply consult it's database, and say "machine X isn't up to date", and then go tell it "download all of the latest updates". The assessment SHOULD NOT include querying. I have not seen a scenario where querying of endpoints is useful. In fact, querying is extremely inefficient, compared to simply telling the endpoint "download all updates". Of course, the net result of that design is that most of the complexity of NEA gets pushed into the remediation network, but that's not necessarily a bad thing. =20 I think there is a fundamental assumption in your statement that all assessment use cases are tied to software updates, that's certainly not true. There might compliance policies dealing with certain applications such as host firewalls, P2P applications being enabled/disabled on endpoints that are admitted to the network, in such a scenario the NEA server is required to request endpoint with specific Posture Attributes that deal with such applications.=20 I am not sure of your statement that "the network won't keep track of the information about a prior assessment", we have described the use of assertions as a means to re-use information from prior assessments. Even in the context of software and patch management, a single "apply all patches and updates" profile is extremely limiting. Large organizations need a little more granularity than this. The assumption that all endpoints will have the exact same requirements for Software and patches is not a sound one. Making the network keep track of this is also not a real scalable idea. =20 =20 =20 That's true. I do believe that "apply all patches" is just a policy and the NEA protocols need to support posture attribute requests and assessment policies at different levels of granularity.=20 =20 The network won't really keep track of what software patches, I was pointing out that NEA might not necessarily discard decisions from prior assessments and the Reference Model specifies assertion attributes that can be used to reflect decisions from a prior assessment. =20 =20 =20 ... This provides the corporation an opportunity to monitor compliance I don't understand "monitor compliance". If a machine does NEA when it connects, it is compliant. If later changes mean a connected machine is no longer compliant to the new policy, the network MUST know, or MUST have a way to tell the machines to become compliant. "monitoring compliance" to me seems to indicate pro-active querying of machines, as in "are you still compliant?". Such querying is inefficient and unnecessary. =20 The term "monitor compliance" does not intend to convey that the network is actively polling the endpoint. It is intended to cover the use case wherein the reassessment can be triggered while the endpoint is connected to the network either via a trigger from the NEA client or the NEA server. There are use cases are described in section 6.2.1 and 6.2.2 We will try to use an alternative term. Another term is seriously needed her.=20 First of all, we are not enabling companies to monitor compliance with this protocol, we are giving them the ability to constrain network access based on a compliance decision. There are any number of ways to monitor compliance that have nothing to do with NEA or the network at all. =20 =20 =20 =20 Agree. The term "monitor" is misleading. =20 =20 The decision of how to handle non-compliant Endpoints can be made by the network administrator ... s/can/MUST/, or s/can/can only/ ... For example, re-assessment may be triggered by a NEA Client if a User disables a security application such as a host firewall on the Endpoint. I don't understand that. If the network policy says he MUST run a firewall, disabling the firewall MUST result in being kicked off of the network. I don't see why re-assessment is necessary: the user has declared he is no longer in compliance. =20 The disabling of the firewall represents a change in posture, the NEA server is required to assess the compliance of the endpoint in the light of the modified posture which is why reassessment is necessary. The network access layer (which is out of scope for NEA discussions) may use the decision of the reassessment to implement a policy to boot the user from the network.=20 Section 6.2.1 describes such a use case. =20 ReAssessment is typically a post-admission event. We are not talking about users who though to be non-compliant coming baclk to retry the admission, we are talking about users who are thought to be compliant and have already been admitted. =20 =20 I am not sure we need to narrow down the definition of reassessment to just cover the cases when the endpoint is compliant; Reassessment might occur for a non-compliant endpoint post remediation. =20 =20 =20 =20 ... Re- assessment also assists in keeping Endpoints connected to the network up to date with fixes and patches published by security application vendors. As opposed to simple downloads of the updates? It's a lot easier for many endpoints to periodically query a server, than it is for a server to poll many endpoints. =20 The document describes two models of reassessment, i.e. NEA client triggered and NEA server triggered, it is upto deployments to determine the most optimum mechanism to employ. Performing re-assessment to me indicates that NEA won't scale. ... Another use of NEA technology may be to supplement information in inventory databases. Is this a charter goal? If not, why are we discussing it? NEA *may* result in additional information being available to the network admin, but the maintenance and use of that information is out of scope of NEA. =20 The text purely reflecting a usage of NEA technology to detect endpoints and supplement inventory information. I don't think the text intends to suggest that the NEA will describe the definition and maintaince of inventory databases. Building an inventory of endpoints is an important pre-cursor in enterprise deployments of NEA technology.=20 And it is not the normal realm of the Network Amdinistrator. What will be required is for one group to manage the identities and policy reqiurements and another to manage the network and the various levels of network access. Then the two will have to agree on how to set policies so that each host is sent to the right network based on identity and compliance. ... In organizations that attempt to keep track of their assets, inventory databases tend to be incomplete and out-of-date. NEA technology may be used to verify or supplement information stored about an organization's assets. I suggest deleting that text entirely. Please refer to above comment=20 I agree with deleting the text. It is far too presumptious! =20 =20 =20 =20 You are right, my comment to Alan was based on the relevance of the use case. I do agree that this sentence is not properly worded. =20 regards, kaushik =20 =20 ... NEA technology can also be used to monitor and report compliance for Endpoints when they try to access certain mission critical applications within an enterprise by employing application triggered Assessment. Why? The endpoint knows what posture it satisfies, and the network admin knows the same thing if he caches the posture assessment from the initial network access. If the application knows what posture it requires, why ask the potentially compromised host, when can instead ask a trusted source: the network admin? This approach could also catch the case of lying endpoints. If the network determines that an endpoint is lying (i.e. by observing network traffic), it can update it's view of the endpoints posture, and inform others on the network that the device is not to be trusted. IMHO this perspective places far too much responsibility and authority on the "network admin". In most large organizations, there are teams of network admins each responsible for different sections of the network. Expecting these tea0s to suddenly become the arbiters of who on which endpoint should be running what is completely unrealistic. There a other departments that deal with that data and it should be left to them. =20 This text is not intended to suggest the exchange of posture information between the NEA server and applications. This text covers use cases wherein assessment can be triggered when Layer 5-7 services are accessed; Section 6.1.2 provides an example of this use case. Regards, kaushik Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea ------_=_NextPart_001_01C73602.1E8A8C86 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi Frank,
 
Please find my response inline. I have used the = tag=20 <Kaushik-Response>
 
 
<snipped>
 

    NEA technology may be = used for=20 several purposes.  One use ...

One use is documented, I = can't find=20 others.  Maybe re-assesment?  But
that's just part of NEA, = and not=20 a different purpose.  The purpose of
NEA could be stated simply: = knowing=20 who is on the network, and knowing
what they are running. =  (Since=20 remediation is out of scope)

<Kaushik> The use cases = provide=20 further detail about the usage of NEA
technology,the primary driver = is=20 assessment but deployments can use an
incremental approach; for e.g. = certain=20 deployments might start with
endpoint detection and creation of an = inventory=20 of endpoints before they
start to apply policies for assessment. This = usage=20 of NEA was discussed
during the last IETF meeting.


  =  =20  Without NEA technology, ensuring compliance of Endpoints = to
 =20    corporate policy is a time-consuming and difficult=20 task.

 What about normal OS updates, as Bernard pointed out? =  A=20 toy idea for
implementing NEA would be an software integrated with a=20 client-side
firewall that downloaded software updates every time the=20 system
connected to a network.

 I understand that much of = the=20 on-list discussion happened while the
authors were busy writing the=20 requirements document, but the points
raised are serious enough to = warrant a=20 response from the authors.  Is
there *ever* a need in NEA for = anything=20 other than "get me all of the
latest updates"?  Why would a = system=20 *ever* ask for less than all of the
updates?  At most, I could = see the=20 updates being version dependent
(updates for OS v1.2.3 versus OS = v2.3.4).=20  But once that information is
propagated to the machine sourcing = the=20 updates, the next step is *still*
"download all=20 updates".

<Kaushik>


I am not sure this = statement really=20 constraints the use of NEA; it is
conceivable that deployments have = security=20  policies around OS versions
and patch levels. However I would = like to=20 point out that general purpose
software distribution is not intended = to a=20 primary driver for NEA and
there are other technologies that deal = with=20 problem of patch=20 management.

</Kaushik>

<FYeh>
=
IMHO,=20 trying to drive the requirements of the protocol based on all of the = anticipated=20 potential uses of the protocol is a fool's errand.

The=20 fundamental value of the protocol is to allow the transmission of any=20 conceivable data on a client to a server that can validate that data = against=20 some set of rules and to do in a secure way that can preclude highler = levels of=20 access. Being able to do this at layer 2 allows us to constrain layer 3 = traffic=20 until the admission decision is made.

People will find = all sorts=20 of ways to use the protocol for uses that it was not intended for. All = we need=20 to do is create a way for them to pass their data from one endpoint of = the=20 tunnel to the other, and provide a means for the network to allow or = deny access=20 based on the decision that is made on the server side of that=20 tunnel.

What types of data are passed, how it is = consumed anc=20 acted on, are not within the scope of the=20 protocol.

<?FYeh> 
 
 
<Kaushik-Response>
 
I think = we are in=20 agreement; as I mentioned in my previous email, NEA protocols = cannot limit=20 what attributes that get validated since that is part of the policies of = the=20 organization that deploys NEA. My statement about patch management was = that use=20 cases from that area are not going to primarily drive protocol=20 requirements.
 
</Kaushik-Response>
 
 

  &nbs= p;  ...=20 With NEA technology, the network is
     able to = assess an=20 Endpoint as soon as it requests access to
     the = network or=20 at any time after joining the network

 So we're assuming = that the=20 network will control what software is
running on the endpoint, but = won't keep=20 track of that information?  Why
bother asking the Endpoint what = it has,=20 when the network could simply
consult it's database, and say "machine = X isn't=20 up to date", and then go
tell it "download all of the latest=20 updates".

 The assessment SHOULD NOT include querying. =  I have=20 not seen a
scenario where querying of endpoints is useful.  In = fact,=20 querying is
extremely inefficient, compared to simply telling the = endpoint=20 "download
all updates".

 Of course, the net result of = that design=20 is that most of the
complexity of NEA gets pushed into the = remediation=20 network, but that's
not necessarily a bad = thing.

<Kaushik>=20  

I think there is a fundamental assumption in your = statement that=20 all
assessment use cases are tied to software updates, that's = certainly=20 not
true. There might compliance policies dealing with certain=20 applications
such as host firewalls, P2P applications being = enabled/disabled=20 on
endpoints that are admitted to the network, in such a scenario the = NEA
server is required to request endpoint with specific Posture=20 Attributes
that deal with such applications.

I am not sure of = your=20 statement that "the network won't keep track of
the information about = a prior=20 assessment", we have described the use of
assertions as a means to = re-use=20 information from prior=20 assessments.

</Kaushik>

<FYeh>

= Even in=20 the context of software and patch management, a single "apply all = patches and=20 updates" profile is extremely limiting. Large organizations need a = little more=20 granularity than this. The assumption that all endpoints will have the = exact=20 same requirements for Software and patches is not a sound one. Making = the=20 network keep track of this is also not a real scalable=20 idea.

</FYeh> 
 
<Kaushik-Response>
 
That's true. I do believe that "apply = all=20 patches" is just a policy and the NEA protocols need to support posture=20 attribute requests and assessment policies at different levels of=20 granularity. 
 
The network won't really keep track of = what software=20 patches, I was pointing out that NEA might not necessarily discard = decisions=20 from prior assessments and the Reference Model specifies assertion = attributes=20 that can be used to reflect decisions from a prior=20 assessment.
 
</Kaushik-Response>
 
 
    &= nbsp; ...=20 This
     provides the corporation an opportunity to = monitor=20 compliance

 I don't understand "monitor compliance". =  If a=20 machine does NEA when
it connects, it is compliant.  If later = changes=20 mean a connected machine
is no longer compliant to the new policy, = the=20 network MUST know, or MUST
have a way to tell the machines to become=20 compliant.  "monitoring
compliance" to me seems to indicate = pro-active=20 querying of machines, as
in "are you still compliant?".  Such = querying=20 is inefficient and
unnecessary.


<Kaushik> =

The term=20 "monitor compliance" does not intend to convey that the network
is = actively=20 polling the endpoint. It is intended to cover the use case
wherein = the=20 reassessment can be triggered while the endpoint is
connected to the = network=20 either via a trigger from the NEA client or the
NEA server. There are = use=20 cases are described in section 6.2.1 and 6.2.2

We will try to use = an=20 alternative=20 term.

</Kaushik>

<FYeh>

Another=20 term is seriously needed her.

First of all, we are not = enabling=20 companies to monitor compliance with this protocol, we are giving them = the=20 ability to constrain network access based on a compliance decision. = There are=20 any number of ways to monitor compliance that have nothing to do with = NEA or the=20 network at all.

</FYeh> 
 
 
<Kaushik-Response>
 
Agree. The term "monitor" is=20 misleading.
 
</Kaushik-Response> 

  = ;   The=20 decision of how to handle non-compliant Endpoints can be
  =  =20  made by the network administrator ...

 s/can/MUST/, or = s/can/can only/

     ... For example,=20 re-assessment
     may be triggered by a NEA Client if = a User=20 disables a security
     application such as a host = firewall=20 on the Endpoint.

 I don't understand that.  If the = network=20 policy says he MUST run a
firewall, disabling the firewall MUST = result in=20 being kicked off of the
network.  I don't see why re-assessment = is=20 necessary: the user has
declared he is no longer in=20 compliance.


<Kaushik>

The disabling of the = firewall=20 represents a change in posture, the NEA
server is required to assess = the=20 compliance of the endpoint in the light
of the modified posture which = is why=20 reassessment is necessary. The
network access layer (which is out of = scope=20 for NEA discussions) may use
the decision of the reassessment to = implement a=20 policy to boot the user
from the network.

Section 6.2.1 = describes=20 such a use case.


</Kaushik>=20

<FYeh>

ReAssessment is typically = a=20 post-admission event. We are not talking about users who though to be=20 non-compliant coming baclk to retry the admission, we are talking about = users=20 who are thought to be compliant and have already been=20 admitted.

</FYeh>
 
<Kaushik-Response>
 
I am = not sure we need=20 to narrow down the definition of reassessment to just cover the cases = when the=20 endpoint is compliant; Reassessment might occur for a non-compliant = endpoint=20 post remediation.
 
</Kaushik-Response>
 
 
 
     = ;...=20 Re-
     assessment also assists in keeping Endpoints=20 connected to the
     network up to date with fixes = and=20 patches published by
     security application=20 vendors.

 As opposed to simple downloads of the updates? =  It's=20 a lot easier for
many endpoints to periodically query a server, than = it is=20 for a server
to poll many endpoints.


<Kaushik> =

The=20 document describes two models of reassessment, i.e. NEA = client
triggered and=20 NEA server triggered, it is upto deployments to determine
the most = optimum=20 mechanism to employ.

</Kaushik>


 Performing = re-assessment to me indicates that NEA won't scale.

    =  ... Another use of NEA technology
     may be to = supplement information in inventory databases.

 Is this a = charter=20 goal?  If not, why are we discussing it?  NEA *may*
result = in=20 additional information being available to the network admin,
but the=20 maintenance and use of that information is out of scope of=20 NEA.


<Kaushik>

The text purely reflecting a = usage of=20 NEA technology to detect endpoints
and supplement inventory = information. I=20 don't think the text intends to
suggest that the NEA will describe = the=20 definition and maintaince of
inventory databases. Building an = inventory of=20 endpoints is an important
pre-cursor in enterprise deployments of NEA = technology.=20

</Kaushik>

<FYeh>

And= it is=20 not the normal realm of the Network Amdinistrator. What will be required = is for=20 one group to manage the identities and policy reqiurements and another = to manage=20 the network and the various levels of network access. Then the two will = have to=20 agree on how to set policies so that each host is sent to the right = network=20 based on identity and=20 compliance.

</FYeh>


    =  ...=20 In
     organizations that attempt to keep track of = their=20 assets,
     inventory databases tend to be incomplete = and=20 out-of-date.
     NEA technology may be used to verify = or=20 supplement information
     stored about an = organization's=20 assets.

 I suggest deleting that text=20 entirely.

<Kaushik>

Please refer to above comment=20

</Kaushik>

<FYeh>

I = agree=20 with deleting the text. It is far too=20 presumptious!

</FYeh> 
 
<Kaushik-Response>
 
You are = right, my=20 comment to Alan was based on the relevance of the use case. I do agree = that this=20 sentence is not properly worded.
 
regards,
 =20 kaushik
 
</Kaushik-Response>
 

    &= nbsp;...=20 NEA
     technology can also be used to monitor and = report=20 compliance
     for Endpoints when they try to access = certain=20 mission critical
     applications within an = enterprise by=20 employing application
     triggered=20 Assessment.

 Why?  The endpoint knows what posture it=20 satisfies, and the network
admin knows the same thing if he caches = the=20 posture assessment from the
initial network access.  If the = application=20 knows what posture it
requires, why ask the potentially compromised = host,=20 when can instead ask
a trusted source: the network admin?  This = approach=20 could also catch the
case of lying endpoints.  If the network = determines=20 that an endpoint is
lying (i.e. by observing network traffic), it can = update=20 it's view of
the endpoints posture, and inform others on the network = that the=20 device
is not to be=20 trusted.

<FYeh>

IMHO this = perspective=20 places far too much responsibility and authority on the "network admin". = In most=20 large organizations, there are teams of network admins each responsible = for=20 different sections of the network. Expecting these tea0s to suddenly = become the=20 arbiters of who on which endpoint should be running what is completely=20 unrealistic. There a other departments that deal with that data and it = should be=20 left to them.

</FYeh>

<Kaushik> =

This=20 text is not intended to suggest the exchange of posture = information
between=20 the NEA server and applications. This text covers use cases
wherein=20 assessment can be triggered when Layer 5-7 services are
accessed; = Section=20 6.1.2 provides an example of this use=20 case.

Regards,
 kaushik

</Kaushik>


 Alan=20 DeKok.
--
 http://deployingradius.com =20      - The web site of the book
 http://deployingradius.com/blog= / -=20 The blog

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

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

------_=_NextPart_001_01C73602.1E8A8C86-- --===============1852762986== 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 --===============1852762986==-- From nea-bounces@ietf.org Fri Jan 12 09:44:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Ne4-0003Po-G9; Fri, 12 Jan 2007 09:44:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Ne3-0003Pd-I2 for nea@ietf.org; Fri, 12 Jan 2007 09:44:39 -0500 Received: from www.deployingradius.com ([216.240.42.17] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5Ne1-0002h0-SI for nea@ietf.org; Fri, 12 Jan 2007 09:44:39 -0500 Received: from [192.168.123.100] (bas1-ottawa23-1167871498.dsl.bell.ca [69.156.78.10]) by book.deployingradius.com (Postfix) with ESMTP id A817AA71D5; Fri, 12 Jan 2007 06:44:34 -0800 (PST) Message-ID: <45A79DFB.4000002@deployingradius.com> Date: Fri, 12 Jan 2007 09:40:59 -0500 From: Alan DeKok User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Paul Sangster Subject: Re: [Nea] REQ: Section 3 References: <5A58F967CBEBBB4A82DF126CF8A9596A021EB4B4@SVL1XCHCLUPIN02.enterprise.veritas.com> In-Reply-To: <5A58F967CBEBBB4A82DF126CF8A9596A021EB4B4@SVL1XCHCLUPIN02.enterprise.veritas.com> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Paul Sangster wrote: > For -00 it seemed reasonable to talk about both sides of the "and/or" so > the WG could decide whether to allow it to remain. Please note the "or > expected to conform to the policies set forth by the organization" > phrase. We certainly welcome dialog on whether the spec went to far (or > not far enough) in this regard. Both sides of the "and/or" involve endpoints, not networks. The charter is clear: enterprise networks, client endpoints. The requirements document discusses non-enterprise networks as being applicable for NEA. I believe such non-enterprise networks are out of scope. > Does the WG believe we should not claim that scenarios where the > Endpoint is Owned by a different party then the Owner of the network > must always be out of scope? No. It is a charter requirement that the ownership of endpoints can be different than the ownership of the enterprise networks. >> The requirements document SHOULD say that the ISP, etc. >> scenarios are explicitely not being considered. The document >> SHOULD say that NEA SHOULD NOT be used in those scenarios. > > The text gives an ISP oriented example in paragraph 4 and says "NEA is > not expected to be applicable" We could consider making the language > stronger if necessary. Please do so. It should be clear that the ISP deployment of NEA is forbidden due to unknown security, privacy, and legal concerns. And we don't have time to discuss those issues, so they won't be resolved here. > Its my impression that this document provides context and requirements > for NEA protocol selection by the NEA WG. The text suggested reads like > a normative requirement applying to the deployer and not to the NEA WG > selection of appropriate protocols for NEA. It does both. The protocol needs to include the capability that an endpoint can decline an NEA protocol exchange, likely with more than simple silence. > Could this be reworded to > state the NEA WG intentions for how we envision NEA's use (and what it > was designed for) without 2119 language? Likely, yes. I can't suggest much right now. > Again expanding the "..." which seems to be causing confusion the "..." > reads: > That is what this text (see the expanded "..." text above) says. We're > stating where NEA is not applicable in this paragraph. I'm open to > mentioning the charter of our WG if that adds clarity to our NEA > protocol selection process. My concern is less with the elided text than with the phrase "is not expected to". It reads as "we expect to follow the charter requirements", which is more open to non-charter work than "we will follow the charter requirements". > Can you suggest a different word then "intends" which make it more clear > that we aren't planning to include this in our scope. We could change > the last phrase to "so the NEA WG will not address such areas." Yes. > Ok, it was trying to say there are 3 parties involved and if they have > different owners they need to have a contract-based expectation of > conformance and willingness to expose information with each other or > this scenario is not applicable. Will reword. So the parties are: endpoint, network infrastructure owner, and network service provider. Are we really saying that enterprise networks have two owners, who don't mutually disclose security policies? I don't understand. What use-case is satisfied by modeling the enterprise network this way? Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Jan 12 10:17:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5O9n-0006Ku-4P; Fri, 12 Jan 2007 10:17:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5O9l-0006Ko-UA for nea@ietf.org; Fri, 12 Jan 2007 10:17:25 -0500 Received: from www.deployingradius.com ([216.240.42.17] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5O9k-0002xA-GM for nea@ietf.org; Fri, 12 Jan 2007 10:17:25 -0500 Received: from [192.168.123.100] (bas1-ottawa23-1167871498.dsl.bell.ca [69.156.78.10]) by book.deployingradius.com (Postfix) with ESMTP id B839AA71D5; Fri, 12 Jan 2007 07:17:21 -0800 (PST) Message-ID: <45A7A5AA.1020400@deployingradius.com> Date: Fri, 12 Jan 2007 10:13:46 -0500 From: Alan DeKok User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Frank Yeh Jr Subject: Re: [Nea] REQ: Section 4 References: In-Reply-To: X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Frank Yeh Jr wrote: > Even in the context of software and patch management, a single "apply > all patches and updates" profile is extremely limiting. Large > organizations need a little more granularity than this. Examples, please. > The assumption > that all endpoints will have the exact same requirements for Software > and patches is not a sound one. In the absence of examples to the contrary, I'm assuming that all endpoints have software and policies that need periodic changes. In the absence of examples to the contrary, I'm assuming that connected endpoints have software and policies that are kept up to date with respect to network requirements. If one use of NEA is to take out-of-date (i.e. non-compliant) endpoints and give them network access, then I don't understand why we need NEA. We already allow non-compliant endpoints on the network... which was the problem NEA was created to solve. > Making the network keep track of this is > also not a real scalable idea. As per previous discussions on the list, the network does not have to keep track of that information. > First of all, we are not enabling companies to monitor compliance with > this protocol, we are giving them the ability to constrain network > access based on a compliance decision. There are any number of ways to > monitor compliance that have nothing to do with NEA or the network at all. I agree. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Jan 12 14:47:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5SMj-0006Ue-L0; Fri, 12 Jan 2007 14:47:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5SMh-0006TP-OG for nea@ietf.org; Fri, 12 Jan 2007 14:47:03 -0500 Received: from e32.co.us.ibm.com ([32.97.110.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5SMe-00088j-HH for nea@ietf.org; Fri, 12 Jan 2007 14:47:03 -0500 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.13.8/8.12.11) with ESMTP id l0CJjkfG011835 for ; Fri, 12 Jan 2007 14:45:46 -0500 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id l0CJkxpj537392 for ; Fri, 12 Jan 2007 12:46:59 -0700 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 l0CJkwGa026807 for ; Fri, 12 Jan 2007 12:46:59 -0700 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 l0CJkwX5026794; Fri, 12 Jan 2007 12:46:58 -0700 In-Reply-To: <45A7A5AA.1020400@deployingradius.com> Subject: Re: [Nea] REQ: Section 4 To: Alan DeKok X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Frank Yeh Jr Date: Fri, 12 Jan 2007 11:46:53 -0800 X-MIMETrack: Serialize by Router on D03NM129/03/M/IBM(Release 7.0.2HF32 | October 17, 2006) at 01/12/2007 12:46:58 MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: cdeeb24e6b743a852c396a4af0e53c8f 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="===============1671724072==" Errors-To: nea-bounces@ietf.org --===============1671724072== Content-type: multipart/alternative; Boundary="0__=07BBF8F2DFF901938f9e8a93df938690918c07BBF8F2DFF90193" Content-Disposition: inline --0__=07BBF8F2DFF901938f9e8a93df938690918c07BBF8F2DFF90193 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Greetings, Alan DeKok wrote on 01/12/2007 07:13:46 AM:= > Frank Yeh Jr wrote: > > Even in the context of software and patch management, a single "app= ly > > all patches and updates" profile is extremely limiting. Large > > organizations need a little more granularity than this. > > Examples, please. > OK, here is an actual customer scenario that we identified... The organization's network supports various groups of users, each= of which has different access rights. The major groups of users were: Inte= rnal Employees with low-level access (rank and file employees), Internal Employees with high-level access (network and sys admins), Internal Employees with Financial Systems access, Contractors with low-level acc= ess, Contractors with High-level access, Contractors with Financial Systems access, and Untrusted. This set of groups each had different network access and each gro= up required a different policy. Anyone Untrusted really had no requirement= and was given access only to the DMZ. The low-level internal employees and Contractors were basically able to use the "Apply all patches" policy b= ut there were other things being enforced such as the age and length of th= e Windows Password. So even these low-level accessors were required to ch= ange their passwords periodically. In addition, a record that these low-leve= l users had signed the Company's EULA before proceeding into their networ= k can be recorded and used as a condition for access (we did not roll it out). The next sets of users, the admins with privileged access, were required to have stronger security settings on their endpoints and also= had some additional scanning and client firewall software that had to be running in order to get into the administrative network. The final set,= with access to the Financial Systems, were required to have the right client software loaded and that also had to be patched and licensed. So each set of users had a different set of requirements to meet = for access to different parts of the network. Is that enough or do you want more? > > The assumption > > that all endpoints will have the exact same requirements for Softwa= re > > and patches is not a sound one. > > In the absence of examples to the contrary, I'm assuming that all > endpoints have software and policies that need periodic changes. Hopefully, the example of the untrusted host who can have access = to a corporate web site will work. The lowest level of endpoint will have absolutely no compliance to policy. A great example of this is when eve= nts have onsite network access for reporters who bring in their own laptops= . It is pretty easy to say that if you do not have the right client software= that you are an untrusted host and get left in the public network. Simultaneously, you might have an admin with his own laptop that is in = the press room supporting someone and he needs administrative access from t= he press room. He plugs in and since he is running the right software and = is authenticated as an admin, he gets in with a whole different level of network access than the reporter plugged into the next port. Wireless m= akes this even more valuable. > In the > absence of examples to the contrary, I'm assuming that connected > endpoints have software and policies that are kept up to date with > respect to network requirements. > I believe that many will but it cannot be assumed that this softw= are is under management or a condition of access for all deployments. > If one use of NEA is to take out-of-date (i.e. non-compliant) > endpoints and give them network access, then I don't understand why w= e > need NEA. We already allow non-compliant endpoints on the network...= > which was the problem NEA was created to solve. > Strong Agreement!!! > > Making the network keep track of this is > > also not a real scalable idea. > > As per previous discussions on the list, the network does not have = to > keep track of that information. > I wish it were not even implied that this is doable. I think it i= s a bad idea that will never scale, but I've been wrong before_ lots of tim= es, so maybe someone will prove me wrong in this case. My personal experien= ce is that this implication will cause more trouble than it is worth. Regards, Frank Yeh= --0__=07BBF8F2DFF901938f9e8a93df938690918c07BBF8F2DFF90193 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Greetings,


Alan DeKok <aland@deployingradius.com> wrote on 01/12/2007 07= :13:46 AM:

> Frank Yeh Jr wrote:
> > Even in the context of software and patch management, a singl= e "apply
> > all patches and updates" profile is extremely limiting. = Large
> > organizations need a little more granularity than this.
>
>   Examples, please.
>

OK, here is an actual customer scenario that we identified...=

The organization's network supports various groups of users, each = of which has different access rights. The major groups of users were: I= nternal Employees with low-level access (rank and file employees), Inte= rnal Employees with high-level access (network and sys admins), Interna= l Employees with Financial Systems access, Contractors with low-level a= ccess, Contractors with High-level access, Contractors with Financial S= ystems access, and Untrusted.

This set of groups each had different network access and each grou= p required a different policy. Anyone Untrusted really had no requireme= nt and was given access only to the DMZ. The low-level internal employe= es and Contractors were basically able to use the "Apply all patch= es" policy but there were other things being enforced such as the = age and length of the Windows Password. So even these low-level accesso= rs were required to change their passwords periodically. In addition, a= record that these low-level users had signed the Company's EULA before= proceeding into their network can be recorded and used as a condition = for access (we did not roll it out).

The next sets of users, the admins with privileged access, were re= quired to have stronger security settings on their endpoints and also h= ad some additional scanning and client firewall software that had to be= running in order to get into the administrative network. The final set= , with access to the Financial Systems, were required to have the right= client software loaded and that also had to be patched and licensed.

So each set of users had a different set of requirements to meet f= or access to different parts of the network.

Is that enough or do you want more?

> > The assumption
> > that all endpoints will have the exact same requirements for = Software
> > and patches is not a sound one.
>
>   In the absence of examples to the contrary, I'm assuming th= at all
> endpoints have software and policies that need periodic changes.

Hopefully, the example of the untrusted host who can have access t= o a corporate web site will work. The lowest level of endpoint will hav= e absolutely no compliance to policy. A great example of this is when e= vents have onsite network access for reporters who bring in their own l= aptops. It is pretty easy to say that if you do not have the right clie= nt software that you are an untrusted host and get left in the public n= etwork. Simultaneously, you might have an admin with his own laptop tha= t is in the press room supporting someone and he needs administrative a= ccess from the press room. He plugs in and since he is running the righ= t software and is authenticated as an admin, he gets in with a whole di= fferent level of network access than the reporter plugged into the next= port. Wireless makes this even more valuable.

>  In the
> absence of examples to the contrary, I'm assuming that connected > endpoints have software and policies that are kept up to date with=
> respect to network requirements.
>

I believe that many will but it cannot be assumed that this softwa= re is under management or a condition of access for all deployments.

>   If one use of NEA is to take out-of-date (i.e. non-complian= t)
> endpoints and give them network access, then I don't understand wh= y we
> need NEA.  We already allow non-compliant endpoints on the ne= twork...
> which was the problem NEA was created to solve.
>

Strong Agreement!!!

> > Making the network keep track of this is
> > also not a real scalable idea.
>
>   As per previous discussions on the list, the network does n= ot have to
> keep track of that information.
>

I wish it were not even implied that this is doable. I think it is= a bad idea that will never scale, but I've been wrong before_ lots of = times, so maybe someone will prove me wrong in this case. My personal e= xperience is that this implication will cause more trouble than it is w= orth.

Regards,
Frank Yeh= --0__=07BBF8F2DFF901938f9e8a93df938690918c07BBF8F2DFF90193-- --===============1671724072== 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 --===============1671724072==-- From nea-bounces@ietf.org Fri Jan 12 15:12:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Sl7-0005eu-0M; Fri, 12 Jan 2007 15:12:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Sl5-0005eX-Gt for nea@ietf.org; Fri, 12 Jan 2007 15:12:15 -0500 Received: from e33.co.us.ibm.com ([32.97.110.151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H5Sl2-0005Q4-W0 for nea@ietf.org; Fri, 12 Jan 2007 15:12:15 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e33.co.us.ibm.com (8.13.8/8.12.11) with ESMTP id l0CKCCPU009689 for ; Fri, 12 Jan 2007 15:12:12 -0500 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by westrelay02.boulder.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id l0CKCCRd515394 for ; Fri, 12 Jan 2007 13:12:12 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0CKCBhZ002367 for ; Fri, 12 Jan 2007 13:12:11 -0700 Received: from d03nm129.boulder.ibm.com (d03nm129.boulder.ibm.com [9.17.195.155]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0CKCBTT002353; Fri, 12 Jan 2007 13:12:11 -0700 In-Reply-To: <618694EF0B657246A4D55A97E38274C302CE72B8@xmb-sjc-22d.amer.cisco.com> Subject: RE: [Nea] REQ: Section 4 To: "Kaushik Narayan \(kaushik\)" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Frank Yeh Jr Date: Fri, 12 Jan 2007 12:11:59 -0800 X-MIMETrack: Serialize by Router on D03NM129/03/M/IBM(Release 7.0.2HF32 | October 17, 2006) at 01/12/2007 13:12:10 MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee 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="===============0263720595==" Errors-To: nea-bounces@ietf.org --===============0263720595== Content-type: multipart/alternative; Boundary="0__=07BBF8F2DFFF29A68f9e8a93df938690918c07BBF8F2DFFF29A6" Content-Disposition: inline --0__=07BBF8F2DFFF29A68f9e8a93df938690918c07BBF8F2DFFF29A6 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Greetings Kaushik, Thanks for your comments, I understand your points much better n= ow and I am pretty much in agreement. Severely stripped down version of the thread follows with my in-l= ine comments. Regards, Frank Yeh Corporate Security Strategy Team IBM Tivoli Software "Kaushik Narayan \(kaushik\)" wrote on 01/11/2007 08:28:31 PM: > Hi Frank, > > Please find my response inline. I have used the tag > > > > > > > > I think we are in agreement; as I mentioned in my previous email, > NEA protocols cannot limit what attributes that get validated since > that is part of the policies of the organization that deploys NEA. > My statement about patch management was that use cases from that > area are not going to primarily drive protocol requirements. > > > Well Said. I confused your previous statement to mean that they would! LOL > > > > That's true. I do believe that "apply all patches" is just a policy > and the NEA protocols need to support posture attribute requests and > assessment policies at different levels of granularity. > > The network won't really keep track of what software patches, I was > pointing out that NEA might not necessarily discard decisions from > prior assessments and the Reference Model specifies assertion > attributes that can be used to reflect decisions from a prior assessm= ent. > > DOH! I had repressed the prior assessments part. I am still very = much a proponent of the network doing as little decision making as possible = and the server-side validator making all possible decisions. OK, my bad on that one. > > > > I am not sure we need to narrow down the definition of reassessment > to just cover the cases when the endpoint is compliant; Reassessment > might occur for a non-compliant endpoint post remediation. > > > Fair enough. So reassessment can simply have the normal english definition of being assessed again. We can further differentiate pre-admission and post-admission reassessment with pre-admission implyi= ng hosts that have previusly been denied network access going through the admission process again and post-admission implying hosts already admit= ted on the network being checked for state changes after admission. I'm not= sure there is a lot of value in differentiating pre-admission reassessm= ent and pre-admission initial assessment unless we wanted to implement some= sort of failure threshold like timing out a session after too many fail= ed attempts. Regards, Frank= --0__=07BBF8F2DFFF29A68f9e8a93df938690918c07BBF8F2DFFF29A6 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Greetings Kaushik,

Thanks for your comments, I understand your points much better now an= d I am pretty much in agreement.

Severely stripped down version of the thread follows with my in-line c= omments.

Regards,
Frank Yeh
Corporate Security Strategy Team
IBM
Tivoli Software


"Kaushik Narayan \(kaushik\)" <kaushik@cisco.com> w= rote on 01/11/2007 08:28:31 PM:

> Hi Frank,
>  
> Please find my response inline. I have used the tag <Kaushi= k-Response>
>  
>  
> <snipped>
>  
>  
> <Kaushik-Response>
>  
> I think we are in agreement; as I mentioned in my previous ema= il,
> NEA protocols cannot limit what attributes that get validated sinc= e
> that is part of the policies of the organization that deploys NEA.=
> My statement about patch management was that use cases from that <= br> > area are not going to primarily drive protocol requirements.<= br> >  
> </Kaushik-Response>
>

Well Said. I confused your previous statement to mean that they wo= uld! LOL

<SNIP>

>  
> <Kaushik-Response>
>  
> That's true. I do believe that "apply all patches" i= s just a policy
> and the NEA protocols need to support posture attribute requests a= nd
> assessment policies at different levels of granularity.
>  
> The network won't really keep track of what software patches, = I was
> pointing out that NEA might not necessarily discard decisions from=
> prior assessments and the Reference Model specifies assertion
= > attributes that can be used to reflect decisions from a prior asse= ssment.
>  
> </Kaushik-Response>

DOH! I had repressed the prior assessments part. I am still very m= uch a proponent of the network doing as little decision making as possi= ble and the server-side validator making all possible decisions.
OK, my bad on that one.

<SNIP>

>  
> <Kaushik-Response>
>  
> I am not sure we need to narrow down the definition of reasses= sment
> to just cover the cases when the endpoint is compliant; Reassessme= nt
> might occur for a non-compliant endpoint post remediation. >  
> </Kaushik-Response>
>  

Fair enough. So reassessment can simply have the normal english de= finition of being assessed again. We can further differentiate pre-admi= ssion and post-admission reassessment with pre-admission implying hosts= that have previusly been denied network access going through the admis= sion process again and post-admission implying hosts already admitted o= n the network being checked for state changes after admission. I'm not = sure there is a lot of value in differentiating pre-admission reassessm= ent and pre-admission initial assessment unless we wanted to implement = some sort of failure threshold like timing out a session after too many= failed attempts.

Regards,
Frank= --0__=07BBF8F2DFFF29A68f9e8a93df938690918c07BBF8F2DFFF29A6-- --===============0263720595== 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 --===============0263720595==-- From nea-bounces@ietf.org Sun Jan 14 11:29:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H68Em-0008WV-L5; Sun, 14 Jan 2007 11:29:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H68Ek-0008WD-1G for nea@ietf.org; Sun, 14 Jan 2007 11:29:38 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H68Ei-0005Es-De for nea@ietf.org; Sun, 14 Jan 2007 11:29:38 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 14 Jan 2007 08:29:36 -0800 X-IronPort-AV: i="4.13,186,1167638400"; d="scan'208,217"; a="101463785:sNHT82293795" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l0EGTZGN010220; Sun, 14 Jan 2007 08:29:35 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l0EGTUUw027145; Sun, 14 Jan 2007 08:29:35 -0800 (PST) Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 14 Jan 2007 08:29:28 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Nea] REQ: Section 4 Date: Sun, 14 Jan 2007 08:29:27 -0800 Message-ID: <618694EF0B657246A4D55A97E38274C302CE76B7@xmb-sjc-22d.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] REQ: Section 4 Thread-Index: Acc2hfmUAXTtYjsqSkeoLOtrKAsYjQBcOXSw From: "Kaushik Narayan \(kaushik\)" To: "Frank Yeh Jr" X-OriginalArrivalTime: 14 Jan 2007 16:29:28.0638 (UTC) FILETIME=[2985FDE0:01C737F9] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5613; t=1168792175; x=1169656175; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kaushik@cisco.com; z=From:=20=22Kaushik=20Narayan=20\(kaushik\)=22=20 |Subject:=20RE=3A=20[Nea]=20REQ=3A=20Section=204 |Sender:=20; bh=j3lRsJMSAS9Bp5tZyNJVIGKbJbXJzQE29+qUHxg4EfU=; b=iForxcY5yiDt6duzWv4sh535KoR2HeWWzkmk32sEeFv/t5ABBYyrwPBn9mTnxzFWQr6ItApJ zhcMyQsPsk7vHbhXS/QDnVOW0Q5GXOVipSUN0iRsknsab5NRTTXtupa6; Authentication-Results: sj-dkim-3; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc 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="===============2143910968==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============2143910968== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C737F9.295182E3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C737F9.295182E3 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Frank, =20 Please find my reply inline.=20 =20 =20 > =20 > > =20 > I am not sure we need to narrow down the definition of reassessment=20 > to just cover the cases when the endpoint is compliant; Reassessment > might occur for a non-compliant endpoint post remediation. > =20 > > =20 Fair enough. So reassessment can simply have the normal english definition of being assessed again. We can further differentiate pre-admission and post-admission reassessment with pre-admission implying hosts that have previusly been denied network access going through the admission process again and post-admission implying hosts already admitted on the network being checked for state changes after admission. I'm not sure there is a lot of value in differentiating pre-admission reassessment and pre-admission initial assessment unless we wanted to implement some sort of failure threshold like timing out a session after too many failed attempts. =20 =20 =20 I am not sure we need to differentiate between pre-admission and post-admission. Essentially reassessment is triggered when either the NEA client or NEA server detects a change in the posture on the endpoint. The endpoint can either be compliant or non-compliant prior to the reassessment. =20 regards, kaushik =20 =20 =20 Regards, Frank ------_=_NextPart_001_01C737F9.295182E3 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi Frank,
 
Please find my reply inline. =
 
 <snipped> 
>=20  
> <Kaushik-Response>
>=20  
> I am not sure we need to narrow down the = definition of=20 reassessment
> to just cover the cases when the endpoint is = compliant;=20 Reassessment
> might occur for a non-compliant endpoint post=20 remediation.
>  
>=20 </Kaushik-Response>
>  

Fair = enough.=20 So reassessment can simply have the normal english definition of being = assessed=20 again. We can further differentiate pre-admission and post-admission=20 reassessment with pre-admission implying hosts that have previusly been = denied=20 network access going through the admission process again and = post-admission=20 implying hosts already admitted on the network being checked for state = changes=20 after admission. I'm not sure there is a lot of value in differentiating = pre-admission reassessment and pre-admission initial assessment unless = we wanted=20 to implement some sort of failure threshold like timing out a session = after too=20 many failed attempts.
 
 
<Kaushik-Response-II>
 
I am=20 not sure we need to differentiate between pre-admission and = post-admission.=20 Essentially reassessment is triggered when either the NEA = client or NEA=20 server detects a change in the posture on the endpoint. The endpoint can = either=20 be compliant or non-compliant prior to the = reassessment.
 
regards,
 =20 kaushik
 
<Kaushik-Response-II>
 
 
Regards,
Fran= k
------_=_NextPart_001_01C737F9.295182E3-- --===============2143910968== 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 --===============2143910968==-- From nea-bounces@ietf.org Sun Jan 14 12:22:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6940-0002ZB-2n; Sun, 14 Jan 2007 12:22:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H693y-0002Z6-R0 for nea@ietf.org; Sun, 14 Jan 2007 12:22:34 -0500 Received: from www.deployingradius.com ([216.240.42.17] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H693w-0005Jo-DY for nea@ietf.org; Sun, 14 Jan 2007 12:22:34 -0500 Received: from [10.0.0.21] (AGrenoble-257-1-84-73.w86-219.abo.wanadoo.fr [86.219.19.73]) by book.deployingradius.com (Postfix) with ESMTP id D5C3FA71D3; Sun, 14 Jan 2007 09:22:23 -0800 (PST) Message-ID: <45AA65F6.4060706@deployingradius.com> Date: Sun, 14 Jan 2007 12:18:46 -0500 From: Alan DeKok User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Frank Yeh Jr Subject: Re: [Nea] REQ: Section 4 References: In-Reply-To: X-Enigmail-Version: 0.94.1.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 Frank Yeh Jr wrote: ... > OK, here is an actual customer scenario that we identified... ... > So each set of users had a different set of requirements to meet for > access to different parts of the network. > > Is that enough or do you want more? Those are good scenarios, but not quite what I was getting at. You described different classes of users, each of whom had differing policies that were enforced. However, what I was getting at was the *status* of the endpoints. My question is: For any given class of users, what happens when the NEA server determines that the endpoint is not up to date with respect to the policy for that class? >> In the >> absence of examples to the contrary, I'm assuming that connected >> endpoints have software and policies that are kept up to date with >> respect to network requirements. > > I believe that many will but it cannot be assumed that this software is > under management or a condition of access for all deployments. Then any machines that are *not* up to date are in many respects treated the same as machines not using NEA, right? After all, if a machines virus scanner is out of date, it could very well be running that virus. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Jan 15 16:07:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6Z35-0008T9-4l; Mon, 15 Jan 2007 16:07:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6Z33-0008PC-CW for nea@ietf.org; Mon, 15 Jan 2007 16:07:21 -0500 Received: from e36.co.us.ibm.com ([32.97.110.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6Z2y-0003ld-Un for nea@ietf.org; Mon, 15 Jan 2007 16:07:21 -0500 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e36.co.us.ibm.com (8.13.8/8.12.11) with ESMTP id l0FL7BT6027116 for ; Mon, 15 Jan 2007 16:07:11 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0FL7Bd1491190 for ; Mon, 15 Jan 2007 14:07:11 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0FL7BaV030617 for ; Mon, 15 Jan 2007 14:07:11 -0700 Received: from d03nm129.boulder.ibm.com (d03nm129.boulder.ibm.com [9.17.195.155]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0FL7AAp030598; Mon, 15 Jan 2007 14:07:10 -0700 In-Reply-To: <45AA65F6.4060706@deployingradius.com> Subject: Re: [Nea] REQ: Section 4 To: Alan DeKok X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Frank Yeh Jr Date: Mon, 15 Jan 2007 13:07:03 -0800 X-MIMETrack: Serialize by Router on D03NM129/03/M/IBM(Release 7.0.2HF32 | October 17, 2006) at 01/15/2007 14:07:10 MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f 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="===============1870989882==" Errors-To: nea-bounces@ietf.org --===============1870989882== Content-type: multipart/alternative; Boundary="0__=07BBF8F7DFE068C68f9e8a93df938690918c07BBF8F7DFE068C6" Content-Disposition: inline --0__=07BBF8F7DFE068C68f9e8a93df938690918c07BBF8F7DFE068C6 Content-type: text/plain; charset=US-ASCII Greeting, Alan DeKok wrote on 01/14/2007 09:18:46 AM: > Frank Yeh Jr wrote: > ... > > OK, here is an actual customer scenario that we identified... > ... > > So each set of users had a different set of requirements to meet for > > access to different parts of the network. > > > > Is that enough or do you want more? > > Those are good scenarios, but not quite what I was getting at. You > described different classes of users, each of whom had differing > policies that were enforced. However, what I was getting at was the > *status* of the endpoints. > > My question is: For any given class of users, what happens when the > NEA server determines that the endpoint is not up to date with respect > to the policy for that class? > > >> In the > >> absence of examples to the contrary, I'm assuming that connected > >> endpoints have software and policies that are kept up to date with > >> respect to network requirements. > > > > I believe that many will but it cannot be assumed that this software is > > under management or a condition of access for all deployments. > > Then any machines that are *not* up to date are in many respects > treated the same as machines not using NEA, right? After all, if a > machines virus scanner is out of date, it could very well be running > that virus. > > Alan DeKok. > -- > http://deployingradius.com - The web site of the book > http://deployingradius.com/blog/ - The blog Frank Yeh Security & Privacy Technology Integration Team IBM Tivoli Software --0__=07BBF8F7DFE068C68f9e8a93df938690918c07BBF8F7DFE068C6 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

Greeting,




Alan DeKok <aland@deployingradius.com> wrote on 01/14/2007 09:18:46 AM:

> Frank Yeh Jr wrote:
> ...
> > OK, here is an actual customer scenario that we identified...
> ...
> > So each set of users had a different set of requirements to meet for
> > access to different parts of the network.
> >
> > Is that enough or do you want more?
>
>   Those are good scenarios, but not quite what I was getting at.  You
> described different classes of users, each of whom had differing
> policies that were enforced.  However, what I was getting at was the
> *status* of the endpoints.
>
>   My question is:  For any given class of users, what happens when the
> NEA server determines that the endpoint is not up to date with respect
> to the policy for that class?
>
> >>  In the
> >> absence of examples to the contrary, I'm assuming that connected
> >> endpoints have software and policies that are kept up to date with
> >> respect to network requirements.
> >
> > I believe that many will but it cannot be assumed that this software is
> > under management or a condition of access for all deployments.
>
>   Then any machines that are *not* up to date are in many respects
> treated the same as machines not using NEA, right?  After all, if a
> machines virus scanner is out of date, it could very well be running
> that virus.
>
>   Alan DeKok.
> --
>   http://deployingradius.com       - The web site of the book
>   http://deployingradius.com/blog/ - The blog

Frank Yeh
Security & Privacy Technology Integration Team
IBM
Tivoli Software --0__=07BBF8F7DFE068C68f9e8a93df938690918c07BBF8F7DFE068C6-- --===============1870989882== 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 --===============1870989882==-- From nea-bounces@ietf.org Mon Jan 15 16:25:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6ZKt-00024L-OH; Mon, 15 Jan 2007 16:25:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6ZKs-000246-Ia for nea@ietf.org; Mon, 15 Jan 2007 16:25:46 -0500 Received: from e36.co.us.ibm.com ([32.97.110.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6ZKq-0006Xo-Un for nea@ietf.org; Mon, 15 Jan 2007 16:25:46 -0500 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e36.co.us.ibm.com (8.13.8/8.12.11) with ESMTP id l0FLPc79030815 for ; Mon, 15 Jan 2007 16:25:38 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0FLPcuq548468 for ; Mon, 15 Jan 2007 14:25:38 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0FLPbOv007482 for ; Mon, 15 Jan 2007 14:25:38 -0700 Received: from d03nm129.boulder.ibm.com (d03nm129.boulder.ibm.com [9.17.195.155]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0FLPb5g007474; Mon, 15 Jan 2007 14:25:37 -0700 In-Reply-To: <618694EF0B657246A4D55A97E38274C302CE76B7@xmb-sjc-22d.amer.cisco.com> Subject: RE: [Nea] REQ: Section 4 To: "Kaushik Narayan \(kaushik\)" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Frank Yeh Jr Date: Mon, 15 Jan 2007 13:25:30 -0800 X-MIMETrack: Serialize by Router on D03NM129/03/M/IBM(Release 7.0.2HF32 | October 17, 2006) at 01/15/2007 14:25:36 MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a 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="===============2034366606==" Errors-To: nea-bounces@ietf.org --===============2034366606== Content-type: multipart/alternative; Boundary="0__=07BBF8F7DFE781988f9e8a93df938690918c07BBF8F7DFE78198" Content-Disposition: inline --0__=07BBF8F7DFE781988f9e8a93df938690918c07BBF8F7DFE78198 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Greetings, Oops, hit send by mistake on the previous email before I actually= got any content in. DOH! Here is my real rely. :-D "Kaushik Narayan \(kaushik\)" wrote on 01/14/2007 08:29:27 AM: > Hi Frank, > > Please find my reply inline. > > > > > > > > > > I am not sure we need to narrow down the definition of reassessment= > > to just cover the cases when the endpoint is compliant; Reassessmen= t > > might occur for a non-compliant endpoint post remediation. > > > > > > > > Fair enough. So reassessment can simply have the normal english > definition of being assessed again. We can further differentiate > pre-admission and post-admission reassessment with pre-admission > implying hosts that have previusly been denied network access going > through the admission process again and post-admission implying > hosts already admitted on the network being checked for state > changes after admission. I'm not sure there is a lot of value in > differentiating pre-admission reassessment and pre-admission initial > assessment unless we wanted to implement some sort of failure > threshold like timing out a session after too many failed attempts. > > > > > I am not sure we need to differentiate between pre-admission and > post-admission. Essentially reassessment is triggered when either > the NEA client or NEA server detects a change in the posture on the > endpoint. The endpoint can either be compliant or non-compliant > prior to the reassessment. > > regards, > kaushik > > > > > Regards, > Frank I think post VS pre admission is relevant. Pre-admission cases ca= n be inferred to be users who do not have the proper conditions when they fi= rst attach. This will be typical when new patches come out., black Tuesdays= being a prime example. Post-admission cases are typically users who hav= e met the conditions for admission but then decide to disable or remove something so that they are no longer compliant but already have access.= The two are significant from a governance standpoint. The first is a normal= consequence of doing business, the second is a violation of corporate policies. The responses to these different cases should be different. Regards, Frank Yeh IBM Global Technology Services Security & Privacy Integration Team= --0__=07BBF8F7DFE781988f9e8a93df938690918c07BBF8F7DFE78198 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Greetings,

Oops, hit send by mistake on the previous email before I actually got = any content in. DOH!

Here is my real rely. :-D


"Kaushik Narayan \(kaushik\)" <kaushik@cisco.com> w= rote on 01/14/2007 08:29:27 AM:

> Hi Frank,
>  
> Please find my reply inline.
>  
>  <snipped>
> >  
> > <Kaushik-Response>
> >  
> > I am not sure we need to narrow down the definition of reasse= ssment
> > to just cover the cases when the endpoint is compliant; Reass= essment
> > might occur for a non-compliant endpoint post remediation. > >  
> > </Kaushik-Response>
> >  
>
> Fair enough. So reassessment can simply have the normal english > definition of being assessed again. We can further differentiate <= br> > pre-admission and post-admission reassessment with pre-admission <= br> > implying hosts that have previusly been denied network access goin= g
> through the admission process again and post-admission implying > hosts already admitted on the network being checked for state
= > changes after admission. I'm not sure there is a lot of value in <= br> > differentiating pre-admission reassessment and pre-admission initi= al
> assessment unless we wanted to implement some sort of failure
= > threshold like timing out a session after too many failed attempts= .
>  
>  
> <Kaushik-Response-II>
>  
> I am not sure we need to differentiate between pre-admission a= nd
> post-admission. Essentially reassessment is triggered when either =
> the NEA client or NEA server detects a change in the posture on th= e
> endpoint. The endpoint can either be compliant or non-compliant > prior to the reassessment.
>  
> regards,
>   kaushik
>  
> <Kaushik-Response-II>
>  
>  
> Regards,
> Frank

I think post VS pre admission is relevant. Pre-admission cases can be = inferred to be users who do not have the proper conditions when they fi= rst attach. This will be typical when new patches come out., black Tues= days being a prime example. Post-admission cases are typically users wh= o have met the conditions for admission but then decide to disable or r= emove something so that they are no longer compliant but already have a= ccess. The two are significant from a governance standpoint. The first = is a normal consequence of doing business, the second is a violation of= corporate policies. The responses to these different cases should be d= ifferent.

Regards,
Frank Yeh
IBM
Global Technology Services
Security & Privacy Integration Team
= --0__=07BBF8F7DFE781988f9e8a93df938690918c07BBF8F7DFE78198-- --===============2034366606== 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 --===============2034366606==-- From nea-bounces@ietf.org Mon Jan 15 23:28:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6fvJ-0005pq-0q; Mon, 15 Jan 2007 23:27:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6fvH-0005pl-SB for nea@ietf.org; Mon, 15 Jan 2007 23:27:47 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6fvF-0007nF-5m for nea@ietf.org; Mon, 15 Jan 2007 23:27:47 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 15 Jan 2007 20:27:44 -0800 X-IronPort-AV: i="4.13,193,1167638400"; d="scan'208,217"; a="457488915:sNHT91584464" 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 l0G4RiAv021328; Mon, 15 Jan 2007 20:27:44 -0800 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 l0G4RiDk001655; Mon, 15 Jan 2007 20:27:44 -0800 (PST) Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 Jan 2007 20:27:44 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Nea] REQ: Section 4 Date: Mon, 15 Jan 2007 20:27:42 -0800 Message-ID: <618694EF0B657246A4D55A97E38274C302CE786A@xmb-sjc-22d.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] REQ: Section 4 Thread-Index: Acc467fFhTgYYGjIT7eHK7kbIZStIQANHvgA From: "Kaushik Narayan \(kaushik\)" To: "Frank Yeh Jr" X-OriginalArrivalTime: 16 Jan 2007 04:27:44.0020 (UTC) FILETIME=[AAC92D40:01C73926] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8474; t=1168921664; x=1169785664; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kaushik@cisco.com; z=From:=20=22Kaushik=20Narayan=20\(kaushik\)=22=20 |Subject:=20RE=3A=20[Nea]=20REQ=3A=20Section=204 |Sender:=20; bh=zCXPkVx8RhNNFdUmBKI4tPqopZDylpZZFk0cVcMqeps=; b=gMumEtI/J00MjypJQSxY4jJe/3SJsyqSIUQTN0iNZpDwVca54EXjjkpZzVf6yHxXyd/l6gs3 4xcChkUOZ/P8SV6LsxLE77Zg67l9UuVTPVhSiZyDiJ6adCJ1xkfUKG9K; Authentication-Results: sj-dkim-4; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 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="===============1108106798==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============1108106798== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73926.AA8D5F9A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C73926.AA8D5F9A Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Frank, =20 Please find my respone below (it's right at the end). =20 > > =20 > > > > =20 > > I am not sure we need to narrow down the definition of reassessment=20 > > to just cover the cases when the endpoint is compliant; Reassessment > > might occur for a non-compliant endpoint post remediation. > > =20 > > > > =20 >=20 > Fair enough. So reassessment can simply have the normal english=20 > definition of being assessed again. We can further differentiate=20 > pre-admission and post-admission reassessment with pre-admission=20 > implying hosts that have previusly been denied network access going=20 > through the admission process again and post-admission implying=20 > hosts already admitted on the network being checked for state=20 > changes after admission. I'm not sure there is a lot of value in=20 > differentiating pre-admission reassessment and pre-admission initial > assessment unless we wanted to implement some sort of failure=20 > threshold like timing out a session after too many failed attempts. > =20 > =20 > > =20 > I am not sure we need to differentiate between pre-admission and=20 > post-admission. Essentially reassessment is triggered when either=20 > the NEA client or NEA server detects a change in the posture on the=20 > endpoint. The endpoint can either be compliant or non-compliant=20 > prior to the reassessment. I think post VS pre admission is relevant. Pre-admission cases can be inferred to be users who do not have the proper conditions when they first attach. This will be typical when new patches come out., black Tuesdays being a prime example. Post-admission cases are typically users who have met the conditions for admission but then decide to disable or remove something so that they are no longer compliant but already have access. The two are significant from a governance standpoint. The first is a normal consequence of doing business, the second is a violation of corporate policies. The responses to these different cases should be different.=20 I just want to clarify that we are still talking about re-assessment. I was suggesting that there may not be much value in trying to differentiate between pre vs post admission scenarios for re-assessment since unlike initial assessment where the network may have to play a role (trigger) in the assessment (especially for scenarios of assessment prior to network access), the process of reassessment is completely driven by the NEA client or server components. The NEA protocol considerations for re-assessment probably need not influenced by whether endpoint was assessed to be compliant as a result of the prior assessment and provided regular access to the network or whether the endpoint was assessed to be non-compliant and denied access or provided access only to the quarantine network. regards,=20 kaushik ------_=_NextPart_001_01C73926.AA8D5F9A Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi Frank,
 
Please find  my respone below (it's right = at the=20 end).
 
<snipped>

> >  
> >=20 <Kaushik-Response>
> >  
> > I am not sure = we need=20 to narrow down the definition of reassessment
> > to just = cover the=20 cases when the endpoint is compliant; Reassessment
> > might = occur for=20 a non-compliant endpoint post remediation.
> >  
> = >=20 </Kaushik-Response>
> >  
>
> Fair = enough. So=20 reassessment can simply have the normal english
> definition of = being=20 assessed again. We can further differentiate
> pre-admission and=20 post-admission reassessment with pre-admission
> implying hosts = that have=20 previusly been denied network access going
> through the = admission=20 process again and post-admission implying
> hosts already = admitted on the=20 network being checked for state
> changes after admission. I'm = not sure=20 there is a lot of value in
> differentiating pre-admission = reassessment=20 and pre-admission initial
> assessment unless we wanted to = implement some=20 sort of failure
> threshold like timing out a session after too = many=20 failed attempts.
>  
> =  
>=20 <Kaushik-Response-II>
>  
> I = am not=20 sure we need to differentiate between pre-admission and
> = post-admission.=20 Essentially reassessment is triggered when either
> the NEA = client or NEA=20 server detects a change in the posture on the
> endpoint. The = endpoint=20 can either be compliant or non-compliant
> prior to the=20 reassessment.


I think post VS pre admission is relevant. Pre-admission cases = can be=20 inferred to be users who do not have the proper conditions when they = first=20 attach. This will be typical when new patches come out., black Tuesdays = being a=20 prime example. Post-admission cases are typically users who have met the = conditions for admission but then decide to disable or remove something = so that=20 they are no longer compliant but already have access. The two are = significant=20 from a governance standpoint. The first is a normal consequence of doing = business, the second is a violation of corporate policies. The responses = to=20 these different cases should be different. 

<Kaushik>

I just=20 want to clarify that we are still talking about re-assessment. I=20 was suggesting that there may not be much value in = trying to=20 differentiate between pre vs post admission scenarios for = re-assessment=20 since unlike initial assessment where the network may have to play = a role=20 (trigger) in the assessment (especially for scenarios of assessment = prior=20 to network access), the process of  reassessment is completely = driven by=20 the NEA client or server components. The NEA protocol considerations for = re-assessment probably need not influenced by whether = endpoint was=20 assessed to be compliant as a result of the prior assessment and = provided=20 regular access to the network or whether the endpoint was assessed to be = non-compliant and denied access or provided access only to the = quarantine=20 network.

regards,=20

 =20 kaushik

------_=_NextPart_001_01C73926.AA8D5F9A-- --===============1108106798== 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 --===============1108106798==-- From nea-bounces@ietf.org Tue Jan 16 01:51:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6iAa-0006Tf-LK; Tue, 16 Jan 2007 01:51:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6iAZ-0006TZ-3q for nea@ietf.org; Tue, 16 Jan 2007 01:51:43 -0500 Received: from www.deployingradius.com ([216.240.42.17] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6iAX-00061i-Nt for nea@ietf.org; Tue, 16 Jan 2007 01:51:43 -0500 Received: from [10.0.0.21] (AGrenoble-257-1-76-115.w86-211.abo.wanadoo.fr [86.211.139.115]) by book.deployingradius.com (Postfix) with ESMTP id C27ADA7067; Mon, 15 Jan 2007 22:51:33 -0800 (PST) Message-ID: <45AC75F5.7070201@deployingradius.com> Date: Tue, 16 Jan 2007 07:51:33 +0100 From: Alan DeKok User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Frank Yeh Jr Subject: Re: [Nea] REQ: Section 4 References: In-Reply-To: X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Frank Yeh Jr wrote: >... Post-admission cases are typically users > who have met the conditions for admission but then decide to disable or > remove something so that they are no longer compliant but already have > access. The two are significant from a governance standpoint. The first > is a normal consequence of doing business, the second is a violation of > corporate policies. The responses to these different cases should be > different. How is the post-admission case different from a user who disables something *prior* to obtaining network access? How would the system handle that case? Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Jan 16 13:42:32 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6tGP-0007e6-KL; Tue, 16 Jan 2007 13:42:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6tGO-0007dy-RV for nea@ietf.org; Tue, 16 Jan 2007 13:42:28 -0500 Received: from e36.co.us.ibm.com ([32.97.110.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6tGM-0000Hn-EE for nea@ietf.org; Tue, 16 Jan 2007 13:42:28 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e36.co.us.ibm.com (8.13.8/8.12.11) with ESMTP id l0GIgPLu005749 for ; Tue, 16 Jan 2007 13:42:25 -0500 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by westrelay02.boulder.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0GIgPMl160058 for ; Tue, 16 Jan 2007 11:42:25 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0GIgPYB021170 for ; Tue, 16 Jan 2007 11:42:25 -0700 Received: from d03nm129.boulder.ibm.com (d03nm129.boulder.ibm.com [9.17.195.155]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0GIgPmF021162; Tue, 16 Jan 2007 11:42:25 -0700 In-Reply-To: <45AC75F5.7070201@deployingradius.com> Subject: Re: [Nea] REQ: Section 4 To: Alan DeKok X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Frank Yeh Jr Date: Tue, 16 Jan 2007 10:42:20 -0800 X-MIMETrack: Serialize by Router on D03NM129/03/M/IBM(Release 7.0.2HF32 | October 17, 2006) at 01/16/2007 11:42:24 MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 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="===============0368459238==" Errors-To: nea-bounces@ietf.org --===============0368459238== Content-type: multipart/alternative; Boundary="0__=07BBF8F6DFF5FE2C8f9e8a93df938690918c07BBF8F6DFF5FE2C" Content-Disposition: inline --0__=07BBF8F6DFF5FE2C8f9e8a93df938690918c07BBF8F6DFF5FE2C Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Greetings, Alan DeKok wrote on 01/15/2007 10:51:33 PM:= > Frank Yeh Jr wrote: > >... Post-admission cases are typically users > > who have met the conditions for admission but then decide to disabl= e or > > remove something so that they are no longer compliant but already h= ave > > access. The two are significant from a governance standpoint. The f= irst > > is a normal consequence of doing business, the second is a violatio= n of > > corporate policies. The responses to these different cases should b= e > > different. > > How is the post-admission case different from a user who disables > something *prior* to obtaining network access? How would the system > handle that case? Basically because if the user has disabled it prior to access the= y are caught before they ever have network access. When they do it post-admission they have, by definition, been admitted and have had acc= ess to the protected network for some period of time (as allowed by the post-admission polling configurations). This can be significant from an= auditing and compliance perspective > > Alan DeKok. > -- > http://deployingradius.com - The web site of the book > http://deployingradius.com/blog/ - The blog Regards, Frank Yeh IBM Global technology Services Security & Privacy Technology Integration Team= --0__=07BBF8F6DFF5FE2C8f9e8a93df938690918c07BBF8F6DFF5FE2C Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Greetings,

Alan DeKok <aland@deployingradius.com> wrote on 01/15/2007 10= :51:33 PM:

> Frank Yeh Jr wrote:
> >... Post-admission cases are typically users
> > who have met the conditions for admission but then decide to = disable or
> > remove something so that they are no longer compliant but alr= eady have
> > access. The two are significant from a governance standpoint.= The first
> > is a normal consequence of doing business, the second is a vi= olation of
> > corporate policies. The responses to these different cases sh= ould be
> > different.
>
>   How is the post-admission case different from a user who di= sables
> something *prior* to obtaining network access?  How would the= system
> handle that case?

Basically because if the user has disabled it prior to access they= are caught before they ever have network access. When they do it post-= admission they have, by definition, been admitted and have had access t= o the protected network for some period of time (as allowed by the post= -admission polling configurations). This can be significant from an aud= iting and compliance perspective

>
>   Alan DeKok.
> --
>   http://deployingradi= us.com       - The web site of the book
>   http://deployi= ngradius.com/blog/ - The blog

Regards,
Frank Yeh
IBM Global technology Services
Security & Privacy Technology Integration Team= --0__=07BBF8F6DFF5FE2C8f9e8a93df938690918c07BBF8F6DFF5FE2C-- --===============0368459238== 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 --===============0368459238==-- From nea-bounces@ietf.org Tue Jan 16 14:30:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6u13-0002LS-5d; Tue, 16 Jan 2007 14:30:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6u12-0002IP-Gt for nea@ietf.org; Tue, 16 Jan 2007 14:30:40 -0500 Received: from www.deployingradius.com ([216.240.42.17] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6u11-0000Qv-3k for nea@ietf.org; Tue, 16 Jan 2007 14:30:40 -0500 Received: from [10.0.0.21] (AGrenoble-257-1-124-145.w90-27.abo.wanadoo.fr [90.27.27.145]) by book.deployingradius.com (Postfix) with ESMTP id A0CFBA7067; Tue, 16 Jan 2007 11:30:33 -0800 (PST) Message-ID: <45AD27D6.1070501@deployingradius.com> Date: Tue, 16 Jan 2007 20:30:30 +0100 From: Alan DeKok User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Frank Yeh Jr Subject: Re: [Nea] REQ: Section 4 References: In-Reply-To: X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Frank Yeh Jr wrote: >> How is the post-admission case different from a user who disables >> something *prior* to obtaining network access? How would the system >> handle that case? > > Basically because if the user has disabled it prior to access they are > caught before they ever have network access. When they do it > post-admission they have, by definition, been admitted and have had > access to the protected network for some period of time (as allowed by > the post-admission polling configurations). This can be significant from > an auditing and compliance perspective Why? If they have been in compliance, who cares how long they've had network access? If they choose to no longer comply, why not just disconnect them until they comply? I don't understand how the problem is more complicated than that. The discussions here indicate there are scenarios that are significant, but there's little in the way of *quantitative* reasons as to why. Detailed examples would help me understand the explanations. Hand waving statements that it would be useful don't help move the discussion forward. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Tue Jan 16 15:53:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6vJB-00005V-C8; Tue, 16 Jan 2007 15:53:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6vJA-00005B-M7 for nea@ietf.org; Tue, 16 Jan 2007 15:53:28 -0500 Received: from e36.co.us.ibm.com ([32.97.110.154]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H6vIn-0004hC-3t for nea@ietf.org; Tue, 16 Jan 2007 15:53:28 -0500 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e36.co.us.ibm.com (8.13.8/8.12.11) with ESMTP id l0GKr3CY018152 for ; Tue, 16 Jan 2007 15:53:03 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0GKr3qJ539046 for ; Tue, 16 Jan 2007 13:53:03 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0GKr2Fn023940 for ; Tue, 16 Jan 2007 13:53:03 -0700 Received: from d03nm129.boulder.ibm.com (d03nm129.boulder.ibm.com [9.17.195.155]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0GKr2Nf023922; Tue, 16 Jan 2007 13:53:02 -0700 In-Reply-To: <45AD27D6.1070501@deployingradius.com> Subject: Re: [Nea] REQ: Section 4 To: Alan DeKok X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Frank Yeh Jr Date: Tue, 16 Jan 2007 12:52:58 -0800 X-MIMETrack: Serialize by Router on D03NM129/03/M/IBM(Release 7.0.2HF32 | October 17, 2006) at 01/16/2007 13:53:02 MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 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="===============0505274194==" Errors-To: nea-bounces@ietf.org --===============0505274194== Content-type: multipart/alternative; Boundary="0__=07BBF8F6DFE1B9FD8f9e8a93df938690918c07BBF8F6DFE1B9FD" Content-Disposition: inline --0__=07BBF8F6DFE1B9FD8f9e8a93df938690918c07BBF8F6DFE1B9FD Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Greetings, Alan DeKok wrote on 01/16/2007 11:30:30 AM:= > Frank Yeh Jr wrote: > >> How is the post-admission case different from a user who disable= s > >> something *prior* to obtaining network access? How would the syst= em > >> handle that case? > > > > Basically because if the user has disabled it prior to access they = are > > caught before they ever have network access. When they do it > > post-admission they have, by definition, been admitted and have had= > > access to the protected network for some period of time (as allowed= by > > the post-admission polling configurations). This can be significant= from > > an auditing and compliance perspective > > Why? > > If they have been in compliance, who cares how long they've had > network access? > > If they choose to no longer comply, why not just disconnect them un= til > they comply? > > I don't understand how the problem is more complicated than that. = The > discussions here indicate there are scenarios that are significant, b= ut > there's little in the way of *quantitative* reasons as to why. Detai= led > examples would help me understand the explanations. Hand waving > statements that it would be useful don't help move the discussion forward. > Ok, this may start the whole Big Brother discussion again, but to= me the fact that someone is in compliance and admitted to the network and = then goes non-compliant indicates a willful act by the user. As you say, the= y CHOOSE to no longer comply. This is a big thing when you start looking = at compliance and business conduct guidelines, Terms of Service, etc. When= they CHOOSE not to comply, they are in many cases breaking some Coporat= e Policy and or ToS that they have agreed to. So legally there are huge implications_ if someone is willfully violating a ToS, they are liable.= > Alan DeKok. > -- > http://deployingradius.com - The web site of the book > http://deployingradius.com/blog/ - The blog Regards, Frank Yeh IBM Global Technology Services Security & Privacy Technology Integration Team= --0__=07BBF8F6DFE1B9FD8f9e8a93df938690918c07BBF8F6DFE1B9FD Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Greetings,

Alan DeKok <aland@deployingradius.com> wrote on 01/16/2007 11= :30:30 AM:

> Frank Yeh Jr wrote:
> >>   How is the post-admission case different from a us= er who disables
> >> something *prior* to obtaining network access?  How = would the system
> >> handle that case?
> >
> > Basically because if the user has disabled it prior to access= they are
> > caught before they ever have network access. When they do it<= br> > > post-admission they have, by definition, been admitted and ha= ve had
> > access to the protected network for some period of time (as a= llowed by
> > the post-admission polling configurations). This can be signi= ficant from
> > an auditing and compliance perspective
>
>   Why?
>
>   If they have been in compliance, who cares how long they've= had
> network access?
>
>   If they choose to no longer comply, why not just disconnect= them until
> they comply?
>
>   I don't understand how the problem is more complicated than= that.  The
> discussions here indicate there are scenarios that are significant= , but
> there's little in the way of *quantitative* reasons as to why. &nb= sp;Detailed
> examples would help me understand the explanations.  Hand wav= ing
> statements that it would be useful don't help move the discussion = forward.
>

Ok, this may start the whole Big Brother discussion again, but to = me the fact that someone is in compliance and admitted to the network a= nd then goes non-compliant indicates a willful act by the user. As you = say, they CHOOSE to no longer comply. This is a big thing when you star= t looking at compliance and business conduct guidelines, Terms of Servi= ce, etc. When they CHOOSE not to comply, they are in many cases breakin= g some Coporate Policy and or ToS that they have agreed to. So legally = there are huge implications_ if someone is willfully violating a ToS, t= hey are liable.
 
>   Alan DeKok.
> --
>   http://deployingradi= us.com       - The web site of the book
>   http://deployi= ngradius.com/blog/ - The blog


Regards,
Frank Yeh
IBM Global Technology Services
Security & Privacy Technology Integration Team= --0__=07BBF8F6DFE1B9FD8f9e8a93df938690918c07BBF8F6DFE1B9FD-- --===============0505274194== 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 --===============0505274194==-- From nea-bounces@ietf.org Tue Jan 16 15:58:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6vOE-0006Wd-9i; Tue, 16 Jan 2007 15:58:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H6vOD-0006WJ-Nc for nea@ietf.org; Tue, 16 Jan 2007 15:58:41 -0500 Received: from e33.co.us.ibm.com ([32.97.110.151]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H6vNl-0002K9-TH for nea@ietf.org; Tue, 16 Jan 2007 15:58:41 -0500 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.13.8/8.12.11) with ESMTP id l0GKwD4B012587 for ; Tue, 16 Jan 2007 15:58:13 -0500 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0GKwCm9541490 for ; Tue, 16 Jan 2007 13:58:12 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0GKwC9w027387 for ; Tue, 16 Jan 2007 13:58:12 -0700 Received: from d03nm129.boulder.ibm.com (d03nm129.boulder.ibm.com [9.17.195.155]) by d03av03.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0GKwBNR027377; Tue, 16 Jan 2007 13:58:12 -0700 In-Reply-To: <618694EF0B657246A4D55A97E38274C302CE786A@xmb-sjc-22d.amer.cisco.com> Subject: RE: [Nea] REQ: Section 4 To: "Kaushik Narayan \(kaushik\)" X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Frank Yeh Jr Date: Tue, 16 Jan 2007 12:58:08 -0800 X-MIMETrack: Serialize by Router on D03NM129/03/M/IBM(Release 7.0.2HF32 | October 17, 2006) at 01/16/2007 13:58:11 MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 6a45e05c1e4343200aa6b327df2c43fc 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="===============0864535738==" Errors-To: nea-bounces@ietf.org --===============0864535738== Content-type: multipart/alternative; Boundary="0__=07BBF8F6DFE13B528f9e8a93df938690918c07BBF8F6DFE13B52" Content-Disposition: inline --0__=07BBF8F6DFE13B528f9e8a93df938690918c07BBF8F6DFE13B52 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Greetings, My reply is at the end this time. "Kaushik Narayan \(kaushik\)" wrote on 01/15/2007 08:27:42 PM: > Hi Frank, > > Please find my respone below (it's right at the end). > > > > > > > > > > > > > > > I am not sure we need to narrow down the definition of reassessme= nt > > > to just cover the cases when the endpoint is compliant; Reassessm= ent > > > might occur for a non-compliant endpoint post remediation. > > > > > > > > > > > > > Fair enough. So reassessment can simply have the normal english > > definition of being assessed again. We can further differentiate > > pre-admission and post-admission reassessment with pre-admission > > implying hosts that have previusly been denied network access going= > > through the admission process again and post-admission implying > > hosts already admitted on the network being checked for state > > changes after admission. I'm not sure there is a lot of value in > > differentiating pre-admission reassessment and pre-admission initia= l > > assessment unless we wanted to implement some sort of failure > > threshold like timing out a session after too many failed attempts.= > > > > > > > > > > I am not sure we need to differentiate between pre-admission and > > post-admission. Essentially reassessment is triggered when either > > the NEA client or NEA server detects a change in the posture on the= > > endpoint. The endpoint can either be compliant or non-compliant > > prior to the reassessment. > > I think post VS pre admission is relevant. Pre-admission cases can > be inferred to be users who do not have the proper conditions when > they first attach. This will be typical when new patches come out., > black Tuesdays being a prime example. Post-admission cases are > typically users who have met the conditions for admission but then > decide to disable or remove something so that they are no longer > compliant but already have access. The two are significant from a > governance standpoint. The first is a normal consequence of doing > business, the second is a violation of corporate policies. The > responses to these different cases should be different. > > I just want to clarify that we are still talking about re- > assessment. I was suggesting that there may not be much value in > trying to differentiate between pre vs post admission scenarios for > re-assessment since unlike initial assessment where the network may > have to play a role (trigger) in the assessment (especially for > scenarios of assessment prior to network access), the process of > reassessment is completely driven by the NEA client or server > components. The NEA protocol considerations for re-assessment > probably need not influenced by whether endpoint was assessed to be > compliant as a result of the prior assessment and provided regular > access to the network or whether the endpoint was assessed to be > non-compliant and denied access or provided access only to the > quarantine network. > regards, > kaushik Hmmm... I suppose you could always consider any assessment an ini= tial assessment as well. So why are we differentiating re-assessment from primary assessment? Let's say I have a client that has failed initial assessment and has gone to a remediation network. When they want to reattempt access, they can simply start the whole assessment from the t= op. I don't typically comsier trhe network to initiate the conversation, it= is the client that initiates things by attempting to access a network. Regards, Frank Yeh IBM Global Technology Services Security & Privacy Technology Integration Team = --0__=07BBF8F6DFE13B528f9e8a93df938690918c07BBF8F6DFE13B52 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Greetings,

My reply is at the end this time.


"Kaushik Narayan \(kaushik\)" <kaushik@cisco.com> w= rote on 01/15/2007 08:27:42 PM:

> Hi Frank,
>  
> Please find  my respone below (it's right at the end).
>  
> <snipped>
>
> > >  
> > > <Kaushik-Response>
> > >  
> > > I am not sure we need to narrow down the definition of r= eassessment
> > > to just cover the cases when the endpoint is compliant; = Reassessment
> > > might occur for a non-compliant endpoint post remediatio= n.
> > >  
> > > </Kaushik-Response>
> > >  
> >
> > Fair enough. So reassessment can simply have the normal engli= sh
> > definition of being assessed again. We can further differenti= ate
> > pre-admission and post-admission reassessment with pre-admiss= ion
> > implying hosts that have previusly been denied network access= going
> > through the admission process again and post-admission implyi= ng
> > hosts already admitted on the network being checked for state=
> > changes after admission. I'm not sure there is a lot of value= in
> > differentiating pre-admission reassessment and pre-admission = initial
> > assessment unless we wanted to implement some sort of failure=
> > threshold like timing out a session after too many failed att= empts.
> >  
> >  
> > <Kaushik-Response-II>
> >  
> > I am not sure we need to differentiate between pre-admission = and
> > post-admission. Essentially reassessment is triggered when ei= ther
> > the NEA client or NEA server detects a change in the posture = on the
> > endpoint. The endpoint can either be compliant or non-complia= nt
> > prior to the reassessment.
>
> I think post VS pre admission is relevant. Pre-admission cases can=
> be inferred to be users who do not have the proper conditions when=
> they first attach. This will be typical when new patches come out.= ,
> black Tuesdays being a prime example. Post-admission cases are > typically users who have met the conditions for admission but then=
> decide to disable or remove something so that they are no longer <= br> > compliant but already have access. The two are significant from a =
> governance standpoint. The first is a normal consequence of doing =
> business, the second is a violation of corporate policies. The > responses to these different cases should be different.
> <Kaushik>
> I just want to clarify that we are still talking about re-
= > assessment. I was suggesting that there may not be much value in <= br> > trying to differentiate between pre vs post admission scenarios fo= r
> re-assessment since unlike initial assessment where the network ma= y
> have to play a role (trigger) in the assessment (especially for > scenarios of assessment prior to network access), the process of &= nbsp;
> reassessment is completely driven by the NEA client or server
= > components. The NEA protocol considerations for re-assessment
= > probably need not influenced by whether endpoint was assessed to b= e
> compliant as a result of the prior assessment and provided regular=
> access to the network or whether the endpoint was assessed to be <= br> > non-compliant and denied access or provided access only to the > quarantine network.
> regards,
>   kaushik

Hmmm... I suppose you could always consider any assessment an init= ial assessment as well. So why are we differentiating re-assessment fro= m primary assessment? Let's say I have a client that has failed initial= assessment and has gone to a remediation network. When they want to re= attempt access, they can simply start the whole assessment from the top= . I don't typically comsier trhe network to initiate the conversation, = it is the client that initiates things by attempting to access a networ= k.


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

= --0__=07BBF8F6DFE13B528f9e8a93df938690918c07BBF8F6DFE13B52-- --===============0864535738== 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 --===============0864535738==-- From nea-bounces@ietf.org Wed Jan 17 02:16:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H752L-0003KI-Qm; Wed, 17 Jan 2007 02:16:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H752K-0003KC-RE for nea@ietf.org; Wed, 17 Jan 2007 02:16:44 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H752J-0005Cr-Cr for nea@ietf.org; Wed, 17 Jan 2007 02:16:44 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 16 Jan 2007 23:16:42 -0800 X-IronPort-AV: i="4.13,199,1167638400"; d="scan'208,217"; a="457792656:sNHT81467086" 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 l0H7GgOW023047; Tue, 16 Jan 2007 23:16:42 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l0H7GYGm027152; Tue, 16 Jan 2007 23:16:42 -0800 (PST) Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 Jan 2007 23:16:33 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Nea] REQ: Section 4 Date: Tue, 16 Jan 2007 23:16:31 -0800 Message-ID: <618694EF0B657246A4D55A97E38274C302D5A052@xmb-sjc-22d.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] REQ: Section 4 Thread-Index: Acc5sRIsFL3+ga5SQW6aLMd71NDI7QAVhzmA From: "Kaushik Narayan \(kaushik\)" To: "Frank Yeh Jr" X-OriginalArrivalTime: 17 Jan 2007 07:16:33.0609 (UTC) FILETIME=[6AE78B90:01C73A07] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4445; t=1169018202; x=1169882202; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kaushik@cisco.com; z=From:=20=22Kaushik=20Narayan=20\(kaushik\)=22=20 |Subject:=20RE=3A=20[Nea]=20REQ=3A=20Section=204 |Sender:=20; bh=RGf3St0TqJCJf3iDIGr5dih0z31QuM8kVmwiDBUYqPU=; b=l0V7Dv06BAfRf1vfXNdv8LKETe1RP11zuYaJ2bThShr3PXIUKYNkQKx5ytcTISxZ2q1raf5Z AdIttFqLBBd8zNVwsUz7AT2X7JUVK/efqbuTJplyzGdnG9Uz5dWdbXs4; Authentication-Results: sj-dkim-4; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 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="===============2112462335==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============2112462335== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73A07.6A645893" This is a multi-part message in MIME format. ------_=_NextPart_001_01C73A07.6A645893 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Frank, =20 Please find my reply inline. =20 Hmmm... I suppose you could always consider any assessment an initial assessment as well. So why are we differentiating re-assessment from primary assessment? Let's say I have a client that has failed initial assessment and has gone to a remediation network. When they want to reattempt access, they can simply start the whole assessment from the top. I don't typically comsier trhe network to initiate the conversation, it is the client that initiates things by attempting to access a network. Re-assessment can be considered unique from a use case perspective since the re-assessment might only check for relevant attributes and may also utilize attributes values from the prior assessment, for e.g. re-assessment after remediation may not require a whole assessment but only specific attributes may be checked based on the remediation instructions that were issued by the NEA server.=20 =20 regards, kaushik ------_=_NextPart_001_01C73A07.6A645893 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi Frank,
 
Please find my reply = inline.
 
<snipped>


Hmmm... I suppose you = could always=20 consider any assessment an initial assessment as well. So why are we=20 differentiating re-assessment from primary assessment? Let's say I have = a client=20 that has failed initial assessment and has gone to a remediation = network. When=20 they want to reattempt access, they can simply start the whole = assessment from=20 the top. I don't typically comsier trhe network to initiate the = conversation, it=20 is the client that initiates things by attempting to access a=20 network.

 <Kaushik>

Re-assessment can be=20 considered unique from a use case perspective since the = re-assessment=20 might only check for relevant attributes and may also utilize attributes = values=20 from the prior assessment,  for e.g.=20 re-assessment after remediation may not require a whole assessment but only = specific=20 attributes may be checked based on the remediation instructions = that were=20 issued by the NEA server. 

</Kaushik>

 

regards,

 =20 kaushik

------_=_NextPart_001_01C73A07.6A645893-- --===============2112462335== 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 --===============2112462335==-- From nea-bounces@ietf.org Wed Jan 17 07:45:59 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7AAt-0000T1-1E; Wed, 17 Jan 2007 07:45:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7AAr-0000Sq-Aw for nea@ietf.org; Wed, 17 Jan 2007 07:45:53 -0500 Received: from www.deployingradius.com ([216.240.42.17] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7AAp-00020P-NO for nea@ietf.org; Wed, 17 Jan 2007 07:45:53 -0500 Received: from [10.0.1.59] (alexander.quiconnect.net [213.30.156.62]) by book.deployingradius.com (Postfix) with ESMTP id C215AA7067; Wed, 17 Jan 2007 04:45:44 -0800 (PST) Message-ID: <45AE1A72.6000204@deployingradius.com> Date: Wed, 17 Jan 2007 13:45:38 +0100 From: Alan DeKok User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Frank Yeh Jr Subject: Re: [Nea] REQ: Section 4 References: In-Reply-To: X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Frank Yeh Jr wrote: > Alan DeKok wrote on 01/16/2007 11:30:30 AM: >> If they have been in compliance, who cares how long they've had >> network access? >> >> If they choose to no longer comply, why not just disconnect them until >> they comply? > > Ok, this may start the whole Big Brother discussion again, but to me the > fact that someone is in compliance and admitted to the network and then > goes non-compliant indicates a willful act by the user. Or, a virus that is newer than the virus scanning rules. There are any number of reasons why a machine may suddenly be non-compliant. > As you say, they > CHOOSE to no longer comply. This is a big thing when you start looking > at compliance and business conduct guidelines, Terms of Service, etc. > When they CHOOSE not to comply, they are in many cases breaking some > Coporate Policy and or ToS that they have agreed to. So legally there > are huge implications_ if someone is willfully violating a ToS, they are > liable. I would prefer to not discuss legal issues, as they are different in every jurisdiction. From the point of view of the network, an endpoint machine can suddenly become non-compliant with network policy due to: a) changes on the endpoint b) updated policy on the NEA server In both cases, the endpoint should have its network connection removed or downgraded until it becomes compliant. with the current policy. This is a problem we can solve in NEA. We cannot address local policies of what additional steps should be taken with non-compliant endpoints, and I believe we shouldn't even try. Those steps are up to local site policy, and are extremely difficult to standardize. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Jan 17 14:18:26 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7GIh-00074u-Vj; Wed, 17 Jan 2007 14:18:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H7GIh-00074J-CB for nea@ietf.org; Wed, 17 Jan 2007 14:18:23 -0500 Received: from e35.co.us.ibm.com ([32.97.110.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H7GId-0005qP-PJ for nea@ietf.org; Wed, 17 Jan 2007 14:18:23 -0500 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e35.co.us.ibm.com (8.13.8/8.12.11) with ESMTP id l0HJICjP000697 for ; Wed, 17 Jan 2007 14:18:12 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by westrelay02.boulder.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0HJICrb474512 for ; Wed, 17 Jan 2007 12:18:12 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0HJIBlN026767 for ; Wed, 17 Jan 2007 12:18:12 -0700 Received: from d03nm129.boulder.ibm.com (d03nm129.boulder.ibm.com [9.17.195.155]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0HJIBUx026754; Wed, 17 Jan 2007 12:18:11 -0700 In-Reply-To: <45AE1A72.6000204@deployingradius.com> Subject: Re: [Nea] REQ: Section 4 To: Alan DeKok X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 Message-ID: From: Frank Yeh Jr Date: Wed, 17 Jan 2007 11:18:03 -0800 X-MIMETrack: Serialize by Router on D03NM129/03/M/IBM(Release 7.0.2HF32 | October 17, 2006) at 01/17/2007 12:18:11 MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 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="===============1620292032==" Errors-To: nea-bounces@ietf.org --===============1620292032== Content-type: multipart/alternative; Boundary="0__=07BBF8F5DFFB7B228f9e8a93df938690918c07BBF8F5DFFB7B22" Content-Disposition: inline --0__=07BBF8F5DFFB7B228f9e8a93df938690918c07BBF8F5DFFB7B22 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Greetings, Alan DeKok wrote on 01/17/2007 04:45:38 AM:= > Frank Yeh Jr wrote: > > Alan DeKok wrote on 01/16/2007 11:30:30= AM: > >> If they have been in compliance, who cares how long they've had > >> network access? > >> > >> If they choose to no longer comply, why not just disconnect them= until > >> they comply? > > > > Ok, this may start the whole Big Brother discussion again, but to m= e the > > fact that someone is in compliance and admitted to the network and = then > > goes non-compliant indicates a willful act by the user. > > Or, a virus that is newer than the virus scanning rules. There are= > any number of reasons why a machine may suddenly be non-compliant. > Yes, but they can all be summarized by "the endpoint state does n= ot match the required state" and the required state is defined by policy. = So a virus that is newer than virus scanning rules might make the endpoint unsafe, but unless the policy has changed, it is still compliant. > > As you say, they > > CHOOSE to no longer comply. This is a big thing when you start look= ing > > at compliance and business conduct guidelines, Terms of Service, et= c. > > When they CHOOSE not to comply, they are in many cases breaking som= e > > Coporate Policy and or ToS that they have agreed to. So legally the= re > > are huge implications_ if someone is willfully violating a ToS, the= y are > > liable. > > I would prefer to not discuss legal issues, as they are different i= n > every jurisdiction. > Very wise of you. I agree. > From the point of view of the network, an endpoint machine can > suddenly become non-compliant with network policy due to: > > a) changes on the endpoint > b) updated policy on the NEA server > > In both cases, the endpoint should have its network connection remo= ved > or downgraded until it becomes compliant. with the current policy. T= his > is a problem we can solve in NEA. > Completely agree. > We cannot address local policies of what additional steps should be= > taken with non-compliant endpoints, and I believe we shouldn't even t= ry. > Those steps are up to local site policy, and are extremely difficult = to > standardize. > I agree again (the stars mut be aligned_ I am strangely agreeable= today ;-). I analogize this by saying we are creating a language or an alphabet_ we cannot control what people will write or say with it. What= we can do is make it usable and rich enough to support anything they want = to say. > Alan DeKok. > -- > http://deployingradius.com - The web site of the book > http://deployingradius.com/blog/ - The blog I get the feeling we are reaching some consensus on this point. H= ope you are too! Regards, Frank Yeh IBM Global Technology Services Security & Privacy Technology Integration Team= --0__=07BBF8F5DFFB7B228f9e8a93df938690918c07BBF8F5DFFB7B22 Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Greetings,

Alan DeKok <aland@deployingradius.com> wrote on 01/17/2007 04= :45:38 AM:

> Frank Yeh Jr wrote:
> > Alan DeKok <aland@deployingradius.com> wrote on 01/16/2= 007 11:30:30 AM:
> >>   If they have been in compliance, who cares how lon= g they've had
> >> network access?
> >>
> >>   If they choose to no longer comply, why not just d= isconnect them until
> >> they comply?
> >
> > Ok, this may start the whole Big Brother discussion again, bu= t to me the
> > fact that someone is in compliance and admitted to the networ= k and then
> > goes non-compliant indicates a willful act by the user.
>
>   Or, a virus that is newer than the virus scanning rules. &n= bsp;There are
> any number of reasons why a machine may suddenly be non-compliant.=
>

Yes, but they can all be summarized by "the endpoint state do= es not match the required state" and the required state is defined= by policy. So a virus that is newer than virus scanning rules might ma= ke the endpoint unsafe, but unless the policy has changed, it is still = compliant.

> > As you say, they
> > CHOOSE to no longer comply. This is a big thing when you star= t looking
> > at compliance and business conduct guidelines, Terms of Servi= ce, etc.
> > When they CHOOSE not to comply, they are in many cases breaki= ng some
> > Coporate Policy and or ToS that they have agreed to. So legal= ly there
> > are huge implications_ if someone is willfully violating a To= S, they are
> > liable.
>
>   I would prefer to not discuss legal issues, as they are dif= ferent in
> every jurisdiction.
>

Very wise of you. I agree.

>   From the point of view of the network, an endpoint machine = can
> suddenly become non-compliant with network policy due to:
>
>   a) changes on the endpoint
>   b) updated policy on the NEA server
>
>   In both cases, the endpoint should have its network connect= ion removed
> or downgraded until it becomes compliant. with the current policy.=  This
> is a problem we can solve in NEA.
>

Completely agree.

>   We cannot address local policies of what additional steps s= hould be
> taken with non-compliant endpoints, and I believe we shouldn't eve= n try.
> Those steps are up to local site policy, and are extremely difficu= lt to
> standardize.
>

I agree again (the stars mut be aligned_ I am strangely agreeable = today ;-). I analogize this by saying we are creating a language or an = alphabet_ we cannot control what people will write or say with it. What= we can do is make it usable and rich enough to support anything they w= ant to say.

>   Alan DeKok.
> --
>   http://deployingradi= us.com       - The web site of the book
>   http://deployi= ngradius.com/blog/ - The blog


I get the feeling we are reaching some consensus on this point. Ho= pe you are too!

Regards,
Frank Yeh
IBM Global Technology Services
Security & Privacy Technology Integration Team
= --0__=07BBF8F5DFFB7B228f9e8a93df938690918c07BBF8F5DFFB7B22-- --===============1620292032== 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 --===============1620292032==-- From nea-bounces@ietf.org Sun Jan 21 13:28:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8hQV-0006A6-On; Sun, 21 Jan 2007 13:28:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8hQU-00068c-OO for nea@ietf.org; Sun, 21 Jan 2007 13:28:22 -0500 Received: from www.deployingradius.com ([216.240.42.17] helo=book.deployingradius.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8hQS-0005El-Bn for nea@ietf.org; Sun, 21 Jan 2007 13:28:22 -0500 Received: from [10.0.0.21] (AGrenoble-257-1-98-170.w90-9.abo.wanadoo.fr [90.9.33.170]) by book.deployingradius.com (Postfix) with ESMTP id 01F11A70B4; Sun, 21 Jan 2007 10:28:07 -0800 (PST) Message-ID: <45B3B0AE.203@deployingradius.com> Date: Sun, 21 Jan 2007 19:27:58 +0100 From: Alan DeKok User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Frank Yeh Jr Subject: Re: [Nea] REQ: Section 4 References: In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Frank Yeh Jr wrote: > Yes, but they can all be summarized by "the endpoint state does not > match the required state" and the required state is defined by policy. > So a virus that is newer than virus scanning rules might make the > endpoint unsafe, but unless the policy has changed, it is still compliant. Yes. > I agree again (the stars mut be aligned_ I am strangely agreeable today > ;-). I analogize this by saying we are creating a language or an > alphabet_ we cannot control what people will write or say with it. What > we can do is make it usable and rich enough to support anything they > want to say. That worries me a little. > I get the feeling we are reaching some consensus on this point. Hope you > are too! Yes. I will try to find time to write up a more detailed summary. Alan DeKok. -- http://deployingradius.com - The web site of the book http://deployingradius.com/blog/ - The blog _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Sun Jan 21 16:56:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8kg5-0001XX-Qm; Sun, 21 Jan 2007 16:56:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H8kg4-0001XS-Fe for nea@ietf.org; Sun, 21 Jan 2007 16:56:40 -0500 Received: from elasmtp-scoter.atl.sa.earthlink.net ([209.86.89.67]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H8kfz-0005es-5K for nea@ietf.org; Sun, 21 Jan 2007 16:56:40 -0500 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=GYQe76DcFwlnRMuc6XsDnuqULTcYNh3qGUz+l6m07UGV+p5kedn/WGUkfzoGtYcd; 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 [66.245.143.140] (helo=gw) by elasmtp-scoter.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1H8kfw-0007FF-8X; Sun, 21 Jan 2007 16:56:32 -0500 Message-ID: <002f01c73da7$05240d30$2101a8c0@home.glassey.com> From: "todd glassey" To: "Alan DeKok" , "Frank Yeh Jr" References: <45B3B0AE.203@deployingradius.com> Subject: Re: [Nea] REQ: Section 4 Date: Sun, 21 Jan 2007 13:56:32 -0800 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.3028 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec7916c5d60ba477e810496d963d93ca60ba350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 66.245.143.140 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org ----- Original Message ----- From: "Alan DeKok" To: "Frank Yeh Jr" Cc: Sent: Sunday, January 21, 2007 10:27 AM Subject: Re: [Nea] REQ: Section 4 > Frank Yeh Jr wrote: > >> Yes, but they can all be summarized by "the endpoint state does not >> match the required state" and the required state is defined by policy. >> So a virus that is newer than virus scanning rules might make the >> endpoint unsafe, but unless the policy has changed, it is still >> compliant. > > Yes. > >> I agree again (the stars mut be aligned_ I am strangely agreeable today >> ;-). I analogize this by saying we are creating a language or an >> alphabet_ we cannot control what people will write or say with it. What >> we can do is make it usable and rich enough to support anything they >> want to say. > > That worries me a little. Why NEA is a tool to assure compliance with specific policies. If those policies are not updated to address specific Zero-Day issues then those issues will not be addressed by the NEA compliance model. But this is true for all systems of this type so being worried is about the operators not being able to react fast enough. T. > >> I get the feeling we are reaching some consensus on this point. Hope you >> are too! > > Yes. I will try to find time to write up a more detailed summary. > > Alan DeKok. > -- > http://deployingradius.com - The web site of the book > http://deployingradius.com/blog/ - The blog > > _______________________________________________ > Nea mailing list > Nea@ietf.org > https://www1.ietf.org/mailman/listinfo/nea _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Wed Jan 24 02:32:08 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9cbq-0000mP-Ik; Wed, 24 Jan 2007 02:31:54 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9cbo-0000mE-KT for nea@ietf.org; Wed, 24 Jan 2007 02:31:52 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H9cbm-0007MM-SL for nea@ietf.org; Wed, 24 Jan 2007 02:31:52 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCD00JSH3DZW5@szxga01-in.huawei.com> for nea@ietf.org; Wed, 24 Jan 2007 15:27:36 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCD00L0X3DZAN@szxga01-in.huawei.com> for nea@ietf.org; Wed, 24 Jan 2007 15:27:35 +0800 (CST) Received: from y34728 ([10.110.31.96]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JCD003AI3DYZ1@szxml03-in.huawei.com> for nea@ietf.org; Wed, 24 Jan 2007 15:27:35 +0800 (CST) Date: Wed, 24 Jan 2007 15:27:33 +0800 From: Han Yin To: nea@ietf.org Message-id: <003401c73f89$1e121740$601f6e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Mailer: Microsoft Outlook Express 5.50.4927.1200 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [Nea] Thank to the design team X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0337156894==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============0337156894== Content-type: multipart/alternative; boundary="Boundary_(ID_k+qrcqPNlUfjDqoILLj+Yw)" This is a multi-part message in MIME format. --Boundary_(ID_k+qrcqPNlUfjDqoILLj+Yw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT I think the new requirement is an excellent project. Assessment triggered by client, Assertion Attribue and Request Attribue are supplemented into docutment. So, the NEA reference model can cover more cases and be applicable to more environments. The discussion about privacy on mail list is considered in Privacy section. Howerver, privacy is not an very serious question, I think. It is not so important whether NEA server can iteratively ask for Attributes as long as the disclosure policy is clear and confirmed by user. Addtionally, I have some question about PT protocol. I will propose them on the list after a while. Thank to the requirement design team! Best regards Han Yin ayinhan@huawei.com --Boundary_(ID_k+qrcqPNlUfjDqoILLj+Yw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT


I think the new requirement is an excellent project. Assessment triggered by client, Assertion Attribue and Request Attribue are supplemented into docutment. So, the NEA reference model can cover more cases and be applicable to more environments. The discussion about privacy on mail list is considered in Privacy section. 
Howerver, privacy is not an very serious question, I think. It is not so important whether NEA server can iteratively ask for Attributes as long as the disclosure policy is clear and confirmed by user.
 
Addtionally, I have some question about PT protocol. I will propose them on the list after a while.

Thank to the requirement design team!

Best regards
Han Yin
--Boundary_(ID_k+qrcqPNlUfjDqoILLj+Yw)-- --===============0337156894== 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 --===============0337156894==-- From nea-bounces@ietf.org Wed Jan 24 02:36:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9cfv-0003VX-Ac; Wed, 24 Jan 2007 02:36:07 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9cft-0003VO-Jv for nea@ietf.org; Wed, 24 Jan 2007 02:36:06 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H9cfH-0007Yl-DO for nea@ietf.org; Wed, 24 Jan 2007 02:36:05 -0500 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCD006UE3GCV8@szxga04-in.huawei.com> for nea@ietf.org; Wed, 24 Jan 2007 15:29:00 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCD008J13GBGU@szxga04-in.huawei.com> for nea@ietf.org; Wed, 24 Jan 2007 15:29:00 +0800 (CST) Received: from y34728 ([10.110.31.96]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JCD003EO3GBZ1@szxml03-in.huawei.com> for nea@ietf.org; Wed, 24 Jan 2007 15:28:59 +0800 (CST) Date: Wed, 24 Jan 2007 15:28:57 +0800 From: Han Yin To: nea@ietf.org Message-id: <003a01c73f89$506c6920$601f6e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Mailer: Microsoft Outlook Express 5.50.4927.1200 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Subject: [Nea] PT protocol must be capable of transporting messages for assessment during network connection request ? X-BeenThere: nea@ietf.org X-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="===============0668559468==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============0668559468== Content-type: multipart/alternative; boundary="Boundary_(ID_e+PxQxarwzbPfKNd92H6Kg)" This is a multi-part message in MIME format. --Boundary_(ID_e+PxQxarwzbPfKNd92H6Kg) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT In new requirement, it is presented in section 5.2.3 Posture Transport Protocol: "The PT protocol must be capable of transporting Messages for Assessment during network connection request and after network connectivity has been established." But I think this is only necessary for assessment triggered by network connection request. Addtional in Section 7.4 Posturen Transport (PT) Protocol Requirements, there is no such a requirement. why? On my view, if PT protocol is not expected to carry assessment messages during network connection request, TLS is a good choice. If PT protocol is expected to carry assessment messages during network connection request, EAP-TLS might be a good choice. Why should we choose among EAP-TTLS/EAP-FAST/EAP-PEAP or define a new one? Another question of PT protocol: In the 16th procedure of section 6.1.2.2, it is described that PT protocol informs the gateway of the compliance status. But, how to apply the result of assessment to network access control is out of NEA WG scope. Is it a unintended mistake? Thank to the requirement design team! Best regards Han Yin ayinhan@huawei.com --Boundary_(ID_e+PxQxarwzbPfKNd92H6Kg) Content-type: text/html; charset=gb2312 Content-transfer-encoding: 7BIT
In new requirement, it is presented in section 5.2.3 Posture Transport Protocol:
"The PT protocol must be capable of transporting Messages for Assessment during network connection request and after network connectivity has been established." But I think this is only necessary for assessment triggered by network connection request. Addtional in Section 7.4 Posturen Transport (PT) Protocol Requirements, there is no such a requirement. why?
On my view, if PT protocol is not expected to carry assessment messages during network connection request, TLS is a good choice. If PT protocol is expected to carry assessment messages during network connection request, EAP-TLS might be a good
choice. Why should we choose among EAP-TTLS/EAP-FAST/EAP-PEAP or define a new one?

Another question of PT protocol:
In the 16th procedure of section 6.1.2.2, it is described that PT protocol informs the gateway of the compliance status. But, how to apply the result of assessment to network access control is out of NEA WG scope. Is it a unintended mistake?


Thank to the requirement design team!

Best regards
Han Yin
--Boundary_(ID_e+PxQxarwzbPfKNd92H6Kg)-- --===============0668559468== 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 --===============0668559468==-- From nea-bounces@ietf.org Wed Jan 24 14:34:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9nsm-000203-E7; Wed, 24 Jan 2007 14:34:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H9nsk-0001zR-Dq for nea@ietf.org; Wed, 24 Jan 2007 14:34:06 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H9nsi-0000Ee-P1 for nea@ietf.org; Wed, 24 Jan 2007 14:34:06 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 24 Jan 2007 11:34:04 -0800 X-IronPort-AV: i="4.13,233,1167638400"; d="scan'208,217"; a="105079734:sNHT84577770" 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 l0OJY2GT007871; Wed, 24 Jan 2007 11:34:02 -0800 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 l0OJXkV8015643; Wed, 24 Jan 2007 11:34:04 -0800 (PST) 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); Wed, 24 Jan 2007 11:34:02 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Nea] PT protocol must be capable of transporting messages for assessment during network connection request ? Date: Wed, 24 Jan 2007 11:34:01 -0800 Message-ID: <618694EF0B657246A4D55A97E38274C302DC596F@xmb-sjc-22d.amer.cisco.com> In-Reply-To: <003a01c73f89$506c6920$601f6e0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Nea] PT protocol must be capable of transporting messages for assessment during network connection request ? Thread-Index: Acc/ilvrDZ6GhCpnR2SIR+Tx5XspzQAYp46g From: "Kaushik Narayan \(kaushik\)" To: "Han Yin" , X-OriginalArrivalTime: 24 Jan 2007 19:34:02.0994 (UTC) FILETIME=[9A7C1D20:01C73FEE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7657; t=1169667242; x=1170531242; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kaushik@cisco.com; z=From:=20=22Kaushik=20Narayan=20\(kaushik\)=22=20 |Subject:=20RE=3A=20[Nea]=20PT=20protocol=20must=20be=20capable=20of=20tr ansporting=20messages=20for=20assessment=20during=20network=20connection=2 0request=20? |Sender:=20; bh=7ne9mAAQrL+EcOjBVGNkX1N0xrwIiswTF/qocb5AZP0=; b=COqCfbVDeyNw6SmhREs8Ch+zMgQIH3EVgOpH4rFI5chcVIdJWeCSocn1hI67GqmSHyENp6a8 ZWnb+0UqK+ZtJ4zvUbAZjEG1WdCZE94ZI9tcJSCcKa9M0mrOjH6hpNSV; Authentication-Results: sj-dkim-2; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.1 (/) 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: , Content-Type: multipart/mixed; boundary="===============1036654807==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============1036654807== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C73FEE.9A613FF0" This is a multi-part message in MIME format. ------_=_NextPart_001_01C73FEE.9A613FF0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Han, =20 Thanks for your comments. Please find my response inline. ________________________________ From: Han Yin [mailto:ayinhan@huawei.com]=20 Sent: Tuesday, January 23, 2007 11:29 PM To: nea@ietf.org Subject: [Nea] PT protocol must be capable of transporting messages for assessment during network connection request ? In new requirement, it is presented in section 5.2.3 Posture Transport Protocol: "The PT protocol must be capable of transporting Messages for Assessment during network connection request and after network connectivity has been established." But I think this is only necessary for assessment triggered by network connection request. Addtional in Section 7.4 Posturen Transport (PT) Protocol Requirements, there is no such a requirement. why?=20 =20 This requirement is covered under "Common Requirements" in section 7.1, the requirement number is C-2. =20 =20 On my view, if PT protocol is not expected to carry assessment messages during network connection request, TLS is a good choice. If PT protocol is expected to carry assessment messages during network connection request, EAP-TLS might be a good choice. Why should we choose among EAP-TTLS/EAP-FAST/EAP-PEAP or define a new one?=20 =20 This draft is intended to capture the protocol requirements; the choice of protocols would be part of future work which might be addressed by a separate draft. =20 Another question of PT protocol: In the 16th procedure of section 6.1.2.2, it is described that PT protocol informs the gateway of the compliance status. But, how to apply the result of assessment to network access control is out of NEA WG scope. Is it a unintended mistake?=20 =20 This is intentional since the mechanisms used to apply access control is out of scope of the NEA charter. There is a line in the NEA charter that clearly states. "Specifying mechanisms for providing restricted access is outside the scope of the NEA WG. " =20 regards, kaushik=20 Thank to the requirement design team! Best regards Han Yin=20 ayinhan@huawei.com ------_=_NextPart_001_01C73FEE.9A613FF0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi Han,
 
Thanks for your comments. Please find my = response=20 inline.

From: Han Yin = [mailto:ayinhan@huawei.com]=20
Sent: Tuesday, January 23, 2007 11:29 PM
To:=20 nea@ietf.org
Subject: [Nea] PT protocol must be capable of=20 transporting messages for assessment during network connection request=20 ?

In new requirement, it is presented = in section=20 5.2.3 Posture Transport Protocol:
"The PT protocol must be capable of = transporting Messages for Assessment during network connection = request and=20 after network connectivity has been established." But I think this = is only=20 necessary for assessment triggered by network connection request.=20 Addtional in Section 7.4 = Posturen=20 Transport (PT) Protocol Requirements, there is no such a = requirement.=20 why? 
 
<Kaushik> This requirement is covered under "Common = Requirements"=20 in section 7.1, the requirement number is C-2.
 
 
On my view, if PT protocol is not = expected to=20 carry assessment messages during network connection request, TLS is a = good=20 choice. If PT protocol is expected to carry assessment messages during = network=20 connection request, EAP-TLS might be a good
choice. Why should we = choose=20 among EAP-TTLS/EAP-FAST/EAP-PEAP or define a new one? 
 
<Kaushik> = This draft is=20 intended to capture the protocol requirements; the choice of protocols = would be=20 part of future work which might be addressed by a separate=20 draft.
 

Another question of=20 PT protocol:
In the 16th procedure of section 6.1.2.2, it = is described=20 that PT protocol informs the gateway of the compliance status. But, how=20 to apply the result of assessment to network access control is out = of NEA=20 WG scope. Is it a unintended mistake? 
 
<Kaushik>  This=20 is intentional since the mechanisms used to apply access control is out = of scope=20 of the NEA charter. There is a line in the NEA charter that clearly = states.=20 "Specifying=20 mechanisms for providing restricted access is outside the scope of the = NEA=20 WG. "
 
regards,
  kaushik 


Thank to = the=20 requirement design team!

Best regards
Han Yin
ayinhan@huawei.com
------_=_NextPart_001_01C73FEE.9A613FF0-- --===============1036654807== 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 --===============1036654807==-- From nea-bounces@ietf.org Thu Jan 25 12:41:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA8aZ-0005nc-8l; Thu, 25 Jan 2007 12:40:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HA8aY-0005nU-AX for nea@ietf.org; Thu, 25 Jan 2007 12:40:42 -0500 Received: from szxga03-in.huawei.com ([61.144.161.55]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HA8aG-0006Mi-Ei for nea@ietf.org; Thu, 25 Jan 2007 12:40:42 -0500 Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCF00AIWQCCSU@szxga04-in.huawei.com> for nea@ietf.org; Fri, 26 Jan 2007 01:38:37 +0800 (CST) Received: from huawei.com ([172.24.1.6]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCF009AYQCAH9@szxga04-in.huawei.com> for nea@ietf.org; Fri, 26 Jan 2007 01:38:36 +0800 (CST) Received: from dragon ([221.219.10.240]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JCF00APAQC91C@szxml02-in.huawei.com>; Fri, 26 Jan 2007 01:38:34 +0800 (CST) Date: Fri, 26 Jan 2007 01:43:30 +0800 From: Han Yin Subject: Re: RE: [Nea] PT protocol must be capable of transporting messages forassessment during network connection request ? To: "Kaushik Narayan (kaushik)" , nea Message-id: <0JCF00APBQCA1C@szxml02-in.huawei.com> MIME-version: 1.0 X-Mailer: Foxmail 5.0 [cn] X-Spam-Score: 0.4 (/) X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235 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="===============0891152883==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============0891152883== Content-type: multipart/alternative; boundary="Boundary_(ID_qEXcoxH+svksvGCTqehlhw)" This is a multi-part message in MIME format. --Boundary_(ID_qEXcoxH+svksvGCTqehlhw) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 SGkgS2F1c2hpayBOYXJheWFuLA0KDQqhoaGhVGhhbmtzIGZvciB5b3VyIHJlc3BvbnNlLiBQbGVh c2UgZmluZCBteSByZXNwb25zZSBpbmxpbmUuDQoNCj09PT09PT09IDIwMDctMDEtMjUgMDM6MzQ6 MDEgxPrU2sC00MXW0NC0tcCjuiA9PT09PT09PQ0KDQpIaSBIYW4sDQoNClRoYW5rcyBmb3IgeW91 ciBjb21tZW50cy4gUGxlYXNlIGZpbmQgbXkgcmVzcG9uc2UgaW5saW5lLg0KDQoNCg0KDQpGcm9t OiBIYW4gWWluIFttYWlsdG86YXlpbmhhbkBodWF3ZWkuY29tXSANClNlbnQ6IFR1ZXNkYXksIEph bnVhcnkgMjMsIDIwMDcgMTE6MjkgUE0NClRvOiBuZWFAaWV0Zi5vcmcNClN1YmplY3Q6IFtOZWFd IFBUIHByb3RvY29sIG11c3QgYmUgY2FwYWJsZSBvZiB0cmFuc3BvcnRpbmcgbWVzc2FnZXMgZm9y IGFzc2Vzc21lbnQgZHVyaW5nIG5ldHdvcmsgY29ubmVjdGlvbiByZXF1ZXN0ID8NCg0KDQpJbiBu ZXcgcmVxdWlyZW1lbnQsIGl0IGlzIHByZXNlbnRlZCBpbiBzZWN0aW9uIDUuMi4zIFBvc3R1cmUg VHJhbnNwb3J0IFByb3RvY29sOg0KIlRoZSBQVCBwcm90b2NvbCBtdXN0IGJlIGNhcGFibGUgb2Yg dHJhbnNwb3J0aW5nIE1lc3NhZ2VzIGZvciBBc3Nlc3NtZW50IGR1cmluZyBuZXR3b3JrIGNvbm5l Y3Rpb24gcmVxdWVzdCBhbmQgYWZ0ZXIgbmV0d29yayBjb25uZWN0aXZpdHkgaGFzIGJlZW4gZXN0 YWJsaXNoZWQuIiBCdXQgSSB0aGluayB0aGlzIGlzIG9ubHkgbmVjZXNzYXJ5IGZvciBhc3Nlc3Nt ZW50IHRyaWdnZXJlZCBieSBuZXR3b3JrIGNvbm5lY3Rpb24gcmVxdWVzdC4gQWRkdGlvbmFsIGlu IFNlY3Rpb24gNy40IFBvc3R1cmVuIFRyYW5zcG9ydCAoUFQpIFByb3RvY29sIFJlcXVpcmVtZW50 cywgdGhlcmUgaXMgbm8gc3VjaCBhIHJlcXVpcmVtZW50LiB3aHk/IA0KDQo8S2F1c2hpaz4gVGhp cyByZXF1aXJlbWVudCBpcyBjb3ZlcmVkIHVuZGVyICJDb21tb24gUmVxdWlyZW1lbnRzIiBpbiBz ZWN0aW9uIDcuMSwgdGhlIHJlcXVpcmVtZW50IG51bWJlciBpcyBDLTIuDQoNCjxIYW4gWWluPg0K WWVzLCBzdWNoIHJlcXVpcmVtZW50IGlzIGNvdmVyZCB1bmRlciBDLTIuDQpCdXQsIEkgdGhpbmsg c3VjaCByZXF1aXJlbWVudCBpcyB1bm5lY2Vzc2FyeS4gSW4gYWJzdHJhY3QsIGl0IGlzIHN0YXRl ZDoNCiAgICAgIk5FQSBwcm92aWRlcyBvd25lcnMgb2YgDQogICAgIG5ldHdvcmtzIChlLmcuIGFu IGVudGVycHJpc2Ugb2ZmZXJpbmcgcmVtb3RlIGFjY2VzcykgYSBtZWNoYW5pc20gDQogICAgIHRv IGV2YWx1YXRlIHRoZSBwb3N0dXJlIG9mIGEgc3lzdGVtLiAgVGhpcyBtYXkgdGFrZSBwbGFjZSBk dXJpbmcgDQogICAgIHRoZSByZXF1ZXN0IGZvciBuZXR3b3JrIGFjY2VzcyBhbmQvb3Igc3Vic2Vx dWVudGx5IGF0IGFueSB0aW1lIA0KICAgICB3aGlsZSBjb25uZWN0ZWQgdG8gdGhlIG5ldHdvcmsu Ig0KICAgICBBZGRpdGlvbmFsbHksIGluIHNvbWUgZW52aXJvbm1lbnQsIHRoZSBhc3Nlc3NtZW50 IG9ubHkgb2NjdXJzIGFmdGVyIHRoZSBob3N0IGlzIGNvbm5lY3RlZCB0byB0aGUgbmV0d29yaywg DQogICAgIHdoaWNoIGlzIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDYuMS4zLjEuICBJbiBzdWNoIGNh c2VzLCB1c2VyIGlzIGNvbmNlcm5lZCBhYm91dCBlbmRwb2ludCBzZWN1cml0eSBzdGF0dXMsIG5v dCB0aGUgbmV0d29yayBhY2Nlc3MuDQo8L0hhbiBZaW4+DQoNCk9uIG15IHZpZXcsIGlmIFBUIHBy b3RvY29sIGlzIG5vdCBleHBlY3RlZCB0byBjYXJyeSBhc3Nlc3NtZW50IG1lc3NhZ2VzIGR1cmlu ZyBuZXR3b3JrIGNvbm5lY3Rpb24gcmVxdWVzdCwgVExTIGlzIGEgZ29vZCBjaG9pY2UuIElmIFBU IHByb3RvY29sIGlzIGV4cGVjdGVkIHRvIGNhcnJ5IGFzc2Vzc21lbnQgbWVzc2FnZXMgZHVyaW5n IG5ldHdvcmsgY29ubmVjdGlvbiByZXF1ZXN0LCBFQVAtVExTIG1pZ2h0IGJlIGEgZ29vZA0KY2hv aWNlLiBXaHkgc2hvdWxkIHdlIGNob29zZSBhbW9uZyBFQVAtVFRMUy9FQVAtRkFTVC9FQVAtUEVB UCBvciBkZWZpbmUgYSBuZXcgb25lPyANCg0KPEthdXNoaWs+IFRoaXMgZHJhZnQgaXMgaW50ZW5k ZWQgdG8gY2FwdHVyZSB0aGUgcHJvdG9jb2wgcmVxdWlyZW1lbnRzOyB0aGUgY2hvaWNlIG9mIHBy b3RvY29scyB3b3VsZCBiZSBwYXJ0IG9mIGZ1dHVyZSB3b3JrIHdoaWNoIG1pZ2h0IGJlIGFkZHJl c3NlZCBieSBhIHNlcGFyYXRlIGRyYWZ0Lg0KDQo8SGFuIFlpbj4NClllcywgUFQgcHJvdG9jb2wg aXMgYSBwYXJ0IG9mIGZ1dHVyZSB3b3JrLiBIb3dlcnZlciwgdGhlIHJlcXVpcmVtZW50IG9mIFBU IHByb3RvY29sIG11c3QgYmUgZGV0ZXJtaW5lZCBub3cgLiBQbGVhc2Ugc2VlIGFib3ZlLg0KPC9I YW4gWWluPg0KDQoNCkFub3RoZXIgcXVlc3Rpb24gb2YgUFQgcHJvdG9jb2w6DQpJbiB0aGUgMTZ0 aCBwcm9jZWR1cmUgb2Ygc2VjdGlvbiA2LjEuMi4yLCBpdCBpcyBkZXNjcmliZWQgdGhhdCBQVCBw cm90b2NvbCBpbmZvcm1zIHRoZSBnYXRld2F5IG9mIHRoZSBjb21wbGlhbmNlIHN0YXR1cy4gQnV0 LCBob3cgdG8gYXBwbHkgdGhlIHJlc3VsdCBvZiBhc3Nlc3NtZW50IHRvIG5ldHdvcmsgYWNjZXNz IGNvbnRyb2wgaXMgb3V0IG9mIE5FQSBXRyBzY29wZS4gSXMgaXQgYSB1bmludGVuZGVkIG1pc3Rh a2U/IA0KDQo8S2F1c2hpaz4gIFRoaXMgaXMgaW50ZW50aW9uYWwgc2luY2UgdGhlIG1lY2hhbmlz bXMgdXNlZCB0byBhcHBseSBhY2Nlc3MgY29udHJvbCBpcyBvdXQgb2Ygc2NvcGUgb2YgdGhlIE5F QSBjaGFydGVyLiBUaGVyZSBpcyBhIGxpbmUgaW4gdGhlIE5FQSBjaGFydGVyIHRoYXQgY2xlYXJs eSBzdGF0ZXMuICJTcGVjaWZ5aW5nIG1lY2hhbmlzbXMgZm9yIHByb3ZpZGluZyByZXN0cmljdGVk IGFjY2VzcyBpcyBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGUgTkVBIFdHLiAiDQoNCjxIYW4gWWlu Pg0KQnV0LGluIFJlcXVpcmUgSW50cm9kdWN0aW9uLCBpdCBpcyBzdGF0ZWQ6IA0KIldoaWxlIHRo ZSBORUEgUmVmZXJlbmNlIE1vZGVsIHJlY29nbml6ZXMgdGhlcmUgaXMgDQogICAgICBhIGxpbmsg YmV0d2VlbiBhbiBFbmRwb2ludCBBc3Nlc3NtZW50IGFuZCB0aGUgZW5mb3JjZW1lbnQgb2YgDQog ICAgICB0aGUgQXNzZXNzbWVudCBkZWNpc2lvbiwgdGhlIG1lY2hhbmlzbXMgYW5kIHByb3RvY29s cyBmb3IgDQogICAgICBlbmZvcmNlbWVudCBhcmUgbm90IGluIHNjb3BlIGZvciB0aGlzIHNwZWNp ZmljYXRpb24uIg0KU28sIFBUIHByb3RvY29sIGlzIG5vdCByZXF1aXJlZCB0byBpbmZvcm0gdGhl IGFzc2VzcyByZXN1bHQgdG8gdGhlIGdhdGV3YXkuIERlcGxveWVyIGNhbiBjb21wbGV0ZSBpdCBi eSBvdGhlciBwcm90b2NvbHMuDQpJbiBteSBzZW5zZSwgZXhwcmVzc2lvbiBpbiB0aGUgMTZ0aCBw b3JvY2VkdXJlIG9mIHNlY3Rpb24gNi4xLjIuMiBpcyBzb21ld2hhdCBjb25mdXNpbmcuIA0KSSB0 aGluayBpdCBjYW4gYmUgbW9kaWZpZWQgYXMgIiB0aGUgY29tcGxpYW5jZSBzdGF0dXMgaXMgaW5m b3JtZWQgdG8gZ2F0ZXdheSBieSBQVCBwcm90b2NvbCBvciBvdGhlciBwcm90b2NvbHMiLg0KPC9I YW4gWWluPg0KcmVnYXJkcywNCiAga2F1c2hpayANCg0KDQpUaGFuayB0byB0aGUgcmVxdWlyZW1l bnQgZGVzaWduIHRlYW0hDQoNCkJlc3QgcmVnYXJkcw0KDQpIYW4gWWluIA0KYXlpbmhhbkBodWF3 ZWkuY29tDQoNCj0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gDQqh oaGhoaGhoaGhoaGhoaGh1sINCsDxo6ENCg0KoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoUhh biBZaW4NCqGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaFheWluaGFuQGh1YXdlaS5jb20NCqGh oaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaEyMDA3LTAxLTI2DQo= --Boundary_(ID_qEXcoxH+svksvGCTqehlhw) Content-type: text/html; charset=gb2312 Content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yODAwLjE1ODYiIG5hbWU9R0VORVJBVE9SPjwvSEVBRD4NCjxCT0RZIGJnQ29sb3I9I2VhZWFl YT48Rk9OVCBzaXplPTI+PEZPTlQgZmFjZT3LzszlPkhpIEthdXNoaWsgDQpOYXJheWFuLDwvRk9O VD48L0ZPTlQ+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPcvOzOUgc2l6ZT0y PqGhoaFUaGFua3MgZm9yIHlvdXIgcmVzcG9uc2UuIFBsZWFzZSBmaW5kIG15IHJlc3BvbnNlIA0K aW5saW5lLjwvRk9OVD48L0RJVj4NCjxESVY+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9 y87M5SBzaXplPTI+PT09PT09PT0gMjAwNy0wMS0yNSZuYnNwOzAzOjM0OjAxJm5ic3A7xPrU2sC0 0MXW0NC0tcCjuiANCj09PT09PT09PC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxE SVY+PEZPTlQgc2l6ZT0yPg0KPFRBQkxFIHdpZHRoPSIxMDAlIj4NCiAgPFRCT0RZPg0KICA8VFI+ DQogICAgPFREIHdpZHRoPSIxMDAlIj4NCiAgICAgIDxCTE9DS1FVT1RFIA0KICAgICAgc3R5bGU9 IlBBRERJTkctUklHSFQ6IDBweDsgUEFERElORy1MRUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7 IEJPUkRFUi1MRUZUOiAjMDAwMDAwIDJweCBzb2xpZDsgTUFSR0lOLVJJR0hUOiAwcHgiPg0KICAg ICAgICA8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz01MzEyNDIyMTktMjQwMTIw MDc+PEZPTlQgZmFjZT1BcmlhbCANCiAgICAgICAgY29sb3I9IzAwMDBmZiBzaXplPTI+SGkgSGFu LDwvRk9OVD48L1NQQU4+PC9ESVY+DQogICAgICAgIDxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxT UEFOIGNsYXNzPTUzMTI0MjIxOS0yNDAxMjAwNz48Rk9OVCBmYWNlPUFyaWFsIA0KICAgICAgICBj b2xvcj0jMDAwMGZmIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KICAgICAgICA8 RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz01MzEyNDIyMTktMjQwMTIwMDc+PEZP TlQgZmFjZT1BcmlhbCANCiAgICAgICAgY29sb3I9IzAwMDBmZiBzaXplPTI+VGhhbmtzIGZvciB5 b3VyIGNvbW1lbnRzLiBQbGVhc2UgZmluZCBteSByZXNwb25zZSANCiAgICAgICAgaW5saW5lLjwv Rk9OVD48L1NQQU4+PC9ESVY+PEJSPg0KICAgICAgICA8RElWIGNsYXNzPU91dGxvb2tNZXNzYWdl SGVhZGVyIGxhbmc9ZW4tdXMgZGlyPWx0ciBhbGlnbj1sZWZ0Pg0KICAgICAgICA8SFIgdGFiSW5k ZXg9LTE+DQogICAgICAgIDxGT05UIGZhY2U9VGFob21hIHNpemU9Mj48Qj5Gcm9tOjwvQj4gSGFu IFlpbiANCiAgICAgICAgW21haWx0bzpheWluaGFuQGh1YXdlaS5jb21dIDxCUj48Qj5TZW50Ojwv Qj4gVHVlc2RheSwgSmFudWFyeSAyMywgMjAwNyANCiAgICAgICAgMTE6MjkgUE08QlI+PEI+VG86 PC9CPiBuZWFAaWV0Zi5vcmc8QlI+PEI+U3ViamVjdDo8L0I+IFtOZWFdIFBUIHByb3RvY29sIA0K ICAgICAgICBtdXN0IGJlIGNhcGFibGUgb2YgdHJhbnNwb3J0aW5nIG1lc3NhZ2VzIGZvciBhc3Nl c3NtZW50IGR1cmluZyBuZXR3b3JrIA0KICAgICAgICBjb25uZWN0aW9uIHJlcXVlc3QgPzxCUj48 L0ZPTlQ+PEJSPjwvRElWPg0KICAgICAgICA8RElWPjwvRElWPg0KICAgICAgICA8RElWPjxGT05U IHNpemU9Mj48Rk9OVCBzaXplPTM+SW4gbmV3IHJlcXVpcmVtZW50LCBpdCBpcyBwcmVzZW50ZWQg aW4gDQogICAgICAgIHNlY3Rpb24gNS4yLjMgUG9zdHVyZSBUcmFuc3BvcnQgUHJvdG9jb2w6PEJS PiJUaGUgUFQgcHJvdG9jb2wgbXVzdCBiZSANCiAgICAgICAgY2FwYWJsZSBvZiB0cmFuc3BvcnRp bmcgTWVzc2FnZXMgZm9yIEFzc2Vzc21lbnQmbmJzcDtkdXJpbmcgbmV0d29yayANCiAgICAgICAg Y29ubmVjdGlvbiByZXF1ZXN0IGFuZCBhZnRlciBuZXR3b3JrIGNvbm5lY3Rpdml0eSBoYXMgDQog ICAgICAgIGJlZW4mbmJzcDtlc3RhYmxpc2hlZC4iIEJ1dCBJIHRoaW5rIHRoaXMgaXMgb25seSBu ZWNlc3NhcnkgZm9yIA0KICAgICAgICBhc3Nlc3NtZW50IHRyaWdnZXJlZCZuYnNwO2J5IG5ldHdv cmsgY29ubmVjdGlvbiByZXF1ZXN0LiANCiAgICAgICAgPC9GT05UPjwvRk9OVD48Rk9OVCBzaXpl PTI+PEZPTlQgc2l6ZT0zPkFkZHRpb25hbCBpbiBTZWN0aW9uIDcuNCANCiAgICAgICAgUG9zdHVy ZW4gVHJhbnNwb3J0Jm5ic3A7KFBUKSBQcm90b2NvbCBSZXF1aXJlbWVudHMsIHRoZXJlIGlzIG5v IHN1Y2ggYSANCiAgICAgICAgcmVxdWlyZW1lbnQuIHdoeT88L0ZPTlQ+PC9GT05UPjxTUEFOIGNs YXNzPTUzMTI0MjIxOS0yNDAxMjAwNz48Rk9OVCANCiAgICAgICAgZmFjZT1BcmlhbCBjb2xvcj0j MDAwMGZmIHNpemU9Mj4mbmJzcDs8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICAgICAgICA8RElWPjxT UEFOIGNsYXNzPTUzMTI0MjIxOS0yNDAxMjAwNz48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAw ZmYgDQogICAgICAgIHNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KICAgICAgICA8 RElWPjxTUEFOIGNsYXNzPTUzMTI0MjIxOS0yNDAxMjAwNz48Rk9OVCBmYWNlPUFyaWFsIGNvbG9y PSMwMDAwZmYgDQogICAgICAgIHNpemU9Mj4mbHQ7S2F1c2hpayZndDsgVGhpcyByZXF1aXJlbWVu dCBpcyBjb3ZlcmVkIHVuZGVyICJDb21tb24gDQogICAgICAgIFJlcXVpcmVtZW50cyIgaW4gc2Vj dGlvbiA3LjEsIHRoZSByZXF1aXJlbWVudCBudW1iZXIgaXMgDQogICAgICAgIEMtMi48L0ZPTlQ+ PC9TUEFOPjwvRElWPg0KICAgICAgICA8RElWPjxTUEFOIGNsYXNzPTUzMTI0MjIxOS0yNDAxMjAw Nz48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQogICAgICAgIHNpemU9Mj48L0ZPTlQ+ PC9TUEFOPiZuYnNwOzwvRElWPg0KICAgICAgICA8RElWPjxTUEFOIGNsYXNzPTUzMTI0MjIxOS0y NDAxMjAwNz4NCiAgICAgICAgPERJVj48Rk9OVCBzaXplPTM+PFNQQU4gY2xhc3M9NTMxMjQyMjE5 LTI0MDEyMDA3Pg0KICAgICAgICA8RElWPjxTUEFOIGNsYXNzPTUzMTI0MjIxOS0yNDAxMjAwNz48 Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQogICAgICAgIHNpemU9Mj4mbHQ7SGFuIFlp biZndDs8L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICAgICAgICA8RElWPjxTUEFOIGNsYXNzPTUzMTI0 MjIxOS0yNDAxMjAwNz48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQogICAgICAgIHNp emU9Mj5ZZXMsIHN1Y2ggcmVxdWlyZW1lbnQgaXMgY292ZXJkIHVuZGVyIEMtMi48L0ZPTlQ+PC9T UEFOPjwvRElWPg0KICAgICAgICA8RElWPjxTUEFOIGNsYXNzPTUzMTI0MjIxOS0yNDAxMjAwNz48 Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQogICAgICAgIHNpemU9Mj5CdXQsIEkgdGhp bmsgc3VjaCByZXF1aXJlbWVudCBpcyB1bm5lY2Vzc2FyeS4gSW4gYWJzdHJhY3QsIGl0IGlzIA0K ICAgICAgICBzdGF0ZWQ6PC9GT05UPjwvU1BBTj48L0RJVj4NCiAgICAgICAgPERJVj48U1BBTiBj bGFzcz01MzEyNDIyMTktMjQwMTIwMDc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICJORUEgDQog ICAgICAgIHByb3ZpZGVzIG93bmVycyBvZiA8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG5l dHdvcmtzIChlLmcuIGFuIA0KICAgICAgICBlbnRlcnByaXNlIG9mZmVyaW5nIHJlbW90ZSBhY2Nl c3MpIGEgbWVjaGFuaXNtIA0KICAgICAgICA8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRv IGV2YWx1YXRlIHRoZSBwb3N0dXJlIG9mIGEgc3lzdGVtLiZuYnNwOyANCiAgICAgICAgVGhpcyBt YXkgdGFrZSBwbGFjZSBkdXJpbmcgPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGUgcmVx dWVzdCBmb3IgDQogICAgICAgIG5ldHdvcmsgYWNjZXNzIGFuZC9vciBzdWJzZXF1ZW50bHkgYXQg YW55IHRpbWUgDQogICAgICAgIDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgd2hpbGUgY29u bmVjdGVkIHRvIHRoZSANCiAgICAgICAgbmV0d29yay4iPC9TUEFOPjwvRElWPg0KICAgICAgICA8 RElWPjxTUEFOIGNsYXNzPTUzMTI0MjIxOS0yNDAxMjAwNz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgDQogICAgICAgIEFkZGl0aW9uYWxseSwgaW4gc29tZSBlbnZpcm9ubWVudCwgdGhlIGFzc2Vz c21lbnQgb25seSBvY2N1cnMgYWZ0ZXIgdGhlIA0KICAgICAgICBob3N0IGlzIGNvbm5lY3RlZCB0 byB0aGUgbmV0d29yaywgPC9TUEFOPjwvRElWPg0KICAgICAgICA8RElWPjxTUEFOIGNsYXNzPTUz MTI0MjIxOS0yNDAxMjAwNz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgd2hpY2ggaXMgDQogICAg ICAgIGRlc2NyaWJlZCBpbiBzZWN0aW9uIDYuMS4zLjEuJm5ic3A7IEluIHN1Y2ggY2FzZXMsIHVz ZXIgaXMgDQogICAgICAgIGNvbmNlcm5lZCZuYnNwO2Fib3V0IGVuZHBvaW50IHNlY3VyaXR5IHN0 YXR1cywgbm90IHRoZSBuZXR3b3JrIA0KICAgICAgICBhY2Nlc3MuPC9TUEFOPjwvRElWPg0KICAg ICAgICA8RElWPjxTUEFOIGNsYXNzPTUzMTI0MjIxOS0yNDAxMjAwNz48Rk9OVCBmYWNlPUFyaWFs IGNvbG9yPSMwMDAwZmYgDQogICAgICAgIHNpemU9Mj4mbHQ7L0hhbiANCiAgICAgICAgWWluJmd0 OzwvRk9OVD48L1NQQU4+PC9ESVY+PC9TUEFOPjwvRk9OVD48L0RJVj48L1NQQU4+PC9ESVY+DQog ICAgICAgIDxESVY+PFNQQU4gY2xhc3M9NTMxMjQyMjE5LTI0MDEyMDA3PjxGT05UIGZhY2U9QXJp YWwgY29sb3I9IzAwMDBmZiANCiAgICAgICAgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9E SVY+DQogICAgICAgIDxESVY+PEZPTlQgc2l6ZT0yPjxGT05UIHNpemU9Mz5PbiBteSB2aWV3LCBp ZiBQVCBwcm90b2NvbCBpcyBub3QgDQogICAgICAgIGV4cGVjdGVkIHRvIGNhcnJ5IGFzc2Vzc21l bnQgbWVzc2FnZXMgZHVyaW5nIG5ldHdvcmsgY29ubmVjdGlvbiByZXF1ZXN0LCANCiAgICAgICAg VExTIGlzIGEgZ29vZCBjaG9pY2UuIElmIFBUIHByb3RvY29sIGlzIGV4cGVjdGVkIHRvIGNhcnJ5 IGFzc2Vzc21lbnQgDQogICAgICAgIG1lc3NhZ2VzIGR1cmluZyBuZXR3b3JrIGNvbm5lY3Rpb24g cmVxdWVzdCwgRUFQLVRMUyBtaWdodCBiZSBhIA0KICAgICAgICBnb29kPEJSPmNob2ljZS4gV2h5 IHNob3VsZCB3ZSBjaG9vc2UgYW1vbmcgRUFQLVRUTFMvRUFQLUZBU1QvRUFQLVBFQVAgb3IgDQog ICAgICAgIGRlZmluZSBhIG5ldyBvbmU/PC9GT05UPjxTUEFOIGNsYXNzPTUzMTI0MjIxOS0yNDAx MjAwNz48Rk9OVCBmYWNlPUFyaWFsIA0KICAgICAgICBjb2xvcj0jMDAwMGZmIHNpemU9Mj4mbmJz cDs8L0ZPTlQ+PC9TUEFOPjwvRk9OVD48L0RJVj4NCiAgICAgICAgPERJVj48Rk9OVCBzaXplPTI+ PFNQQU4gDQogICAgICAgIGNsYXNzPTUzMTI0MjIxOS0yNDAxMjAwNz48L1NQQU4+PC9GT05UPiZu YnNwOzwvRElWPg0KICAgICAgICA8RElWPjxGT05UIHNpemU9Mj48U1BBTiBjbGFzcz01MzEyNDIy MTktMjQwMTIwMDc+Jmx0O0thdXNoaWsmZ3Q7IFRoaXMgDQogICAgICAgIGRyYWZ0IGlzIGludGVu ZGVkIHRvIGNhcHR1cmUgdGhlIHByb3RvY29sIHJlcXVpcmVtZW50czsgdGhlIGNob2ljZSBvZiAN CiAgICAgICAgcHJvdG9jb2xzIHdvdWxkIGJlIHBhcnQgb2YgZnV0dXJlIHdvcmsgd2hpY2gmbmJz cDttaWdodCBiZSBhZGRyZXNzZWQgYnkgDQogICAgICAgIGEgc2VwYXJhdGUgZHJhZnQuPC9TUEFO PjwvRk9OVD48L0RJVj4NCiAgICAgICAgPERJVj48Rk9OVCBzaXplPTI+PFNQQU4gDQogICAgICAg IGNsYXNzPTUzMTI0MjIxOS0yNDAxMjAwNz48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KICAg ICAgICA8RElWPjxGT05UIHNpemU9Mj48U1BBTiBjbGFzcz01MzEyNDIyMTktMjQwMTIwMDc+DQog ICAgICAgIDxESVY+PEZPTlQgc2l6ZT0zPjxTUEFOIGNsYXNzPTUzMTI0MjIxOS0yNDAxMjAwNz4N CiAgICAgICAgPERJVj48U1BBTiBjbGFzcz01MzEyNDIyMTktMjQwMTIwMDc+PEZPTlQgZmFjZT1B cmlhbCBjb2xvcj0jMDAwMGZmIA0KICAgICAgICBzaXplPTI+Jmx0O0hhbiBZaW4mZ3Q7PC9GT05U PjwvU1BBTj48L0RJVj4NCiAgICAgICAgPERJVj48U1BBTiBjbGFzcz01MzEyNDIyMTktMjQwMTIw MDc+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0KICAgICAgICBzaXplPTI+WWVzLCBQ VCBwcm90b2NvbCBpcyBhIHBhcnQgb2YgZnV0dXJlIHdvcmsuIEhvd2VydmVyLCZuYnNwO3RoZSAN CiAgICAgICAgcmVxdWlyZW1lbnQgb2YgUFQgcHJvdG9jb2wgbXVzdCBiZSBkZXRlcm1pbmVkIG5v dyAuIFBsZWFzZSBzZWUgDQogICAgICAgIGFib3ZlLjwvRk9OVD48L1NQQU4+PC9ESVY+DQogICAg ICAgIDxESVY+PFNQQU4gY2xhc3M9NTMxMjQyMjE5LTI0MDEyMDA3PjxGT05UIGZhY2U9QXJpYWwg Y29sb3I9IzAwMDBmZiANCiAgICAgICAgc2l6ZT0yPiZsdDsvSGFuIFlpbiZndDs8L0ZPTlQ+PC9T UEFOPjwvRElWPg0KICAgICAgICA8RElWPjxTUEFOIGNsYXNzPTUzMTI0MjIxOS0yNDAxMjAwNz48 Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQogICAgICAgIHNpemU9Mj48L0ZPTlQ+PC9T UEFOPiZuYnNwOzwvRElWPjwvU1BBTj48L0ZPTlQ+PC9ESVY+PC9TUEFOPjwvRElWPg0KICAgICAg ICA8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZj48L0ZPTlQ+PEJSPjxGT05UIHNp emU9Mz5Bbm90aGVyIA0KICAgICAgICBxdWVzdGlvbiBvZiBQVCBwcm90b2NvbDo8L0ZPTlQ+PC9E SVY+DQogICAgICAgIDxESVY+PEZPTlQgc2l6ZT0zPkluIHRoZSAxNnRoIHByb2NlZHVyZSBvZiBz ZWN0aW9uIDYuMS4yLjIsIGl0IA0KICAgICAgICBpcyZuYnNwO2Rlc2NyaWJlZCB0aGF0IFBUIHBy b3RvY29sIGluZm9ybXMgdGhlIGdhdGV3YXkgb2YgdGhlIGNvbXBsaWFuY2UgDQogICAgICAgIHN0 YXR1cy4gQnV0LCBob3cgdG8mbmJzcDthcHBseSB0aGUgcmVzdWx0IG9mIGFzc2Vzc21lbnQgdG8g bmV0d29yayANCiAgICAgICAgYWNjZXNzIGNvbnRyb2wgaXMgb3V0IG9mIE5FQSBXRyBzY29wZS4g SXMgaXQgYSB1bmludGVuZGVkIG1pc3Rha2U/PFNQQU4gDQogICAgICAgIGNsYXNzPTUzMTI0MjIx OS0yNDAxMjAwNz48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQogICAgICAgIHNpemU9 Mj4mbmJzcDs8L0ZPTlQ+PC9TUEFOPjwvRk9OVD48L0RJVj4NCiAgICAgICAgPERJVj48Rk9OVCBz aXplPTM+PFNQQU4gDQogICAgICAgIGNsYXNzPTUzMTI0MjIxOS0yNDAxMjAwNz48L1NQQU4+PC9G T05UPiZuYnNwOzwvRElWPg0KICAgICAgICA8RElWPjxGT05UIHNpemU9Mz48U1BBTiBjbGFzcz01 MzEyNDIyMTktMjQwMTIwMDc+PEZPTlQgZmFjZT1BcmlhbCANCiAgICAgICAgY29sb3I9IzAwMDBm ZiBzaXplPTI+Jmx0O0thdXNoaWsmZ3Q7IDwvRk9OVD4mbmJzcDs8Rk9OVCBmYWNlPUFyaWFsIA0K ICAgICAgICBjb2xvcj0jMDAwMGZmIHNpemU9Mj5UaGlzIGlzIGludGVudGlvbmFsIHNpbmNlIHRo ZSBtZWNoYW5pc21zIHVzZWQgdG8gDQogICAgICAgIGFwcGx5IGFjY2VzcyBjb250cm9sIGlzIG91 dCBvZiBzY29wZSBvZiB0aGUgTkVBIGNoYXJ0ZXIuIFRoZXJlIGlzIGEgbGluZSANCiAgICAgICAg aW4gdGhlIE5FQSBjaGFydGVyIHRoYXQgY2xlYXJseSBzdGF0ZXMuIDwvRk9OVD48L1NQQU4+PC9G T05UPjxGT05UIA0KICAgICAgICBzaXplPTM+PFNQQU4gY2xhc3M9NTMxMjQyMjE5LTI0MDEyMDA3 PiJTcGVjaWZ5aW5nIG1lY2hhbmlzbXMgZm9yIA0KICAgICAgICBwcm92aWRpbmcgcmVzdHJpY3Rl ZCBhY2Nlc3MgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhlIE5FQSANCiAgICAgICAgV0cuJm5i c3A7IjwvU1BBTj48L0ZPTlQ+PC9ESVY+DQogICAgICAgIDxESVY+PEZPTlQgc2l6ZT0zPjxTUEFO IGNsYXNzPTUzMTI0MjIxOS0yNDAxMjAwNz48L1NQQU4+PFNQQU4gDQogICAgICAgIGNsYXNzPTUz MTI0MjIxOS0yNDAxMjAwNz48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgDQogICAgICAg IHNpemU9Mj48L0ZPTlQ+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCiAgICAgICAgPERJVj48 Rk9OVCBzaXplPTM+PFNQQU4gY2xhc3M9NTMxMjQyMjE5LTI0MDEyMDA3Pg0KICAgICAgICA8RElW PjxTUEFOIGNsYXNzPTUzMTI0MjIxOS0yNDAxMjAwNz48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMw MDAwZmYgDQogICAgICAgIHNpemU9Mj4mbHQ7SGFuIFlpbiZndDs8L0ZPTlQ+PC9TUEFOPjwvRElW Pg0KICAgICAgICA8RElWPjxTUEFOIGNsYXNzPTUzMTI0MjIxOS0yNDAxMjAwNz48Rk9OVCBmYWNl PUFyaWFsIGNvbG9yPSMwMDAwZmYgDQogICAgICAgIHNpemU9Mj5CdXQsaW4gUmVxdWlyZSBJbnRy b2R1Y3Rpb24sIGl0IGlzIHN0YXRlZDogPC9GT05UPjwvU1BBTj48L0RJVj4NCiAgICAgICAgPERJ Vj48U1BBTiBjbGFzcz01MzEyNDIyMTktMjQwMTIwMDc+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0j MDAwMGZmIA0KICAgICAgICBzaXplPTI+IldoaWxlIHRoZSBORUEgUmVmZXJlbmNlIE1vZGVsIHJl Y29nbml6ZXMgdGhlcmUgaXMgDQogICAgICAgIDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgYSBsaW5rIGJldHdlZW4gYW4gRW5kcG9pbnQgQXNzZXNzbWVudCANCiAgICAgICAgYW5k IHRoZSBlbmZvcmNlbWVudCBvZiA8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRo ZSBBc3Nlc3NtZW50IA0KICAgICAgICBkZWNpc2lvbiwgdGhlIG1lY2hhbmlzbXMgYW5kIHByb3Rv Y29scyBmb3IgDQogICAgICAgIDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZW5m b3JjZW1lbnQgYXJlIG5vdCBpbiBzY29wZSBmb3IgdGhpcyANCiAgICAgICAgc3BlY2lmaWNhdGlv bi4iPC9GT05UPjwvU1BBTj48L0RJVj4NCiAgICAgICAgPERJVj48U1BBTiBjbGFzcz01MzEyNDIy MTktMjQwMTIwMDc+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIA0KICAgICAgICBzaXpl PTI+U28sIFBUIHByb3RvY29sIGlzIG5vdCByZXF1aXJlZCB0byBpbmZvcm0gdGhlIGFzc2VzcyBy ZXN1bHQgdG8gDQogICAgICAgIHRoZSBnYXRld2F5LiBEZXBsb3llciBjYW4gY29tcGxldGUgaXQg Ynkgb3RoZXIgDQogICAgICAgIHByb3RvY29scy48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KICAgICAg ICA8RElWPjxTUEFOIGNsYXNzPTUzMTI0MjIxOS0yNDAxMjAwNz48Rk9OVCBmYWNlPUFyaWFsIGNv bG9yPSMwMDAwZmYgDQogICAgICAgIHNpemU9Mj5JbiBteSBzZW5zZSwmbmJzcDtleHByZXNzaW9u IGluIHRoZSAxNnRoIHBvcm9jZWR1cmUgb2Ygc2VjdGlvbiANCiAgICAgICAgNi4xLjIuMiBpcyBz b21ld2hhdCBjb25mdXNpbmcuIDwvRk9OVD48L1NQQU4+PC9ESVY+DQogICAgICAgIDxESVY+PFNQ QU4gY2xhc3M9NTMxMjQyMjE5LTI0MDEyMDA3PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBm ZiANCiAgICAgICAgc2l6ZT0yPkkgdGhpbmsgaXQgY2FuIGJlIG1vZGlmaWVkIGFzJm5ic3A7IiB0 aGUgY29tcGxpYW5jZSBzdGF0dXMgaXMgDQogICAgICAgIGluZm9ybWVkIHRvIGdhdGV3YXkgYnkg UFQgcHJvdG9jb2wgb3Igb3RoZXIgDQogICAgICAgIHByb3RvY29scyIuPC9GT05UPjwvU1BBTj48 L0RJVj4NCiAgICAgICAgPERJVj48U1BBTiBjbGFzcz01MzEyNDIyMTktMjQwMTIwMDc+PC9TUEFO PjxTUEFOIA0KICAgICAgICBjbGFzcz01MzEyNDIyMTktMjQwMTIwMDc+PEZPTlQgZmFjZT1Bcmlh bCBjb2xvcj0jMDAwMGZmIHNpemU9Mj4mbHQ7L0hhbiANCiAgICAgICAgWWluJmd0OzwvRk9OVD48 L1NQQU4+PC9ESVY+PC9TUEFOPjwvRk9OVD48L0RJVj4NCiAgICAgICAgPERJVj48Rk9OVCBzaXpl PTM+PFNQQU4gY2xhc3M9NTMxMjQyMjE5LTI0MDEyMDA3PjxGT05UIGZhY2U9QXJpYWwgDQogICAg ICAgIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPnJlZ2FyZHMsPC9GT05UPjwvU1BBTj48L0ZPTlQ+PC9E SVY+DQogICAgICAgIDxESVY+PEZPTlQgc2l6ZT0zPjxTUEFOIGNsYXNzPTUzMTI0MjIxOS0yNDAx MjAwNz48Rk9OVCBmYWNlPUFyaWFsIA0KICAgICAgICBjb2xvcj0jMDAwMGZmIHNpemU9Mj4mbmJz cDsgDQogICAgICAgIGthdXNoaWs8L0ZPTlQ+Jm5ic3A7PC9TUEFOPjxCUj48QlI+PC9GT05UPjxC Uj5UaGFuayB0byB0aGUgcmVxdWlyZW1lbnQgDQogICAgICAgIGRlc2lnbiB0ZWFtITxCUj48QlI+ QmVzdCByZWdhcmRzPEJSPjwvRElWPg0KICAgICAgICA8RElWPkhhbiBZaW4gPC9ESVY+DQogICAg ICAgIDxESVY+PEEgDQogICAgICAgIGhyZWY9Im1haWx0bzpheWluaGFuQGh1YXdlaS5jb20iPmF5 aW5oYW5AaHVhd2VpLmNvbTwvQT48L0RJVj48L0ZPTlQ+PC9CTE9DS1FVT1RFPjwvVEQ+PC9UUj48 L1RCT0RZPjwvVEFCTEU+PC9GT05UPjwvRElWPg0KPERJVj4NCjxQPjxGT05UIGZhY2U9y87M5SBz aXplPTI+PSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA8L0ZPTlQ+ PC9QPg0KPFA+PEZPTlQgZmFjZT3LzszlIHNpemU9Mj6hoaGhoaGhoaGhoaGhoaGh1sI8QlI+wPGj oTwvRk9OVD48L1A+DQo8RElWPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPcvOzOUgc2l6 ZT0yPqGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaFIYW4gWWluPC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBmYWNlPcvOzOUgc2l6ZT0yPjxGT05UIGZhY2U9y87M5SBzaXplPTI+oaGhoaGhoaGh oaGhoaGhoaGhoaGhoaGhoaGhoTwvRk9OVD48QSANCmhyZWY9Im1haWx0bzpheWluaGFuQGh1YXdl aS5jb20iPmF5aW5oYW5AaHVhd2VpLmNvbTwvQT48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9y87M5SBzaXplPTI+oaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoTIwMDctMDEt MjY8L0ZPTlQ+PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPjwvRElWPjwvQk9EWT48L0hUTUw+DQo= --Boundary_(ID_qEXcoxH+svksvGCTqehlhw)-- --===============0891152883== 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 --===============0891152883==-- From nea-bounces@ietf.org Sat Jan 27 11:43:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAqde-0006HN-V9; Sat, 27 Jan 2007 11:42:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HAqdd-0006HG-7r for nea@ietf.org; Sat, 27 Jan 2007 11:42:49 -0500 Received: from nj300815-ier2.net.avaya.com ([198.152.12.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HAqdb-0002iP-Ju for nea@ietf.org; Sat, 27 Jan 2007 11:42:49 -0500 Received: from cof110avexu1.global.avaya.com (h135-9-6-16.avaya.com [135.9.6.16]) by nj300815-ier2.net.avaya.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l0RGge3G023625 for ; Sat, 27 Jan 2007 11:42:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: RE: [Nea] PT protocol must be capable of transporting messagesforassessment during network connection request ? Date: Sat, 27 Jan 2007 09:42:39 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [Nea] PT protocol must be capable of transporting messagesforassessment during network connection request ? Thread-Index: AcdAqBQ8ZwM8hIBkRiWdQi9cQ7x3VgBiD1jg References: <0JCF00APBQCA1C@szxml02-in.huawei.com> From: "Mani, Mahalingam \(Mani\)" To: "Han Yin" , "Kaushik Narayan \(kaushik\)" , "nea" X-Scanner: InterScan AntiVirus for Sendmail X-Spam-Score: 0.0 (/) X-Scan-Signature: 3c3f5218b222da1e73e850f1438da613 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="===============1879712467==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============1879712467== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C74232.28877A16" This is a multi-part message in MIME format. ------_=_NextPart_001_01C74232.28877A16 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Han, =20 Thanks for the thorough read and feedback. To your specific question on = 6.1.2.2 Sorry about the delay in responding. =20 Regards, -mani _____ =20 From: Han Yin [mailto:ayinhan@huawei.com]=20 Sent: Thursday, January 25, 2007 9:43 AM To: Kaushik Narayan (kaushik); nea Subject: Re: RE: [Nea] PT protocol must be capable of transporting = messagesforassessment during network connection request ? =20 Hi Kaushik Narayan,=20 =20 =A1=A1=A1=A1Thanks for your response. Please find my response inline. =20 =3D=3D=3D=3D=3D=3D=3D=3D 2007-01-25 03:34:01 = =C4=FA=D4=DA=C0=B4=D0=C5=D6=D0=D0=B4=B5=C0=A3=BA = =3D=3D=3D=3D=3D=3D=3D=3D =20 Hi Han, =20 Thanks for your comments. Please find my response inline. =20 [Mani, Mahalingam (Mani)] [snip] =09 Another question of PT protocol: In the 16th procedure of section 6.1.2.2, it is described that PT = protocol informs the gateway of the compliance status. But, how to apply = the result of assessment to network access control is out of NEA WG = scope. Is it a unintended mistake?=20 =20 This is intentional since the mechanisms used to apply = access control is out of scope of the NEA charter. There is a line in = the NEA charter that clearly states. "Specifying mechanisms for = providing restricted access is outside the scope of the NEA WG. " =20 But,in Require Introduction, it is stated:=20 "While the NEA Reference Model recognizes there is=20 a link between an Endpoint Assessment and the enforcement of=20 the Assessment decision, the mechanisms and protocols for=20 enforcement are not in scope for this specification." So, PT protocol is not required to inform the assess result to the = gateway. Deployer can complete it by other protocols. In my sense, expression in the 16th porocedure of section 6.1.2.2 is = somewhat confusing.=20 I think it can be modified as " the compliance status is informed to = gateway by PT protocol or other protocols". =20 [Mani, Mahalingam (Mani)] the first para at the beginning of section 6 = states the motivation of the section where it says=20 =A1=B0It should be emphasized that the provided examples are not = intended to indicate the only approach to addressing the use case but = rather are included to ease understanding of how the flows might occur = and require support from the NEA protocols.=A1=B1 This use-case cites PT as a possible carrier to help illustrate the = use-case. If it is confusing, it can be worded differently as you = suggest or, alternatively =A1=B0The PB server also informs the gateway of the compliance status, = so that it can take the appropriate enforcement action if = required.=A1=B1 Which is less specific about=20 regards, kaushik=20 =09 =09 Thank to the requirement design team! =09 Best regards Han Yin=20 ayinhan@huawei.com =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D = =3D =3D =3D =3D=20 =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=D6=C2 =C0=F1=A3=A1 =20 =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1= =A1=A1=A1Han Yin =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1= =A1=A1=A1ayinhan@huawei.com =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1= =A1=A1=A1=A1=A1=A1=A1=A1=A12007-01-26 =20 ------_=_NextPart_001_01C74232.28877A16 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Han,

 

Thanks for the thorough read and = feedback. To your specific question on 6.1.2.2

Sorry about the delay in = responding.

 

Regards,

-mani

From: Han = Yin [mailto:ayinhan@huawei.com]
Sent: Thursday, January = 25, 2007 9:43 AM
To: Kaushik Narayan = (kaushik); nea
Subject: Re: RE: [Nea] PT = protocol must be capable of transporting messagesforassessment during network = connection request ?

 

Hi Kaushik Narayan,

 

=A1=A1=A1=A1Thanks for your response. Please find my response = inline.

 

=3D=3D=3D=3D=3D=3D=3D=3D 2007-01-25 03:34:01 =C4=FA=D4=DA=C0=B4=D0=C5=D6=D0=D0=B4=B5=C0=A3=BA= = =3D=3D=3D=3D=3D=3D=3D=3D

 

Hi = Han,

 

Thanks for your comments. Please = find my response inline.

 

= [Mani, Mahalingam (Mani)] [snip]


Another question of PT protocol:

In the 16th procedure of section 6.1.2.2, it is described that PT protocol informs the gateway of the compliance status. But, = how to apply the result of assessment to network access control is out of NEA WG = scope. Is it a unintended mistake? 

 

<Kaushik> =  This is intentional since the mechanisms used to apply = access control is out of scope of the NEA charter. There is a line in the NEA charter that clearly states. "Specifying mechanisms = for providing restricted access is outside the scope of the NEA WG. "

 

<Han = Yin>

But,in Require Introduction, it = is stated:

"While the NEA Reference = Model recognizes there is
      a link between an Endpoint Assessment = and the enforcement of
      the Assessment decision, the mechanisms = and protocols for
      enforcement are not in scope for this specification."

So, PT protocol is not required = to inform the assess result to the gateway. Deployer can complete it by = other protocols.

In my sense, expression in = the 16th porocedure of section 6.1.2.2 is somewhat confusing. =

I think it can be modified as " the compliance status is informed to gateway by PT = protocol or other protocols".

</Han = Yin>

 

<mani>

[Mani, Mahalingam (Mani)] the first para at the = beginning of section 6 states the motivation of the section where it says =

=A1=B0It should be emphasized = that the provided examples are not intended to indicate the only approach to addressing the use case but rather are included to ease understanding = of how the flows might occur and require support from the NEA protocols.=A1=B1

This use-case cites PT as a possible carrier to help illustrate the = use-case. If it is confusing, it can be worded differently as you suggest or, = alternatively

=A1=B0The PB server also informs the gateway of the compliance status, so that it = can take the appropriate enforcement action if required.=A1=B1 Which is = less specific about

</mani>

regards,

  kaushik 


Thank to the requirement design team!

Best regards

Han Yin

=3D =3D = =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =3D =

=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1= =D6=C2
=C0=F1=A3=A1

 

=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1= =A1=A1=A1=A1=A1=A1Han Yin

=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1= =A1=A1=A1=A1=A1=A1ayinhan@huawei.com

=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1= =A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A1=A12007-01-26

 

------_=_NextPart_001_01C74232.28877A16-- --===============1879712467== 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 --===============1879712467==-- From nea-bounces@ietf.org Sun Jan 28 11:09:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBCaH-0000ny-1T; Sun, 28 Jan 2007 11:08:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBCaF-0000ns-NB for nea@ietf.org; Sun, 28 Jan 2007 11:08:47 -0500 Received: from szxga01-in.huawei.com ([61.144.161.53]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBCaC-0006Rf-ON for nea@ietf.org; Sun, 28 Jan 2007 11:08:47 -0500 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCL003R0659KE@szxga01-in.huawei.com> for nea@ietf.org; Mon, 29 Jan 2007 00:07:58 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCL005TT6590W@szxga01-in.huawei.com> for nea@ietf.org; Mon, 29 Jan 2007 00:07:57 +0800 (CST) Received: from dragon ([61.49.124.35]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JCL00FVO6589E@szxml01-in.huawei.com>; Mon, 29 Jan 2007 00:07:56 +0800 (CST) Date: Mon, 29 Jan 2007 00:12:56 +0800 From: Han Yin Subject: Re: RE: RE: [Nea] PT protocol must be capable of transportingmessagesforassessment during network connection request ? To: "Mani, Mahalingam (Mani)" , nea Message-id: <0JCL00FVP6589E@szxml01-in.huawei.com> MIME-version: 1.0 X-Mailer: Foxmail 5.0 [cn] X-Spam-Score: 0.1 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1228452547==" Errors-To: nea-bounces@ietf.org --===============1228452547== Content-type: text/plain; charset=gb2312 Content-transfer-encoding: base64 TWFoYWxpbmdhbSAoTWFuaSksDQoNCglUaGFua3MgZm9yIHlvdXIgcmVzcG9uc2UuDQoNCiAgICBJ IGFncmVlIHlvdXIgbW9kaWZpY2F0aW9uIGFib3V0IHNlY3Rpb24gNi4xLjEuMi4gU3VjaCBkZXNj cmlwdGlvbiBpcyBtb3JlIGNsZWFyLiAgICANCiAgICBIb3cgYWJvdXQgbXkgZmlzdCBxdWVzdGlv bj8NCg0KICAgIEluIHNvbWUgZW52aXJvbm1lbnQsIHRoZSBhc3Nlc3NtZW50IG9ubHkgb2NjdXJz IGFmdGVyIHRoZSBob3N0IGlzIGNvbm5lY3RlZCB0byB0aGUgbmV0d29yaywgd2hpY2ggaXMgZGVz Y3JpYmVkIGluIHNlY3Rpb24gNi4xLjMuMS4gIEluIHN1Y2ggY2FzZXMsIHVzZXIgaXMgY29uY2Vy bmVkIGFib3V0IGVuZHBvaW50IHNlY3VyaXR5IHN0YXR1cywgbm90IHRoZSBuZXR3b3JrIGFjY2Vz cy4gU2luY2UgaW5pdGFsLWFzc2Vzc21lbnQgYW5kIHJlLWFzc2Vzc21lbnQgaXMgYm90aCBwZXJm b3JtZWQgYWZ0ZXIgdGhlIGhvc3QgaXMgY29ubmVjdGVkIHRvIHRoZSBuZXR3b3JrLCAgaXQgaXMg dW5uZWNlc3NhcnkgdG8gcmVxdWlyZSBORUEgcHJvdG9jb2xzIGNhcnJ5IGFzc2Vzc21lbnQgbWVz c2FnZSBkdXJpbmcgbmV0d29yayBhY2Nlc3MgcmVxdWVzdC4gSSB0aGluayByZXF1aXJlbWVudCBD LTIgaXMgcmVkdW5kYW50IGFuZCBub3QgYWJsZSB0byBjb3ZlciB0aGUgdXNlIGNhc2UgaW4gNi4x LjMuMS4NCiAgICANCiAgICAgcmVnYXJkcywNCg0KoaGhoaGhoaGhoaGhoaGhoUhhbiBZaW4NCqGh oaGhoaGhoaGhoaGhoaFheWluaGFuQGh1YXdlaS5jb20NCg0KPT09PT09PT09PT09PT09PT09PT09 PT0NCg0KRlJPTTogICAgbW1hbmlAYXZheWEuY29tDQpTRU5UOiAgICAyMDA3LTAxLTI4IDAwOjQy OjM5DQpUTzogICAgICBheWluaGFuQGh1YXdlaS5jb207IGthdXNoaWtAY2lzY28uY29tOyBuZWFA aWV0Zi5vcmcNCkNDOiAgICAgIA0KU3ViamVjdDogUkU6IFJFOiBbTmVhXSBQVCBwcm90b2NvbCBt dXN0IGJlIGNhcGFibGUgb2YgdHJhbnNwb3J0aW5nbWVzc2FnZXNmb3Jhc3Nlc3NtZW50IGR1cmlu ZyBuZXR3b3JrIGNvbm5lY3Rpb24gcmVxdWVzdCA/DQoNCj5IYW4sDQo+DQo+IA0KPg0KPlRoYW5r cyBmb3IgdGhlIHRob3JvdWdoIHJlYWQgYW5kIGZlZWRiYWNrLiBUbyB5b3VyIHNwZWNpZmljIHF1 ZXN0aW9uIG9uIDYuMS4yLjINCj4NCj5Tb3JyeSBhYm91dCB0aGUgZGVsYXkgaW4gcmVzcG9uZGlu Zy4NCj4NCj4gDQo+DQo+UmVnYXJkcywNCj4NCj4tbWFuaQ0KPg0KPiAgX19fX18gIA0KPg0KPkZy b206IEhhbiBZaW4gW21haWx0bzpheWluaGFuQGh1YXdlaS5jb21dIA0KPlNlbnQ6IFRodXJzZGF5 LCBKYW51YXJ5IDI1LCAyMDA3IDk6NDMgQU0NCj5UbzogS2F1c2hpayBOYXJheWFuIChrYXVzaGlr KTsgbmVhDQo+U3ViamVjdDogUmU6IFJFOiBbTmVhXSBQVCBwcm90b2NvbCBtdXN0IGJlIGNhcGFi bGUgb2YgdHJhbnNwb3J0aW5nIG1lc3NhZ2VzZm9yYXNzZXNzbWVudCBkdXJpbmcgbmV0d29yayBj b25uZWN0aW9uIHJlcXVlc3QgPw0KPg0KPiANCj4NCj5IaSBLYXVzaGlrIE5hcmF5YW4sIA0KPg0K PiANCj4NCj6hoaGhVGhhbmtzIGZvciB5b3VyIHJlc3BvbnNlLiBQbGVhc2UgZmluZCBteSByZXNw b25zZSBpbmxpbmUuDQo+DQo+IA0KPg0KPj09PT09PT09IDIwMDctMDEtMjUgMDM6MzQ6MDEgxPrU 2sC00MXW0NC0tcCjuiA9PT09PT09PQ0KPg0KPiANCj4NCj4JSGkgSGFuLA0KPg0KPgkgDQo+DQo+ CVRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4gUGxlYXNlIGZpbmQgbXkgcmVzcG9uc2UgaW5saW5l Lg0KPg0KPgkgDQo+DQo+CVtNYW5pLCBNYWhhbGluZ2FtIChNYW5pKV0gW3NuaXBdDQo+DQo+CQ0K PglBbm90aGVyIHF1ZXN0aW9uIG9mIFBUIHByb3RvY29sOg0KPg0KPglJbiB0aGUgMTZ0aCBwcm9j ZWR1cmUgb2Ygc2VjdGlvbiA2LjEuMi4yLCBpdCBpcyBkZXNjcmliZWQgdGhhdCBQVCBwcm90b2Nv bCBpbmZvcm1zIHRoZSBnYXRld2F5IG9mIHRoZSBjb21wbGlhbmNlIHN0YXR1cy4gQnV0LCBob3cg dG8gYXBwbHkgdGhlIHJlc3VsdCBvZiBhc3Nlc3NtZW50IHRvIG5ldHdvcmsgYWNjZXNzIGNvbnRy b2wgaXMgb3V0IG9mIE5FQSBXRyBzY29wZS4gSXMgaXQgYSB1bmludGVuZGVkIG1pc3Rha2U/IA0K Pg0KPgkgDQo+DQo+CTxLYXVzaGlrPiAgVGhpcyBpcyBpbnRlbnRpb25hbCBzaW5jZSB0aGUgbWVj aGFuaXNtcyB1c2VkIHRvIGFwcGx5IGFjY2VzcyBjb250cm9sIGlzIG91dCBvZiBzY29wZSBvZiB0 aGUgTkVBIGNoYXJ0ZXIuIFRoZXJlIGlzIGEgbGluZSBpbiB0aGUgTkVBIGNoYXJ0ZXIgdGhhdCBj bGVhcmx5IHN0YXRlcy4gIlNwZWNpZnlpbmcgbWVjaGFuaXNtcyBmb3IgcHJvdmlkaW5nIHJlc3Ry aWN0ZWQgYWNjZXNzIGlzIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoZSBORUEgV0cuICINCj4NCj4J IA0KPg0KPgk8SGFuIFlpbj4NCj4NCj4JQnV0LGluIFJlcXVpcmUgSW50cm9kdWN0aW9uLCBpdCBp cyBzdGF0ZWQ6IA0KPg0KPgkiV2hpbGUgdGhlIE5FQSBSZWZlcmVuY2UgTW9kZWwgcmVjb2duaXpl cyB0aGVyZSBpcyANCj4JICAgICAgYSBsaW5rIGJldHdlZW4gYW4gRW5kcG9pbnQgQXNzZXNzbWVu dCBhbmQgdGhlIGVuZm9yY2VtZW50IG9mIA0KPgkgICAgICB0aGUgQXNzZXNzbWVudCBkZWNpc2lv biwgdGhlIG1lY2hhbmlzbXMgYW5kIHByb3RvY29scyBmb3IgDQo+CSAgICAgIGVuZm9yY2VtZW50 IGFyZSBub3QgaW4gc2NvcGUgZm9yIHRoaXMgc3BlY2lmaWNhdGlvbi4iDQo+DQo+CVNvLCBQVCBw cm90b2NvbCBpcyBub3QgcmVxdWlyZWQgdG8gaW5mb3JtIHRoZSBhc3Nlc3MgcmVzdWx0IHRvIHRo ZSBnYXRld2F5LiBEZXBsb3llciBjYW4gY29tcGxldGUgaXQgYnkgb3RoZXIgcHJvdG9jb2xzLg0K Pg0KPglJbiBteSBzZW5zZSwgZXhwcmVzc2lvbiBpbiB0aGUgMTZ0aCBwb3JvY2VkdXJlIG9mIHNl Y3Rpb24gNi4xLjIuMiBpcyBzb21ld2hhdCBjb25mdXNpbmcuIA0KPg0KPglJIHRoaW5rIGl0IGNh biBiZSBtb2RpZmllZCBhcyAiIHRoZSBjb21wbGlhbmNlIHN0YXR1cyBpcyBpbmZvcm1lZCB0byBn YXRld2F5IGJ5IFBUIHByb3RvY29sIG9yIG90aGVyIHByb3RvY29scyIuDQo+DQo+CTwvSGFuIFlp bj4NCj4NCj4JIA0KPg0KPgk8bWFuaT4NCj4NCj4JW01hbmksIE1haGFsaW5nYW0gKE1hbmkpXSB0 aGUgZmlyc3QgcGFyYSBhdCB0aGUgYmVnaW5uaW5nIG9mIHNlY3Rpb24gNiBzdGF0ZXMgdGhlIG1v dGl2YXRpb24gb2YgdGhlIHNlY3Rpb24gd2hlcmUgaXQgc2F5cyANCj4NCj4JobBJdCBzaG91bGQg YmUgZW1waGFzaXplZCB0aGF0IHRoZSBwcm92aWRlZCBleGFtcGxlcyBhcmUgbm90IGludGVuZGVk IHRvIGluZGljYXRlIHRoZSBvbmx5IGFwcHJvYWNoIHRvIGFkZHJlc3NpbmcgdGhlIHVzZSBjYXNl IGJ1dCByYXRoZXIgYXJlIGluY2x1ZGVkIHRvIGVhc2UgdW5kZXJzdGFuZGluZyBvZiBob3cgdGhl IGZsb3dzIG1pZ2h0IG9jY3VyIGFuZCByZXF1aXJlIHN1cHBvcnQgZnJvbSB0aGUgTkVBIHByb3Rv Y29scy6hsQ0KPg0KPglUaGlzIHVzZS1jYXNlIGNpdGVzIFBUIGFzIGEgcG9zc2libGUgY2Fycmll ciB0byBoZWxwIGlsbHVzdHJhdGUgdGhlIHVzZS1jYXNlLiBJZiBpdCBpcyBjb25mdXNpbmcsIGl0 IGNhbiBiZSB3b3JkZWQgZGlmZmVyZW50bHkgYXMgeW91IHN1Z2dlc3Qgb3IsIGFsdGVybmF0aXZl bHkNCj4NCj4JobBUaGUgUEIgc2VydmVyIGFsc28gaW5mb3JtcyB0aGUgZ2F0ZXdheSBvZiB0aGUg Y29tcGxpYW5jZSBzdGF0dXMsIHNvIHRoYXQgaXQgY2FuIHRha2UgdGhlIGFwcHJvcHJpYXRlIGVu Zm9yY2VtZW50IGFjdGlvbiBpZiByZXF1aXJlZC6hsSBXaGljaCBpcyBsZXNzIHNwZWNpZmljIGFi b3V0IA0KPg0KPgk8L21hbmk+DQo+DQo+CXJlZ2FyZHMsDQo+DQo+CSAga2F1c2hpayANCj4JDQo+ CQ0KPglUaGFuayB0byB0aGUgcmVxdWlyZW1lbnQgZGVzaWduIHRlYW0hDQo+CQ0KPglCZXN0IHJl Z2FyZHMNCj4NCj4JSGFuIFlpbiANCj4NCj4JYXlpbmhhbkBodWF3ZWkuY29tDQo+DQo+PSA9ID0g PSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSA9ID0gPSANCj4NCj4gDQo+DQo+oaGhoaGh oaGhoaGhoaGhoaGhoaGhoaGhoaGhoUhhbiBZaW4NCj4NCj6hoaGhoaGhoaGhoaGhoaGhoaGhoaGh oaGhoaGhYXlpbmhhbkBodWF3ZWkuY29tDQo+DQo+oaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGhoaGh oaGhoaGhoTIwMDctMDEtMjYNCj4NCj4gDQoNCg0K --===============1228452547== 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 --===============1228452547==-- From nea-bounces@ietf.org Sun Jan 28 20:04:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBKw2-0000KY-Lb; Sun, 28 Jan 2007 20:03:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBKw2-0000KL-36 for nea@ietf.org; Sun, 28 Jan 2007 20:03:50 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBKvz-00039R-5f for nea@ietf.org; Sun, 28 Jan 2007 20:03:50 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 28 Jan 2007 17:03:47 -0800 X-IronPort-AV: i="4.13,249,1167638400"; d="scan'208,217"; a="460276518:sNHT117896588" 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 l0T13j5s015670; Sun, 28 Jan 2007 17:03:45 -0800 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 l0T13eUw024083; Sun, 28 Jan 2007 17:03:40 -0800 (PST) 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); Sun, 28 Jan 2007 17:03:37 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: RE: [Nea] PT protocol must be capable of transporting messages forassessment during network connection request ? Date: Sun, 28 Jan 2007 17:03:35 -0800 Message-ID: <618694EF0B657246A4D55A97E38274C302E3889B@xmb-sjc-22d.amer.cisco.com> In-Reply-To: <0JCF00APBQCA1C@szxml02-in.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [Nea] PT protocol must be capable of transporting messages forassessment during network connection request ? Thread-Index: AcdAp7J8+TgSdC5sTxK+mexVLP53WAClvtkQ From: "Kaushik Narayan \(kaushik\)" To: "Han Yin" , "Mani, Mahalingam \(Mani\)" , "nea" X-OriginalArrivalTime: 29 Jan 2007 01:03:37.0699 (UTC) FILETIME=[4EC7A330:01C74341] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=19867; t=1170032625; x=1170896625; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kaushik@cisco.com; z=From:=20=22Kaushik=20Narayan=20\(kaushik\)=22=20 |Subject:=20RE=3A=20RE=3A=20[Nea]=20PT=20protocol=20must=20be=20capable=2 0of=20transporting=20messages=20forassessment=20during=20network=20connect ion=20request=20? |Sender:=20; bh=lFnnwzUBLDoXvrAYrcrwRc2fDQ8DDwzwORegELp00CQ=; b=tB4jb8Y80twA1pFOyCh39jeDV4zyR8QZrvK1pjXVAJ6pdEhzcvA3CVpZOrcc0vBtBy84AgNX B6xTyQWFrY76+/QL73rej3Kto8Kht7xKbaPChktaCFPIHtabw9+LoUVz; Authentication-Results: sj-dkim-2; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 1.0 (+) X-Scan-Signature: 4fc59e88b356924367ae169e6a06365d 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="===============0126820787==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============0126820787== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C74341.4E94F3ED" This is a multi-part message in MIME format. ------_=_NextPart_001_01C74341.4E94F3ED Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Hi Han, Sorry for the delay in responding. Please find my response inline with the tag In new requirement, it is presented in section 5.2.3 Posture Transport Protocol: "The PT protocol must be capable of transporting Messages for Assessment during network connection request and after network connectivity has been established." But I think this is only necessary for assessment triggered by network connection request. Addtional in Section 7.4 Posturen Transport (PT) Protocol Requirements, there is no such a requirement. why? This requirement is covered under "Common Requirements" in section 7.1, the requirement number is C-2. Yes, such requirement is coverd under C-2. But, I think such requirement is unnecessary. In abstract, it is stated: "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." Additionally, in some environment, the assessment only occurs after the host is connected to the network, which is described in section 6.1.3.1. In such cases, user is concerned about endpoint security status, not the network access. The ability to support endpoint assessment prior to network access and subsequently at any time when endpoint is connected to the network does have a impact on protocol design and choice and it is important to state this as a requirement in Section 7 even though the abstract makes a similar statement. On my view, if PT protocol is not expected to carry assessment messages during network connection request, TLS is a good choice. If PT protocol is expected to carry assessment messages during network connection request, EAP-TLS might be a good choice. Why should we choose among EAP-TTLS/EAP-FAST/EAP-PEAP or define a new one? This draft is intended to capture the protocol requirements; the choice of protocols would be part of future work which might be addressed by a separate draft. Yes, PT protocol is a part of future work. Howerver, the requirement of PT protocol must be determined now . Please see above. I am not sure that stating protocol choices such as TLS and EAP methods is part of requirements, I would consider that part of protocol design. Another question of PT protocol: In the 16th procedure of section 6.1.2.2, it is described that PT protocol informs the gateway of the compliance status. But, how to apply the result of assessment to network access control is out of NEA WG scope. Is it a unintended mistake? This is intentional since the mechanisms used to apply access control is out of scope of the NEA charter. There is a line in the NEA charter that clearly states. "Specifying mechanisms for providing restricted access is outside the scope of the NEA WG. " But,in Require Introduction, it is stated: "While the NEA Reference Model recognizes there is a link between an Endpoint Assessment and the enforcement of the Assessment decision, the mechanisms and protocols for enforcement are not in scope for this specification." So, PT protocol is not required to inform the assess result to the gateway. Deployer can complete it by other protocols. In my sense, expression in the 16th porocedure of section 6.1.2.2 is somewhat confusing. I think it can be modified as " the compliance status is informed to gateway by PT protocol or other protocols". I agree with you & Mani that we should modify the text in section 6.1.2.2. regards, kaushik ayinhan@huawei.com = = = = = = = = = = = = = = = = = = = = = = 　　　　　　　　致 礼！ 　　　　　　　　　　　　　　Han Yin 　　　　　　　　　　　　　　ayinhan@huawei.com 　　　　　　　　　　　　　　　　　2007-01-26 ------_=_NextPart_001_01C74341.4E94F3ED Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit
Hi Han,
 
Sorry for the delay in responding. Please find my response inline with the tag <Kaushik-Response>
 
<snipped>
 

 
In new requirement, it is presented in section 5.2.3 Posture Transport Protocol:
"The PT protocol must be capable of transporting Messages for Assessment during network connection request and after network connectivity has been established." But I think this is only necessary for assessment triggered by network connection request. Addtional in Section 7.4 Posturen Transport (PT) Protocol Requirements, there is no such a requirement. why? 
 
<Kaushik> This requirement is covered under "Common Requirements" in section 7.1, the requirement number is C-2.
 
<Han Yin>
Yes, such requirement is coverd under C-2.
But, I think such requirement is unnecessary. In abstract, it is stated:
     "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."
     Additionally, in some environment, the assessment only occurs after the host is connected to the network,
     which is described in section 6.1.3.1.  In such cases, user is concerned about endpoint security status, not the network access.
</Han Yin>
 
<Kaushik-Response>
 
The ability to support endpoint assessment prior to network access and subsequently at any time when endpoint is connected to the network does have a impact on protocol design and choice and it is important to state this as a requirement in Section 7 even though the abstract makes a similar statement.
 
</Kaushik-Response>
 
 
 
On my view, if PT protocol is not expected to carry assessment messages during network connection request, TLS is a good choice. If PT protocol is expected to carry assessment messages during network connection request, EAP-TLS might be a good
choice. Why should we choose among EAP-TTLS/EAP-FAST/EAP-PEAP or define a new one? 
 
<Kaushik> This draft is intended to capture the protocol requirements; the choice of protocols would be part of future work which might be addressed by a separate draft.
 
<Han Yin>
Yes, PT protocol is a part of future work. Howerver, the requirement of PT protocol must be determined now . Please see above.
</Han Yin>
 
 
<Kaushik-Response>
 
I am not sure that stating protocol choices such as TLS and EAP methods is part of requirements, I would consider that part of protocol design.
 
</Kaushik-Response>
 

Another question of PT protocol:
In the 16th procedure of section 6.1.2.2, it is described that PT protocol informs the gateway of the compliance status. But, how to apply the result of assessment to network access control is out of NEA WG scope. Is it a unintended mistake? 
 
<Kaushik>  This is intentional since the mechanisms used to apply access control is out of scope of the NEA charter. There is a line in the NEA charter that clearly states. "Specifying mechanisms for providing restricted access is outside the scope of the NEA WG. "
 
<Han Yin>
But,in Require Introduction, it is stated:
"While the NEA Reference Model recognizes there is
      a link between an Endpoint Assessment and the enforcement of
      the Assessment decision, the mechanisms and protocols for
      enforcement are not in scope for this specification."
So, PT protocol is not required to inform the assess result to the gateway. Deployer can complete it by other protocols.
In my sense, expression in the 16th porocedure of section 6.1.2.2 is somewhat confusing.
I think it can be modified as " the compliance status is informed to gateway by PT protocol or other protocols".
</Han Yin>
 
<Kaushik-Response>
 
I agree with you &  Mani that we should modify the text in section 6.1.2.2.
 
regards,
 kaushik
 
</Kaushik-Response>
 
 
 
 

= = = = = = = = = = = = = = = = = = = = = =

　　　　　　　　致
礼！

 
　　　　　　　　　　　　　　Han Yin
　　　　　　　　　　　　　　ayinhan@huawei.com
　　　　　　　　　　　　　　　　　2007-01-26
 
------_=_NextPart_001_01C74341.4E94F3ED-- --===============0126820787== 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 --===============0126820787==-- From nea-bounces@ietf.org Mon Jan 29 23:03:07 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBkCX-0004xm-St; Mon, 29 Jan 2007 23:02:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBkCX-0004vZ-2f for nea@ietf.org; Mon, 29 Jan 2007 23:02:33 -0500 Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBkCR-0004Lg-U9 for nea@ietf.org; Mon, 29 Jan 2007 23:02:33 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JCN002MRXUMHX@szxga02-in.huawei.com> for nea@ietf.org; Tue, 30 Jan 2007 12:01:34 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JCN0052JXUJWH@szxga02-in.huawei.com> for nea@ietf.org; Tue, 30 Jan 2007 12:01:34 +0800 (CST) Received: from y34728 ([10.110.31.96]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JCN00HPRXUIKY@szxml04-in.huawei.com> for nea@ietf.org; Tue, 30 Jan 2007 12:01:31 +0800 (CST) Date: Tue, 30 Jan 2007 12:01:30 +0800 From: Han Yin Subject: Re: RE: [Nea] PT protocol must be capable of transporting messages forassessment during network connection request ? To: "Kaushik Narayan (kaushik)" , "Mani, Mahalingam (Mani)" , nea Message-id: <015301c74423$52e98bd0$601f6e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Mailer: Microsoft Outlook Express 5.50.4927.1200 X-Priority: 3 X-MSMail-priority: Normal References: <618694EF0B657246A4D55A97E38274C302E3889B@xmb-sjc-22d.amer.cisco.com> X-Spam-Score: 1.1 (+) X-Scan-Signature: 94962611154c8404498b19f744990308 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="===============0642002576==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============0642002576== Content-type: multipart/alternative; boundary="Boundary_(ID_9YWCEcUr1TLQYIEYqX5/PA)" This is a multi-part message in MIME format. --Boundary_(ID_9YWCEcUr1TLQYIEYqX5/PA) Content-type: text/plain; charset=iso-2022-jp Content-transfer-encoding: 7BIT Hi Kaushik, Thanks for your responding. I do not want to state protocol choices in requirements document. >From my point of view, Requiremt C-2 is not flexible and not to cover the use case in 6.1.3. Since in some environment, inital-assessment and re-assessment are both performed after the host is connected to the network, it is uncessary to require that NEA protocols must be capable of carrying assessment message during network access request. We can define several PT protocols(certainly, not in requirement document) which might carry assessment messary in different cases. However, in my opinon, the range of available PT protoco is reduced by Requirement C-2, which claims "NEA protocols MUST allow the NEA Server to initiate requests for Posture information prior ...... AND at any time after the ...... ". Additionally, in section 5.2.3 Posture Transport Protocol, It is claimed "The PT protocol must be capable of transporting Messages for Assessment during .... AND after ...." So, some PT protocols surpporting other requirements could be excluded because of these claims. For examle, in some cases descibed in section 6.1.3, some protocols that can only carry assessment message after the host is connected to network might act as PT protocol, but not meet the claims above. Therefore, I think that these claims might be modified from "AND" to "AND/OR", which could increase the flexibility of PT protocol selection. Regards, Han Yin ayinhan@huawei.com ----- Original Message ----- From: Kaushik Narayan (kaushik) To: Han Yin ; Mani, Mahalingam (Mani) ; nea Sent: Monday, January 29, 2007 9:03 AM Subject: RE: RE: [Nea] PT protocol must be capable of transporting messages forassessment during network connection request ? Hi Han, Sorry for the delay in responding. Please find my response inline with the tag In new requirement, it is presented in section 5.2.3 Posture Transport Protocol: "The PT protocol must be capable of transporting Messages for Assessment during network connection request and after network connectivity has been established." But I think this is only necessary for assessment triggered by network connection request. Addtional in Section 7.4 Posturen Transport (PT) Protocol Requirements, there is no such a requirement. why? This requirement is covered under "Common Requirements" in section 7.1, the requirement number is C-2. Yes, such requirement is coverd under C-2. But, I think such requirement is unnecessary. In abstract, it is stated: "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." Additionally, in some environment, the assessment only occurs after the host is connected to the network, which is described in section 6.1.3.1. In such cases, user is concerned about endpoint security status, not the network access. The ability to support endpoint assessment prior to network access and subsequently at any time when endpoint is connected to the network does have a impact on protocol design and choice and it is important to state this as a requirement in Section 7 even though the abstract makes a similar statement. On my view, if PT protocol is not expected to carry assessment messages during network connection request, TLS is a good choice. If PT protocol is expected to carry assessment messages during network connection request, EAP-TLS might be a good choice. Why should we choose among EAP-TTLS/EAP-FAST/EAP-PEAP or define a new one? This draft is intended to capture the protocol requirements; the choice of protocols would be part of future work which might be addressed by a separate draft. Yes, PT protocol is a part of future work. Howerver, the requirement of PT protocol must be determined now . Please see above. I am not sure that stating protocol choices such as TLS and EAP methods is part of requirements, I would consider that part of protocol design. Another question of PT protocol: In the 16th procedure of section 6.1.2.2, it is described that PT protocol informs the gateway of the compliance status. But, how to apply the result of assessment to network access control is out of NEA WG scope. Is it a unintended mistake? This is intentional since the mechanisms used to apply access control is out of scope of the NEA charter. There is a line in the NEA charter that clearly states. "Specifying mechanisms for providing restricted access is outside the scope of the NEA WG. " But,in Require Introduction, it is stated: "While the NEA Reference Model recognizes there is a link between an Endpoint Assessment and the enforcement of the Assessment decision, the mechanisms and protocols for enforcement are not in scope for this specification." So, PT protocol is not required to inform the assess result to the gateway. Deployer can complete it by other protocols. In my sense, expression in the 16th porocedure of section 6.1.2.2 is somewhat confusing. I think it can be modified as " the compliance status is informed to gateway by PT protocol or other protocols". I agree with you & Mani that we should modify the text in section 6.1.2.2. regards, kaushik ayinhan@huawei.com = = = = = = = = = = = = = = = = = = = = = = 　　　　　　　　致 礼！ 　　　　　　　　　　　　　　Han Yin 　　　　　　　　　　　　　　ayinhan@huawei.com 　　　　　　　　　　　　　　　　　2007-01-26 --Boundary_(ID_9YWCEcUr1TLQYIEYqX5/PA) Content-type: text/html; charset=iso-2022-jp Content-transfer-encoding: 7BIT
Hi Kaushik,
Thanks for your responding.
I do not want to state protocol choices in requirements document.
 
From my point of view,  Requiremt C-2 is not flexible and not to cover the use case in 6.1.3.
Since in some environment, inital-assessment and re-assessment  are both performed after the host is connected to the network, it is uncessary to require that  NEA protocols must be capable of carrying assessment message during network access request.
We can define several PT protocols(certainly, not in requirement document) which might carry assessment messary in different cases.
 
However, in my opinon, the range of available PT protoco is reduced by  Requirement C-2, which claims "NEA protocols MUST allow the NEA Server to initiate requests for Posture information prior ...... AND at any time after the ...... ". Additionally, in section 5.2.3 Posture Transport Protocol, It is claimed "The PT protocol must be capable of transporting Messages for Assessment during .... AND after ...." So, some PT protocols surpporting other requirements could be excluded because of these claims. For examle, in some cases descibed in section 6.1.3,
some protocols that can only carry assessment message after the host is connected to network might act as PT protocol, but not meet the claims above.
 
Therefore, I think that these claims might be modified from "AND" to "AND/OR", which could increase the flexibility of PT protocol selection.
 
Regards,
 
Han Yin
 
 
 
----- Original Message -----
Sent: Monday, January 29, 2007 9:03 AM
Subject: RE: RE: [Nea] PT protocol must be capable of transporting messages forassessment during network connection request ?

Hi Han,
 
Sorry for the delay in responding. Please find my response inline with the tag <Kaushik-Response>
 
<snipped>
 

 
In new requirement, it is presented in section 5.2.3 Posture Transport Protocol:
"The PT protocol must be capable of transporting Messages for Assessment during network connection request and after network connectivity has been established." But I think this is only necessary for assessment triggered by network connection request. Addtional in Section 7.4 Posturen Transport (PT) Protocol Requirements, there is no such a requirement. why? 
 
<Kaushik> This requirement is covered under "Common Requirements" in section 7.1, the requirement number is C-2.
 
<Han Yin>
Yes, such requirement is coverd under C-2.
But, I think such requirement is unnecessary. In abstract, it is stated:
     "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."
     Additionally, in some environment, the assessment only occurs after the host is connected to the network,
     which is described in section 6.1.3.1.  In such cases, user is concerned about endpoint security status, not the network access.
</Han Yin>
 
<Kaushik-Response>
 
The ability to support endpoint assessment prior to network access and subsequently at any time when endpoint is connected to the network does have a impact on protocol design and choice and it is important to state this as a requirement in Section 7 even though the abstract makes a similar statement.
 
</Kaushik-Response>
 
 
 
On my view, if PT protocol is not expected to carry assessment messages during network connection request, TLS is a good choice. If PT protocol is expected to carry assessment messages during network connection request, EAP-TLS might be a good
choice. Why should we choose among EAP-TTLS/EAP-FAST/EAP-PEAP or define a new one? 
 
<Kaushik> This draft is intended to capture the protocol requirements; the choice of protocols would be part of future work which might be addressed by a separate draft.
 
<Han Yin>
Yes, PT protocol is a part of future work. Howerver, the requirement of PT protocol must be determined now . Please see above.
</Han Yin>
 
 
<Kaushik-Response>
 
I am not sure that stating protocol choices such as TLS and EAP methods is part of requirements, I would consider that part of protocol design.
 
</Kaushik-Response>
 

Another question of PT protocol:
In the 16th procedure of section 6.1.2.2, it is described that PT protocol informs the gateway of the compliance status. But, how to apply the result of assessment to network access control is out of NEA WG scope. Is it a unintended mistake? 
 
<Kaushik>  This is intentional since the mechanisms used to apply access control is out of scope of the NEA charter. There is a line in the NEA charter that clearly states. "Specifying mechanisms for providing restricted access is outside the scope of the NEA WG. "
 
<Han Yin>
But,in Require Introduction, it is stated:
"While the NEA Reference Model recognizes there is
      a link between an Endpoint Assessment and the enforcement of
      the Assessment decision, the mechanisms and protocols for
      enforcement are not in scope for this specification."
So, PT protocol is not required to inform the assess result to the gateway. Deployer can complete it by other protocols.
In my sense, expression in the 16th porocedure of section 6.1.2.2 is somewhat confusing.
I think it can be modified as " the compliance status is informed to gateway by PT protocol or other protocols".
</Han Yin>
 
<Kaushik-Response>
 
I agree with you &  Mani that we should modify the text in section 6.1.2.2.
 
regards,
 kaushik
 
</Kaushik-Response>
 
 
 
 

= = = = = = = = = = = = = = = = = = = = = =

　　　　　　　　致
礼！

 
　　　　　　　　　　　　　　Han Yin
　　　　　　　　　　　　　　ayinhan@huawei.com
　　　　　　　　　　　　　　　　　2007-01-26
 
--Boundary_(ID_9YWCEcUr1TLQYIEYqX5/PA)-- --===============0642002576== 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 --===============0642002576==-- From nea-bounces@ietf.org Tue Jan 30 16:09:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC0E0-0008Ru-1O; Tue, 30 Jan 2007 16:09:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HC0Dy-0008Rj-RX for nea@ietf.org; Tue, 30 Jan 2007 16:09:06 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HC0Dw-0002SV-O8 for nea@ietf.org; Tue, 30 Jan 2007 16:09:06 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 30 Jan 2007 13:09:03 -0800 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l0UL93aj023852; Tue, 30 Jan 2007 13:09:03 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l0UL8xho022213; Tue, 30 Jan 2007 13:08:59 -0800 (PST) Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 30 Jan 2007 13:08:58 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: RE: [Nea] PT protocol must be capable of transporting messages forassessment during network connection request ? Date: Tue, 30 Jan 2007 13:08:49 -0800 Message-ID: <618694EF0B657246A4D55A97E38274C302E99CE7@xmb-sjc-22d.amer.cisco.com> In-Reply-To: <015301c74423$52e98bd0$601f6e0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE: [Nea] PT protocol must be capable of transporting messages forassessment during network connection request ? Thread-Index: AcdEI1oPjG8VIQkkQaal9r/Dj851OQAjwGjg From: "Kaushik Narayan \(kaushik\)" To: "Han Yin" , "Mani, Mahalingam \(Mani\)" , "nea" X-OriginalArrivalTime: 30 Jan 2007 21:08:58.0358 (UTC) FILETIME=[DBAA3160:01C744B2] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=27711; t=1170191343; x=1171055343; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kaushik@cisco.com; z=From:=20=22Kaushik=20Narayan=20\(kaushik\)=22=20 |Subject:=20RE=3A=20RE=3A=20[Nea]=20PT=20protocol=20must=20be=20capable=2 0of=20transporting=20messages=20forassessment=20during=20network=20connect ion=20request=20? |Sender:=20; bh=/RcVbbrR8nVvzOfUkZ1kVHqcr7su/LMRzSiiHeGs5Yg=; b=DmiC38mIKzcdJjDSXcXgjmiA9G7SbB1mrzjgvu6Z2uEqGNS0UGDIDMCyt6AjlNtuEhrjjZkk OQNHBgbwk2AiACWwvjrRgIrw73BcJee8BFpKxu39CwGLMMD3XkOclu3W; Authentication-Results: sj-dkim-7; header.From=kaushik@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 1.1 (+) X-Scan-Signature: 69ad46fbd0e474a7c7f3312d9e320336 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="===============0784200113==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============0784200113== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C744B2.DB739995" This is a multi-part message in MIME format. ------_=_NextPart_001_01C744B2.DB739995 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Hi Han, I think that is a fair suggestion and we will update the document. regards, kaushik ________________________________ From: Han Yin [mailto:ayinhan@huawei.com] Sent: Monday, January 29, 2007 8:02 PM To: Kaushik Narayan (kaushik); Mani, Mahalingam (Mani); nea Subject: Re: RE: [Nea] PT protocol must be capable of transporting messages forassessment during network connection request ? Hi Kaushik, Thanks for your responding. I do not want to state protocol choices in requirements document. >From my point of view, Requiremt C-2 is not flexible and not to cover the use case in 6.1.3. Since in some environment, inital-assessment and re-assessment are both performed after the host is connected to the network, it is uncessary to require that NEA protocols must be capable of carrying assessment message during network access request. We can define several PT protocols(certainly, not in requirement document) which might carry assessment messary in different cases. However, in my opinon, the range of available PT protoco is reduced by Requirement C-2, which claims "NEA protocols MUST allow the NEA Server to initiate requests for Posture information prior ...... AND at any time after the ...... ". Additionally, in section 5.2.3 Posture Transport Protocol, It is claimed "The PT protocol must be capable of transporting Messages for Assessment during .... AND after ...." So, some PT protocols surpporting other requirements could be excluded because of these claims. For examle, in some cases descibed in section 6.1.3, some protocols that can only carry assessment message after the host is connected to network might act as PT protocol, but not meet the claims above. Therefore, I think that these claims might be modified from "AND" to "AND/OR", which could increase the flexibility of PT protocol selection. Regards, Han Yin ayinhan@huawei.com ----- Original Message ----- From: Kaushik Narayan (kaushik) To: Han Yin ; Mani, Mahalingam (Mani) ; nea Sent: Monday, January 29, 2007 9:03 AM Subject: RE: RE: [Nea] PT protocol must be capable of transporting messages forassessment during network connection request ? Hi Han, Sorry for the delay in responding. Please find my response inline with the tag In new requirement, it is presented in section 5.2.3 Posture Transport Protocol: "The PT protocol must be capable of transporting Messages for Assessment during network connection request and after network connectivity has been established." But I think this is only necessary for assessment triggered by network connection request. Addtional in Section 7.4 Posturen Transport (PT) Protocol Requirements, there is no such a requirement. why? This requirement is covered under "Common Requirements" in section 7.1, the requirement number is C-2. Yes, such requirement is coverd under C-2. But, I think such requirement is unnecessary. In abstract, it is stated: "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." Additionally, in some environment, the assessment only occurs after the host is connected to the network, which is described in section 6.1.3.1. In such cases, user is concerned about endpoint security status, not the network access. The ability to support endpoint assessment prior to network access and subsequently at any time when endpoint is connected to the network does have a impact on protocol design and choice and it is important to state this as a requirement in Section 7 even though the abstract makes a similar statement. On my view, if PT protocol is not expected to carry assessment messages during network connection request, TLS is a good choice. If PT protocol is expected to carry assessment messages during network connection request, EAP-TLS might be a good choice. Why should we choose among EAP-TTLS/EAP-FAST/EAP-PEAP or define a new one? This draft is intended to capture the protocol requirements; the choice of protocols would be part of future work which might be addressed by a separate draft. Yes, PT protocol is a part of future work. Howerver, the requirement of PT protocol must be determined now . Please see above. I am not sure that stating protocol choices such as TLS and EAP methods is part of requirements, I would consider that part of protocol design. Another question of PT protocol: In the 16th procedure of section 6.1.2.2, it is described that PT protocol informs the gateway of the compliance status. But, how to apply the result of assessment to network access control is out of NEA WG scope. Is it a unintended mistake? This is intentional since the mechanisms used to apply access control is out of scope of the NEA charter. There is a line in the NEA charter that clearly states. "Specifying mechanisms for providing restricted access is outside the scope of the NEA WG. " But,in Require Introduction, it is stated: "While the NEA Reference Model recognizes there is a link between an Endpoint Assessment and the enforcement of the Assessment decision, the mechanisms and protocols for enforcement are not in scope for this specification." So, PT protocol is not required to inform the assess result to the gateway. Deployer can complete it by other protocols. In my sense, expression in the 16th porocedure of section 6.1.2.2 is somewhat confusing. I think it can be modified as " the compliance status is informed to gateway by PT protocol or other protocols". I agree with you & Mani that we should modify the text in section 6.1.2.2. regards, kaushik ayinhan@huawei.com = = = = = = = = = = = = = = = = = = = = = = 　　　　　　　　致 礼！ 　　　　　　　　　　　　　　Han Yin 　　　　　　　　　　　　　　ayinhan@huawei.com 　　　　　　　　　　　　　　　　　2007-01-26 ------_=_NextPart_001_01C744B2.DB739995 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit
Hi Han,
 
I think that is a fair suggestion and we will update the document.
 
regards,
  kaushik

From: Han Yin [mailto:ayinhan@huawei.com]
Sent: Monday, January 29, 2007 8:02 PM
To: Kaushik Narayan (kaushik); Mani, Mahalingam (Mani); nea
Subject: Re: RE: [Nea] PT protocol must be capable of transporting messages forassessment during network connection request ?

Hi Kaushik,
Thanks for your responding.
I do not want to state protocol choices in requirements document.
 
From my point of view,  Requiremt C-2 is not flexible and not to cover the use case in 6.1.3.
Since in some environment, inital-assessment and re-assessment  are both performed after the host is connected to the network, it is uncessary to require that  NEA protocols must be capable of carrying assessment message during network access request.
We can define several PT protocols(certainly, not in requirement document) which might carry assessment messary in different cases.
 
However, in my opinon, the range of available PT protoco is reduced by  Requirement C-2, which claims "NEA protocols MUST allow the NEA Server to initiate requests for Posture information prior ...... AND at any time after the ...... ". Additionally, in section 5.2.3 Posture Transport Protocol, It is claimed "The PT protocol must be capable of transporting Messages for Assessment during .... AND after ...." So, some PT protocols surpporting other requirements could be excluded because of these claims. For examle, in some cases descibed in section 6.1.3,
some protocols that can only carry assessment message after the host is connected to network might act as PT protocol, but not meet the claims above.
 
Therefore, I think that these claims might be modified from "AND" to "AND/OR", which could increase the flexibility of PT protocol selection.
 
Regards,
 
Han Yin
 
 
 
----- Original Message -----
Sent: Monday, January 29, 2007 9:03 AM
Subject: RE: RE: [Nea] PT protocol must be capable of transporting messages forassessment during network connection request ?

Hi Han,
 
Sorry for the delay in responding. Please find my response inline with the tag <Kaushik-Response>
 
<snipped>
 

 
In new requirement, it is presented in section 5.2.3 Posture Transport Protocol:
"The PT protocol must be capable of transporting Messages for Assessment during network connection request and after network connectivity has been established." But I think this is only necessary for assessment triggered by network connection request. Addtional in Section 7.4 Posturen Transport (PT) Protocol Requirements, there is no such a requirement. why? 
 
<Kaushik> This requirement is covered under "Common Requirements" in section 7.1, the requirement number is C-2.
 
<Han Yin>
Yes, such requirement is coverd under C-2.
But, I think such requirement is unnecessary. In abstract, it is stated:
     "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."
     Additionally, in some environment, the assessment only occurs after the host is connected to the network,
     which is described in section 6.1.3.1.  In such cases, user is concerned about endpoint security status, not the network access.
</Han Yin>
 
<Kaushik-Response>
 
The ability to support endpoint assessment prior to network access and subsequently at any time when endpoint is connected to the network does have a impact on protocol design and choice and it is important to state this as a requirement in Section 7 even though the abstract makes a similar statement.
 
</Kaushik-Response>
 
 
 
On my view, if PT protocol is not expected to carry assessment messages during network connection request, TLS is a good choice. If PT protocol is expected to carry assessment messages during network connection request, EAP-TLS might be a good
choice. Why should we choose among EAP-TTLS/EAP-FAST/EAP-PEAP or define a new one? 
 
<Kaushik> This draft is intended to capture the protocol requirements; the choice of protocols would be part of future work which might be addressed by a separate draft.
 
<Han Yin>
Yes, PT protocol is a part of future work. Howerver, the requirement of PT protocol must be determined now . Please see above.
</Han Yin>
 
 
<Kaushik-Response>
 
I am not sure that stating protocol choices such as TLS and EAP methods is part of requirements, I would consider that part of protocol design.
 
</Kaushik-Response>
 

Another question of PT protocol:
In the 16th procedure of section 6.1.2.2, it is described that PT protocol informs the gateway of the compliance status. But, how to apply the result of assessment to network access control is out of NEA WG scope. Is it a unintended mistake? 
 
<Kaushik>  This is intentional since the mechanisms used to apply access control is out of scope of the NEA charter. There is a line in the NEA charter that clearly states. "Specifying mechanisms for providing restricted access is outside the scope of the NEA WG. "
 
<Han Yin>
But,in Require Introduction, it is stated:
"While the NEA Reference Model recognizes there is
      a link between an Endpoint Assessment and the enforcement of
      the Assessment decision, the mechanisms and protocols for
      enforcement are not in scope for this specification."
So, PT protocol is not required to inform the assess result to the gateway. Deployer can complete it by other protocols.
In my sense, expression in the 16th porocedure of section 6.1.2.2 is somewhat confusing.
I think it can be modified as " the compliance status is informed to gateway by PT protocol or other protocols".
</Han Yin>
 
<Kaushik-Response>
 
I agree with you &  Mani that we should modify the text in section 6.1.2.2.
 
regards,
 kaushik
 
</Kaushik-Response>
 
 
 
 

= = = = = = = = = = = = = = = = = = = = = =

　　　　　　　　致
礼！

 
　　　　　　　　　　　　　　Han Yin
　　　　　　　　　　　　　　ayinhan@huawei.com
　　　　　　　　　　　　　　　　　2007-01-26
 
------_=_NextPart_001_01C744B2.DB739995-- --===============0784200113== 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 --===============0784200113==--