From nea-bounces@ietf.org Mon Apr 02 18:03:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYUc6-0008DL-Hr; Mon, 02 Apr 2007 18:02:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYUc5-0008AZ-El for nea@ietf.org; Mon, 02 Apr 2007 18:02:57 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYUc0-0004lQ-R4 for nea@ietf.org; Mon, 02 Apr 2007 18:02:57 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 02 Apr 2007 15:02:52 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l32M2qNR027624; Mon, 2 Apr 2007 15:02:52 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l32M2hML006421; Mon, 2 Apr 2007 22:02:48 GMT Received: from xmb-sjc-22d.amer.cisco.com ([128.107.191.68]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 15:02:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Policy Attribute Type (split from [Nea] Comments on -01re:nomenclature) Date: Mon, 2 Apr 2007 15:02:42 -0700 Message-ID: <618694EF0B657246A4D55A97E38274C303419CF4@xmb-sjc-22d.amer.cisco.com> In-Reply-To: <5A58F967CBEBBB4A82DF126CF8A9596A028C99F2@SVL1XCHCLUPIN02.enterprise.veritas.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Policy Attribute Type (split from [Nea] Comments on -01re:nomenclature) Thread-Index: AcdyyhyJ0mz9RermQpmP37hKdx3dtAAGI8SwAJzv92A= From: "Kaushik Narayan \(kaushik\)" To: "Paul Sangster" , "Alan DeKok" X-OriginalArrivalTime: 02 Apr 2007 22:02:44.0558 (UTC) FILETIME=[A43DBEE0:01C77572] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4791; t=1175551372; x=1176415372; 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=20Policy=20Attribute=20Type=20(split=20from=20[Nea]=20C omments=20on=20-01re=3Anomenclature) |Sender:=20; bh=R5guyeDir5+AOEH+RPq1hBnw/7lx3W8EeQtgUhf7eCY=; b=WOudP227BSL4aXY8c7rbxiInOaWrZgEyvcmif6YJzYQEhiQbrC0kehKwy5XopTRIgZgSQhrA RHI3NM5EI0Ls75zGfZ17AQe3b/iLmBW9zoSaMT2+NJ3u/jjEeKVsb+aj; 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: b132cb3ed2d4be2017585bf6859e1ede Cc: nea@ietf.org X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Hi All, I am not sure that this thread was summarized but I think atleast those who responded to this thread feel that we should have a model wherein the NEA client is always instructed by the NEA server about the information (attributes) it is required to provide. The only optimization that was suggested was where the NEA server can pass an expected value and the client can assert instead of passing back the specific value.=20 I think as a design team we tried to use the attribute classes to describe the existing implementation models, i.e. NEA client centric (policy attributes & compliance claim attributes), NEA server centric (request, posture & result attributes) & assertions. The suggestion is to stay away from such specificity and at the PA layer define a flat attribute space similar to say RADIUS/Diameter. We could further attempt to simplify the model by describing the protocol between each individual collector and validator as a generic challenge/response utilizing a set of attributes and the each validator determines the posture decision at the end of this exchange.=20 I just want to confirm with responders on this thread that this summary is accurate and would request other members of the WG to respond in case they have differing views. regards, kaushik =20 -----Original Message----- From: Paul Sangster [mailto:Paul_Sangster@symantec.com]=20 Sent: Friday, March 30, 2007 9:08 AM To: Alan DeKok Cc: nea@ietf.org Subject: RE: Policy Attribute Type (split from [Nea] Comments on -01re:nomenclature) =20 > -----Original Message----- > From: Alan DeKok [mailto:aland@deployingradius.com] > Sent: Friday, March 30, 2007 5:49 AM > To: Frank Yeh Jr > Cc: nea@ietf.org; Paul Hoffman > Subject: Re: Policy Attribute Type (split from [Nea] Comments on -01=20 > re:nomenclature) >=20 > Frank Yeh Jr wrote: > > IMHO there is no need for the server to inform the client > of what it > > "MUST" do. The client can simply report what it is doing and the=20 > > server can compare that against what it thinks the client > must do, and > > make the admission decision on the server. >=20 > What information is the client supposed to report to the server? =20 > The extremes range from nearly nothing (IP / MAC / hostname), to=20 > sending its complete disk image. >=20 > i.e. There has to be some method of bootstrapping the clients=20 > knowledge of what the server cares about. The server could ask the client for component information it cares about (using attributes of the Request Attribute Type.) >=20 > That information can be exchanged as part of NEA, or bootstrapped=20 > via some offline method. Yes, the group could decide to support a model where in effect the request attributes are pre-provisioned on the endpoint or we could just say the server requests what it needs each time. >=20 > > Giving the client granular descriptions of what states must > be met to > > attain access is a rather large security hole IMHO. >=20 > But the client already has that information. Anti-virus software=20 > includes lists of "bad" content. The client I presume your refering to the AV product specific policy defs which define "signatures" the AV uses to recognize "bad" content. Not sure this is useful for anything outside the AV product. > therefore knows that it must pretend to not have any of that "bad"=20 > content before gaining access. I think his point was not wanting to trust the client to manage (keep up to date), protect and properly report compliance to an enterprise's policy. This adds more complexity to the NEA Client which increases the likelihood for bugs, vulnerabilities, ... Also, not sending to the client requests including both: "what is the version of the XYZ component" and "i'm looking for an answer of 1.0" which makes it trivial to write a non-cooperating NEA Client that just repeats the desired answers instead of reporting its current posture information. If we stay out of expressing the expected result (compliance policy) then we can avoid the complexity of policy expression and how we make that interoperable. This seems helpful but at the cost of always sending posture information across the network (unless a prior assertion can be re-used which is a different usage model.) >=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 _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Fri Apr 06 09:34:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZoZj-0003rA-Oo; Fri, 06 Apr 2007 09:33:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZoZi-0003qT-8G for nea@ietf.org; Fri, 06 Apr 2007 09:33:58 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZoZg-0007FF-VE for nea@ietf.org; Fri, 06 Apr 2007 09:33:58 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 06 Apr 2007 09:33:57 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l36DXumu020563; Fri, 6 Apr 2007 09:33:56 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l36DXuGd000854; Fri, 6 Apr 2007 13:33:56 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Apr 2007 09:33:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Apr 2007 09:33:54 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revised NEA milestone dates for final review Thread-Index: Acd4UDhe+eseEgpzQ5i0bj2W9ZA1/A== From: "Susan Thomson \(sethomso\)" To: X-OriginalArrivalTime: 06 Apr 2007 13:33:56.0086 (UTC) FILETIME=[39819960:01C77850] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1398; t=1175866436; x=1176730436; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sethomso@cisco.com; z=From:=20=22Susan=20Thomson=20\(sethomso\)=22=20 |Subject:=20Revised=20NEA=20milestone=20dates=20for=20final=20review |Sender:=20 |To:=20; bh=xBiuOJ632cjGtuobnfu2RrebnomWKIxcF5eRwGjJO0M=; b=IB11lP1eaqM1xUmfiuJkMUpt8xLWRc99Jfaw9M/DQzkNoByQaqGyYPBsbN1R2kgIwBsRfyN0 HFgoupwZh1+LwdYmo/gNYIA6WUz7tWodvD2vWX45wAu0upu26Pi1LxQw; Authentication-Results: rtp-dkim-2; header.From=sethomso@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Subject: [Nea] Revised NEA milestone dates for final review X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Below is a revised set of milestones that were reviewed at the meeting in Prague. A hum was taken demonstrating support for these changes in the WG meeting. Please review these proposed milestones and provide feedback to the mailing list by April 12, 2007. Even if you think the milestones are OK, please send an email so that WG consensus can be judged. Once consensus is achieved, the milestone revisions will be submitted to our AD so that the charter can be updated. As mentioned before, to meet these milestones, we will need to step up the pace of comments on the requirements draft over the next couple of months. We encourage those in the working group who have not provided feedback yet to review the draft as soon as possible.=20 Thanks Susan & Steve Done At IETF 67, discuss NEA Requirements=20 Done Submit first draft of NEA Requirements I-D=20 Done Submit revised NEA requirements I-D=20 Done At IETF 68, discuss open issues with requirements I-D =20 Apr 2007 Submit revised NEA requirements I-D May 2007 Discuss NEA Requirements I-D Jun 2007 Submit revised NEA requirements I-D=20 Jun 2007 WGLC on NEA requirements I-D Jul 2007 At IETF 69, resolve any remaining issues raised at Last Call Aug 2007 Submit revised NEA requirements I-D Aug 2007 Submit NEA Requirements I-D to the IESG for IETF Last Call as Informational RFC _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Sun Apr 29 16:45:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiGGx-0000ju-UY; Sun, 29 Apr 2007 16:45:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiGGw-0000jT-Pq for nea@ietf.org; Sun, 29 Apr 2007 16:45:30 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiGGw-0000Ui-4a for nea@ietf.org; Sun, 29 Apr 2007 16:45:30 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 29 Apr 2007 16:45:30 -0400 X-IronPort-AV: i="4.14,467,1170651600"; d="scan'208"; a="119832148:sNHT72184516" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3TKjTp7030911 for ; Sun, 29 Apr 2007 16:45:29 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3TKjTlI001973 for ; Sun, 29 Apr 2007 20:45:29 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 29 Apr 2007 16:45:29 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 29 Apr 2007 16:45:26 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NEA WG meeting minutes at IETF 68 Thread-Index: AceKn1Dup2Pd24ddShWf6+ydCySvZg== From: "Susan Thomson \(sethomso\)" To: X-OriginalArrivalTime: 29 Apr 2007 20:45:29.0657 (UTC) FILETIME=[52C73A90:01C78A9F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=13973; t=1177879529; x=1178743529; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sethomso@cisco.com; z=From:=20=22Susan=20Thomson=20\(sethomso\)=22=20 |Subject:=20NEA=20WG=20meeting=20minutes=20at=20IETF=2068 |Sender:=20 |To:=20; bh=E2GVgyap02GjZxJ3pGr65eszmIgitiHUUJ39SIJLIPg=; b=i97+FE6lFzvw7CBrAGuRjBClvjEvdySXXWOpprMa5idyKhLrWVPMECQ3miubJc/6VpJsz/bH xAtOnGSIvqSMnVE+a8v66rV82jkKFgJuayu9gv1GO6GrsvTpzZVHecGq; Authentication-Results: rtp-dkim-1; header.From=sethomso@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 731ea0e9f5725b67e634db1918f3b951 Subject: [Nea] NEA WG meeting minutes at IETF 68 X-BeenThere: nea@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Network Endpoint Assessment discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: nea-bounces@ietf.org Below are minutes of NEA WG meeting at IETF meeting in Prague. Let me = know of any corrections by Friday, May 4. Thanks Susan --------------------------------- Minutes from NEA WG Meeting IETF 68 in Prague, Czech Republic March 20, 2007, 1.00 PM - 3.00 PM Chaired by Steve Hanna and Susan Thomson Notes taken by Mani Mahalingam and Mauricio Sanchez =20 These notes do not attempt to duplicate all the material in the slides. Instead, they provide a brief summary of that material and focus on comments and discussion. =20 The following draft agenda was agreed to: =20 1:00 Preliminaries 1:05 WG Status 1:10 Proposed Milestone Revisions 1:25 Discuss NEA Requirements draft 2:40 FWNA, Eduroam, and NEA 2:55 Next Steps 3:00 Adjourn * WG Status * Steve reviewed WG status. Two revisions of NEA requirements=20 draft have been posted since IETF 67. Steve asked how many had read either the -00 or -01 of the draft. A significant number of=20 people raised their hand. * Proposed Milestone Revisions * Steve reviewed the updated milestones, a previous version of=20 which had been distributed on the mailing list. He asked for a=20 hum to determine support for the revisions. The hum demonstrated=20 significant support for the revisions. There were no objections. The=20 milestones will be confirmed on the mailing list before sending to the=20 area director. * NEA Requirements I-D * Paul Sangster reviewed the -01 version of the NEA requirements I-D.=20 He covered the following topics in the presentation in the meeting=20 (please refer to the slides): --- Reference Model --- Attribute Types & Use Case examples --- Open Issues=20 =20 Reference Model: Paul reviewed the reference model agreed to at the IETF67 meeting.=20 Steve asked whether there are any people in the room who do not=20 understand what problem the NEA WG is trying to solve. Nobody=20 raised their hand. Attribute Types and Use Cases: Paul presented three usage scenarios for NEA as the motivation=20 for defining different attribute classes:=20 (1) request/response for posture information=20 (2) request for compliance to a given policy=20 (3) allow for re-use of assertions from prior assessments.=20 The requirements draft currently defines different types of=20 attributes to meet these usage scenarios. A NEA server may=20 send 4 attribute types: request attributes, policy attributes,=20 result attributes and remediation attributes. A NEA client may=20 send posture attributes, compliance claim attributes and=20 assertion attributes. The requirements draft contains 5 use cases which are intended=20 to illustrate usage of different attribute types. Paul presented=20 the 5 use cases defined thus far. Yaron Sheffer: The draft has classified many attributes, but=20 it does not specify the semantic power of attributes. Are=20 attributes similar to RADIUS attributes? Are they collections of=20 attributes, rule-sets for policies, etc? It could become very=20 complex. Paul: The WG needs to specify the attributes in more detail=20 in the protocol specs after completing the requirements document.=20 The attributes may be more sophisticated than RADIUS attributes,=20 because they may contain references to policies, for example. Yaron: A clearer description of attributes is preferred. Specify=20 something more than "what attributes can do", but less than=20 "what attributes can look like". Paul: This is a valid comment. For further discussion on mailing=20 list. Alan de Kok: Not clear that all these attribute types are necessary.=20 For example, the compliance claim attribute. =20 Paul: The intent is to support the models previously described.=20 Alan: No one knows how to transport policies well in protocol.=20 Suggest not even try. Why would an administrator tell the client=20 what the policies are since the administrator does not trust the client? = Paul: The policy could be in the form of a URI or just some name,=20 or some minimal indication of where the policies are. =20 Alan: How is asking for the version of AV different from asking=20 for compliance to a specific policy?=20 Steve: There was discussion on the mailing list that it was important=20 that allowance be made for privacy-sensitive clients; hence the=20 current attribute in the draft. We can take this requirements=20 back to the mailing list to reconfirm. Paul: This is another issue that should be discussed further on=20 the list.=20 Alan: Why does the draft identify 3 different protocols?=20 There is a need for one protocol with layers of proxying.=20 Paul: It seems that the draft is saying the same thing, just=20 using different words. Leif Johannsen: The requirements I-D should explicitly state=20 whether there is a need for a schema, or not. If so, do not=20 invent a new one.=20 Paul: The requirements draft does say that existing standards=20 should be used where applicable. This comment is a similar one =20 to the comment made earlier on attribute type definitions.=20 This is another topic to be taken to the list. Chairs: All WG participants are encouraged to send their comments=20 to the alias. Do not make the editorial team the bottleneck for=20 raising issues on the list for resolution. Hannes Tschofenig: The draft includes a problem statement, use cases,=20 architecture,trust-model as well as requirements. This was surprising=20 given the document title. These topics are useful to have described,=20 but at least change the title of the document. Also, the WG should=20 have a chance to see some of the design team's discussions.=20 Harald Alvestrand: Since the use of the term protocols for the three=20 layers seems to be causing confusion, at least make the layering=20 explicit. The term "prove" is asking for trouble. Another term should=20 be used. Open Issues: Virtualization:=20 Should virtualization be explicitly supported? This topic is not=20 discussed in the current requirements draft.=A0 Three options presented: = no change (ignored), say it's out of scope, or be more explicit about=20 virtualization models and how NEA supports it . Alan de Kok: There should be a discussion on virtualization. The=20 hypervisor is just a proxy to virtual clients.=A0 There is no need=20 for a change in the model. Paul Sangster: There are many virtualization models. One would=20 not expect the NEA client to be part of virtualization layer.=20 Paul asks whether hypervisor should be actively involved in=20 NEA process, or just act as a pass-through.=20 Alan: Depends on whether the endpoint appears to network as=20 one machine or as N machines. Tim Chown: What is the client identifier used to distinguish=20 virtual machines? Need to identify these issues in the draft and=20 specify explicitly that out of scope, not just ignore. Paul Hoffman: Virtualization is analogous to a NAT box which=20 has multiple endpoints behind it. To NEA server, it looks like=20 a single endpoint. Thus, no change in model. NEA client on non-endpoint: Should the draft recognize a device that acts as a NEA client=20 for the endpoints behind it that do not have an NEA client?=20 The device may be an intrusion detection system or intrusion protection=20 system, for example. Alan de Kok: May be useful to talk about the specific case of NAT=20 or FW acting on behalf of the endpoints they allow into the network.=20 Mauricio Sanchez: Does this use case imply any changes to the protocol=20 requirements?=20 Paul: No changes foreseen to the requirements themselves. It changes=20 some of the normative text. Mauricio Sanchez: It is better to focus on use cases that impact the=20 requirements.=20 Tim Chown: It would be useful to have some discussion on how the=20 communication between IDS, NEA server and firewall works and how=20 these devices get configured in this use case, but agree=20 do not want to be too distracted by this. Is it possible to have=20 multiple NEA servers in a domain? =20 Paul Sangster: Yes, there could be multiple NEA servers Steve: How the NEA server communicates with an enforcement point=20 is explicitly out of scope per the charter. Bob Morgan: This should be a supported option in the model.=20 It does have an impact on protocol requirements because the protocol=20 needs to ask about endpoint X even though talking to client Y. Paul Sangster: NEA server does create awkwardness in model, and=20 agrees it will add attributes to the protocol requirements. Steve: Our AD needs to assess if this use case is within the=20 scope of the charter.=20 Tim Polk: The WG should continue to discuss the use case to=20 better understand if this scenario falls within the scope of an=20 endpoint as used in the charter. Depending on the=20 outcome of this investigation, we may have to slate this for future = work. Alan: NEA use cases need to take into account enforcement.=20 Steve: Enforcement is present in the model but out of scope for WG. Tim Polk: The charter states that enforcement is not mandatory.=20 Paul Hoffman: Suggests that we ignore this use case. It could be=20 an extension of the existing reference model. Security at all layers: The requirements document currently specifies authentication,=20 confidentiality and integrity requirements for all 3 layers.=20 Requirements for PA & PT are currently listed as a MUST,=20 while PB is a SHOULD. These requirements are intended to cater for=20 cases where all client or server components may not be co-resident.=20 Steve: Alternately, NEA could use hop-hop protection with remote=20 validators on the NEA server. Paul: Yes. However, this does not support authentication of a=20 posture collector to a posture validator or vice versa Hao Zhou: Why is there a need for protection on PA layer? Its possible=20 for components at this layer to define their own since they typically=20 come from the same vendor. Paul: Possible to do vendor-specific security, but the advantage is that = there is a standard one that allows for interoperability. Paul: PB security is expected to be needed least as PT and PB=20 components typically are co-resident. Mauricio Sanchez: Proposes making PB a MAY. Privacy considerations (Section 9.2 ) Paul said that intent of the current text in Section 9.2 is to be=20 a starting point for discussion. The text was motivated by an earlier=20 thread on the mailing list regarding privacy concerns with use of NEA.=20 Paul described that, for privacy reasons, a client may have a policy=20 regarding what information to disclose. Possible models are: --- Client sends all attributes by default=20 --- Client has local policy regarding what attributes to send --- Client can respond to requests based on local policy. Server can=20 iteratively request attributes (factoring in responses to previous=20 requests). Richard Graveman: How do I know if a NEA server is legitimate? Paul: Through strong authentication of the NEA server. Trust=20 anchors are pre-configured. Paul Hoffman: We just got into a policy rat-hole. One side should=20 pick policy. The expectation is that this would be the server.=20 If server asks for posture attributes, the client either responds or = not.=20 This is an option with any protocol. Need not specify in the = requirements=20 draft.=20 Yaron: I think there should be some discussion in the draft, probably=20 in an appendix in reduced form as implementation advice. The 3rd policy=20 option mentioned in the draft is overkill, however. The client need=20 not disclose information at the risk of not being allowed=20 onto network. Hannes: There are more complex privacy considerations in the roaming=20 scenario, where there is a difference between the access network=20 and home network.=20 Steve: The roaming use case is explicitly excluded from the charter=20 and is out of scope. Other issues on current draft? Paul Hoffman: The requirements document currently lacks discussion=20 of how remediation works and what happens afterwards.=A0 For example,=20 an endpoint may be given restricted access for the purposes of=20 remediation after which posture may need to be revalidated. Paul: Remediation is out of scope of the charter.=20 Paul, others: The draft needs to describe that remediation could happen, = not=20 how it happens. Tim Chown: Should specify the quarantine phase in an example=20 (while not describing quarantine enforcement itself)=20 Leif Johansson (FWNA/EDUROAM):=20 There was a short presentation on use of federated 802.1x in=20 FWNA/eduroam deployments, and how it may be impacted by NEA.=20 In these deployments, the network provider (foreign provider) and=20 the identity provider (home provider) are different organizations=20 when a host roams. If the same model is used when performing posture=20 assessment, some method of communication is needed between the network=20 and posture provider.=20 While it is clear that support for such networks is outside the=20 current NEA charter, the presenters' intent was to raise awareness of=20 potential issues in an attempt to avoid problems with supporting=20 such deployments in the future.=20 Several proposals for resolving the issues without affecting NEA were=20 suggested including (1) proxying (2) providing foreign network provider=20 with a reference to the posture results and (3) separating = authentication=20 and posture assessment. Wrap-up: Steve discussed the next steps: --- Confirm revised milestones on mailing list --- Discuss open issues on mailing list --- Revise NEA requirements I-D=20 --- Further discussion on list=20 --- Revise NEA requirements I-D based on discussions --- WGLC in June _______________________________________________ Nea mailing list Nea@ietf.org https://www1.ietf.org/mailman/listinfo/nea From nea-bounces@ietf.org Mon Apr 30 19:06:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiexJ-0002NP-VY; Mon, 30 Apr 2007 19:06:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiexJ-0002NK-EB for nea@ietf.org; Mon, 30 Apr 2007 19:06:53 -0400 Received: from extu-mxob-1.symantec.com ([216.10.194.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiexH-0006M3-QI for nea@ietf.org; Mon, 30 Apr 2007 19:06:53 -0400 Received: from tus1opsmtapin01.ges.symantec.com ([192.168.214.43]) by extu-mxob-1.symantec.com with esmtp (Exim 4.66) (envelope-from ) id 1HiexH-0003NH-0F for nea@ietf.org; Mon, 30 Apr 2007 16:06:51 -0700 Received: from ussv-exch.relay.symantec.com ([10.137.18.172] helo=SVLXCHCON2.enterprise.veritas.com) by tus1opsmtapin01.ges.symantec.com with esmtp (Exim 4.52) id 1HiexG-0003hN-Pg for nea@ietf.org; Mon, 30 Apr 2007 16:06:50 -0700 Received: from TUS1XCHECNPIN01.enterprise.veritas.com ([155.64.230.18]) by SVLXCHCON2.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 30 Apr 2007 16:06:50 -0700 Received: from TUS1XCHEVSPIN05.enterprise.veritas.com ([155.64.231.27]) by TUS1XCHECNPIN01.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 30 Apr 2007 16:06:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 30 Apr 2007 16:06:49 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: NEA Overview and Requirements I-D -02 submitted Thread-Index: AceLfDub3QGJ0jdOSFSvLuoTLDJ6Mw== From: "Paul Sangster" To: X-OriginalArrivalTime: 30 Apr 2007 23:06:49.0516 (UTC) FILETIME=[3B94C6C0:01C78B7C] X-Brightmail-Verdict: VlJEQwAAAAIAAAABAAAAAAAAAAEAAAAAAAAAAWluYm94AG5lYUBpZXRmLm9yZwA= X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f Subject: [Nea] NEA Overview and Requirements I-D -02 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="===============0845036600==" Errors-To: nea-bounces@ietf.org This is a multi-part message in MIME format. --===============0845036600== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C78B7C.3BC1B07E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C78B7C.3BC1B07E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just a heads up that consistent with our revised schedule, we have submitted a revised version of the NEA Requirements I-D to the IETF for publication. Hopefully this version will be published later this week. We welcome feedback and discussion on all parts of this document as we move closer towards WG last call. =20 Most of the changes were based on feedback we receive in Prague and/or via the mailing list. We certainly encourage everyone who wasn't able to attend the meeting to review the minutes and listen to the audio recording ( http://limestone.uoregon.edu/ftp/pub/videolab/media/ietf68/ietf68-ch1-tu e-noon.mp3 ) =20 The primary changes made to the -02 version include: * Removal of policy and compliance claim attribute types * Removal of use case/example highlighting policy/claim attribute type exchange o Mention of quarantining during remediation o Broadened title since covers more than requirements o Change PB cryptographic protection requirements to MAY (from SHOULD) o Describe scope of posture sent by NEA Client based on operation domain o Less emphasis on attribute types more on types of messages - Removed mention of attribute types from example flows to ease readibility o Addressed comments from several e-mail threads (e.g. Mauricio, Nancy) o Removed mention of 3rd party providing posture for clientless endpoints o Replaced capitalization of terminology based upon commonly used words o Explained 3 layered protocol model based on message enveloping over PT =20 * - These items were the largest changes to the I-D. If WG members believe we must call out these types of attribute messages please explain to alias so we can gauge consensus. =20 Paul ------_=_NextPart_001_01C78B7C.3BC1B07E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Just a = heads up that=20 consistent with our revised schedule, we have submitted a revised = version of the=20 NEA Requirements I-D to the IETF for publication.  Hopefully this = version=20 will be published later this week.  We welcome feedback and = discussion on=20 all parts of this document as we move closer towards WG last=20 call.
 
Most = of the changes=20 were based on feedback we receive in Prague and/or via the mailing = list. =20 We certainly encourage everyone who wasn't able to attend the meeting to = review=20 the minutes and listen to the audio recording ( http://limestone.uoregon.edu/ftp/pub/videolab/media/ie= tf68/ietf68-ch1-tue-noon.mp3 )
 
The = primary changes=20 made to the -02 version include:
  = * Removal of=20 policy and compliance claim attribute types
  = * Removal of=20 use case/example highlighting policy/claim attribute type=20 exchange
  = o Mention of=20 quarantining during remediation
  = o Broadened=20 title since covers more than requirements
  o Change=20 PB cryptographic protection requirements to MAY (from=20 SHOULD)
  = o Describe=20 scope of posture sent by NEA Client based on operation=20 domain
  = o Less=20 emphasis on attribute types more on types of = messages
     - Removed mention of = attribute=20 types from example flows to ease readibility
  = o Addressed=20 comments from several e-mail threads (e.g. Mauricio, = Nancy)
  = o Removed=20 mention of 3rd party providing posture for clientless=20 endpoints
  = o Replaced=20 capitalization of terminology based upon commonly used = words
  = o Explained 3=20 layered protocol model based on message enveloping over = PT
 
* - = These items were=20 the largest changes to the I-D.  If WG members believe we must call = out=20 these types of attribute messages please explain to alias so we can = gauge=20 consensus.
 
Paul
------_=_NextPart_001_01C78B7C.3BC1B07E-- --===============0845036600== 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 --===============0845036600==--