It appears that there was consensus to form a NEA working group at
the last BoF meeting. Given that, I won't object to a WG being
formed, but the charter needs to be more tightly scoped. I have
asked for an applicability statement to be put on this work at the
IETF. I will try and provide draft text to that end.
At 07:40 AM 10/2/2006, IESG Secretary wrote:
A new IETF working group has been proposed in the Security Area.
The IESG has not made any determination as yet. The following 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 9.
+++
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.
How does NEA facilitate corrective action? Isn't corrective action
out of scope for NEA?
Two deployment scenarios will be supported: advisory mode and mandatory
mode.
In advisory mode, an endpoint may be advised of the result of posture
assessment
and any recommended remediation actions, but is provided normal network
access
regardless of the result. In mandatory mode, a non-compliant endpoint is
given
restricted access to the network sufficient for remediation purposes
and any essential
services or denied access completely.
I suggest deleting the text about advisory and mandatory
modes. Instead let us state that after assessment is complete,
corrective action such as it is, is up to the organization's policy.
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 in either advisory or mandatory
modes.
It is not clear how this is feasible. Tying this to network access
is not universally applicable (for instance, in cases where the
endpoints are not owned by the organization performing the
assessment; Vidya and others have pointed this out at various times
on the NEA list and elsewhere), and it is not clear what the
transport protocol is for assessment while connected. I realize that
the transport protocol is out of scope for NEA WG, but curious what
other than EAP is on the table for this purpose.
Since NEA involves many different components from different vendors,
interoperation is highly desirable. The priority of the NEA working
group is to
standardize protocols at the higher layers in the architectures:
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, these new 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 standardization. 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.
PA, the 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. Certain posture attributes
will be standardized to ensure interoperability but vendor-specific
attributes will also be supported. 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 (or stack of protocols) is
suitable for carrying
the PB protocol at the time of network connection, or shortly after.
The phrase "shortly after" is ambiguous. Once again my question is
what is the transport protocol in mind here, one that can be used at
the time of network connection and one that can be used "shortly after."
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.
Actually this goes one step further. How does an NEA system know
whether an endpoint is compromised or not? It does not. So, all
endpoints must be assumed to have been compromised.
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 standardize protocols for remediation.
NEA is intended to be used with new or existing tools that can be used in
the absence of NEA.
This statement is not clear.
There is an open issue with respect to NEA
applicability
in deployment scenarios where the endpoint is owned by a party that
is different
from the organization providing network access.
Instead of this let us write an applicability statement for NEA
work. "NEA is applicable to networks where endpoints accessing the
network are owned and tightly controlled by the organization that
owns and operates the network. In all other cases, NEA and
associated procedures and protocols are ineffective."
Further work in the NEA WG will be considered via the standard
rechartering
process after the completion of these milestones.
Milestones:
June 2006:
* Submit first version of NEA Requirements I-D
July 2006:
* Agree on charter and milestones at IETF 66
I presume the above will be revised.
<snip>
December 2006:
* Deadline for submission of candidate specs for PA and PB
* Submit first version of NEA Evaluation I-D
January 2007:
* WG Last Call on NEA Evaluation I-D
The December and January deadlines seem too tight. Perhaps those can
be revised based on the WG's pace.
<snip>
September 2007:
* Decide how to address MTI PT, recharter if needed
What's MTI?
thanks,
Lakshminath
_______________________________________________
New-work mailing list
New-work(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/new-work
_______________________________________________
secdir mailing list
secdir(_at_)mit(_dot_)edu
https://mailman.mit.edu/mailman/listinfo/secdir
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf