RE: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)

Hi Vidya

Inline ...

-----Original Message-----
From: Narayanan, Vidya [mailto:vidyan(_at_)qualcomm(_dot_)com] 
Sent: Tuesday, October 24, 2006 2:15 AM
To: iesg(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
Cc: nea(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org] 
Sent: Tuesday, October 17, 2006 12:50 PM
To: ietf-announce(_at_)ietf(_dot_)org
Cc: nea(_at_)ietf(_dot_)org
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(_at_)ietf(_dot_)org) by October 23rd.

+++

Network Endpoint Assessment (nea)
===================================

Current Status: Proposed Working Group

Chair(s): 
TBD

Security Area Director(s):
Russ Housley <housley(_at_)vigilsec(_dot_)com>
Sam Hartman <hartmans-ietf(_at_)mit(_dot_)edu>

Security Area Advisor:
Russ Housley <housley(_at_)vigilsec(_dot_)com>

Mailing List: nea(_at_)ietf(_dot_)org

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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/nea


_______________________________________________
Nea mailing list
Nea(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/nea


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf