Hi Vidya Inline ... > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@xxxxxxxxxxxx] > Sent: Tuesday, October 24, 2006 2:15 AM > To: iesg@xxxxxxxx; ietf@xxxxxxxx > Cc: nea@xxxxxxxx > Subject: RE: [Nea] UPDATED: WG Review: Network Endpoint > Assessment (nea) > > All, > > This charter is definitely clearer on some of the points that were > discussed based on the last version, but a couple of things > still remain > to be clarified. Based on several discussions that we've had lately, I > have two suggestions for further clarity: > > 1. Let's add the text suggested by Harald and Lakshminath > (there seemed > to be agreement on this text on the list). Quoting the change > proposed: > > Replace: > > "NEA can be limited in its applicability when the endpoint and the > organization providing network access are owned by different parties." > > with > > "NEA is applicable to computing environments of enterprises where > endpoints accessing the enterprise's network are owned and/or expected > to conform to the policies set forth by the organization that owns and > operates the network. All other cases are outside the scope > of the NEA > charter, since we do not know that NEA would be useful in > such cases." > I don't think there is consensus around this text, and I can think of existing deployment scenarios that might be ruled out by this text and also where it might be considered to be too broad. I would rather allow the WG the time to define terminology and discuss criteria that determine applicability, e.g. who owns the endpoint versus who manages the endpoint (these may be different), so that we can do a clearer job articulating this. I don't think we are going to complete this now, and given there is an explicit action in the charter to address applicability, I think this should be good enough. > 2. On the mandatory-to-implement PT protocol, I would like to see the > clarification that the protocol must allow the NEA process to > run either > at the time of network access or while connected. This clarification > seems mainly needed because there is text elsewhere in the > charter about > allowing NEA runs "at network access or while connected" - if > that text > is removed, this clarification won't be required. > I don't think this really matters, but in the interests of closing on this, will remove the text you refer to. Thanks Susan > Thanks, > Vidya > > > -----Original Message----- > > From: IESG Secretary [mailto:iesg-secretary@xxxxxxxx] > > Sent: Tuesday, October 17, 2006 12:50 PM > > To: ietf-announce@xxxxxxxx > > Cc: nea@xxxxxxxx > > Subject: [Nea] UPDATED: WG Review: Network Endpoint > Assessment (nea) > > > > A new IETF working group has been proposed in the Security Area. > > The IESG has not made any determination as yet. The following > > UPDATED draft charter was submitted, and is provided for > > informational purposes only. Please send your comments to the > > IESG mailing list (iesg@xxxxxxxx) by October 23rd. > > > > +++ > > > > Network Endpoint Assessment (nea) > > =================================== > > > > Current Status: Proposed Working Group > > > > Chair(s): > > TBD > > > > Security Area Director(s): > > Russ Housley <housley@xxxxxxxxxxxx> > > Sam Hartman <hartmans-ietf@xxxxxxx> > > > > Security Area Advisor: > > Russ Housley <housley@xxxxxxxxxxxx> > > > > Mailing List: nea@xxxxxxxx > > > > Description of Working Group: > > > > Network Endpoint Assessment (NEA) architectures have been > > implemented in the industry to assess the "posture" of > > endpoint devices for the purposes of monitoring compliance to > > an organization's posture policy and optionally restricting > > access until the endpoint has been updated to satisfy the > > posture requirements. An endpoint that does not comply with > > posture policy may be vulnerable to a number of known threats > > that may exist on the network. The intent of NEA is to > > facilitate corrective actions to address these known > > vulnerabilities before a host is exposed to potential attack. > > Note that an endpoint that is deemed compliant may still be > > vulnerable to unknown threats that may exist on the network. > > The network may thus continue to be exposed to such threats > > as well as the range of other threats not addressed by > > maintaining endpoint compliance. > > > > Posture refers to the hardware or software configuration of > > an endpoint as it pertains to an organization's security > > policy. Posture may include knowledge that software installed > > to protect the machine (e.g. patch management software, > > anti-virus software, host firewall software, host intrusion > > protection software or any custom software) is enabled and > > up-to-date. On network access and while connected, an > > endpoint supporting NEA protocols can be queried for such > > posture information. > > > > An organization may make a range of policy decisions based on > > the posture of an endpoint. NEA is not intended to be > > prescriptive in this regard. Supported deployment scenarios > > will include, but are not limited to, providing normal access > > regardless of compliance result along with any > > recommendations for remediation ("advisory mode"), as well as > > providing restricted access sufficient for remediation > > purposes and any essential services until an endpoint is in > > compliance ("mandatory mode"). > > > > Since NEA involves many different components from different > > vendors, interoperability is important. The priority of the > > NEA working group is to develop standard protocols at the > > higher layers in the > > architecture: the Posture Attribute protocol (PA) and the > > Posture Broker protocol (PB). PA and PB will be designed to > > support a variety of lower layer protocols. When used with > > standards for lower layers, the PA and PB protocols will > > allow interoperability between an NEA Client from one vendor > > and an NEA Server from another. > > > > Since there are already several non-standard protocols at > > these higher layers, the NEA working group will consider > > these existing protocols as candidates for the standard > > protocols. A requirements document will be written and used > > as a basis for evaluating the candidate protocols. The > > working group may decide to standardize one of the candidate > > protocols, use one of them as a basis for a new or revised > > protocol, or decide that a new protocol is needed. > > > > The NEA Requirements document will include a problem > > statement, definition of terms, requirements for the PA and > > PB protocols, and an overall security analysis. It will also > > include generic requirements for the protocol transporting > > PA, PB: the Posture Transport protocol (PT). PT protocols may > > be standardized in other WGs since these protocols may not be > > specific to NEA. The NEA WG will identify one mandatory to > > implement PT protocol to ensure interoperability. > > > > The PA (Posture Attribute) protocol consists of posture > > attributes that are carried between a particular Posture > > Collector in a NEA client and a particular Posture Validator > > in a NEA Server. The PA protocol is carried inside the PB > > protocol. A base set of standard posture attributes will be > > specified. Vendor-specific attributes will also be supported, > > but vendor-specific attributes must be documented in an RFC. > > > > The PB (Posture Broker) protocol aggregates posture > > attributes from one or more Posture Collectors in an NEA > > client and sends them to the NEA server for assessment by one > > or more Posture Validators. > > > > The PT (Posture Transport) protocol carries the PB protocol. > > > > The NEA working group will not specify protocols other than > > PA and PB at this time. The expectation is that an existing > > protocol can be used for the PT. > > > > One commonly discussed issue with NEA systems is how to > > handle compromised endpoints, whose reports of their own > > posture may not be accurate. Detecting or handling such > > endpoints is out of scope of the NEA WG. Work on PA will > > focus on attributes useful for assessing posture of those > > endpoints reporting accurate information. However, the > > protocols developed by the NEA WG must be designed to > > accommodate emerging technologies for identifying and dealing > > with lying endpoints. > > > > Note that NEA is not chartered to develop standard protocols > > for remediation. NEA is intended to be used with new or > > existing tools that can be used in the absence of NEA. NEA > > can be limited in its applicability when the endpoint and the > > organization providing network access are owned by different > > parties. NEA applicability and security considerations will > > be described in the appropriate NEA documents. > > > > Further work in the NEA WG will be considered via the > > rechartering process after the completion of these milestones. > > > > Milestones: > > > > October 2006: > > * Submit first draft of NEA Requirements I-D > > > > November 2006: > > * At IETF 67, discuss issues with NEA Requirements I-D > > * Agree on solutions to issues with NEA Requirements I-D > > > > December 2007: > > * Submit revised requirements I-D > > > > February 2007: > > * WGLC on NEA Requirements I-D > > * Deadline for submission of candidate specs for PA and PB > > > > March 2007: > > * At IETF 68, resolve outstanding issues with requirements I-D > > * Report from NEA protocol evaluation team > > > > April 2007: > > * Submit NEA Evaluation I-D > > > > June 2007: > > * Submit revised NEA Evaluation I-D > > * WGLC on NEA Evaluation I-D > > > > July 2007: > > * At IETF 69, review outstanding comments on evaluation I-D > > > > August 2007: > > * Submit first draft of PA and PB spec > > > > October 2007: > > * Submit revised draft of PA and PB spec > > * Decide how to address MTI PT, recharter if needed > > > > December 2007: > > * At IETF70, discuss and resolve issues with PA and PB spec > > > > February 2008: > > * WGLC on PA and PB spec > > > > _______________________________________________ > > Nea mailing list > > Nea@xxxxxxxx > > https://www1.ietf.org/mailman/listinfo/nea > > > > _______________________________________________ > Nea mailing list > Nea@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/nea > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf