|
RE: [Nea] WG Review: Network Endpoint Assessment (nea)
2006-10-06 13:51:37
Hi Susan,
Please see inline.
-----Original Message-----
From: Susan Thomson (sethomso) [mailto:sethomso(_at_)cisco(_dot_)com]
Sent: Thursday, October 05, 2006 12:22 PM
To: Narayanan, Vidya
Cc: nea(_at_)ietf(_dot_)org; iesg(_at_)ietf(_dot_)org;
ietf(_at_)ietf(_dot_)org
Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea)
Hi Vidya
Thanks for your comments.
Inline ...
-----Original Message-----
From: Narayanan, Vidya [mailto:vidyan(_at_)qualcomm(_dot_)com]
Sent: Wednesday, October 04, 2006 12:48 PM
To: iesg(_at_)ietf(_dot_)org
Cc: nea(_at_)ietf(_dot_)org
Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea)
All,
Comments on the charter inline below.
-----Original Message-----
From: IESG Secretary [mailto:iesg-secretary(_at_)ietf(_dot_)org]
Sent: Monday, October 02, 2006 7:30 AM
To: ietf-announce(_at_)ietf(_dot_)org
Cc: nea(_at_)ietf(_dot_)org
Subject: [Nea] 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 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.
Is it fair to then say that NEA is attempting to protect
the endhost
and not necessarily the network?
Yes, this is the focus.
That is not immediately clear in the
charter. Obviously, the network must deal with all kinds of
known and
unknown threats and a process like NEA is inadequate to
protect it at
any acceptable level. That is why we employ a number of other
mechanisms like firewalls, access control, packet filters, IDS/IPS,
etc. in any combination to appropriately protect the networks.
So, stating that NEA is not attempting to protect the
network at large
would bring a lot of clarity to the charter.
Since we have been around the block a few times on this
section, could you suggest precise text that you would like
to see to make this clearer?
How about adding this text - "It should be noted that the networks at
large are exposed to attacks from lying endpoints and external entities
attaching to the networks as well as any problems arising from unknown
vulnerabilities on NEA compliant endpoints. Hence, NEA must not be
considered a protection mechanism for networks. Further, mechanisms
needed to protect the network from all kinds of vulnerabilities are
expected to be a superset of any protection that may be achieved by
employing 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.
It is unclear how the advisory vs mandatory model relates
to the NEA
procedures itself. NEA is attempting to provide a vehicle
to perform
some compliance tests on acceptable "postures". What the network
decides to do with that information seems entirely dependent on the
policy of the network and the extent of non-compliance,
etc. What does
it mean to say that NEA *allows* an advisory and/or a
mandatory model?
Yes, it is a matter of policy. We have had other input as
well that indicates this text is causing confusion. We added
this text in consultation with our AD to re-inforce the
notion that NEA did not necessarily imply enforcement, and
that things like emergency services could be made available
regardless of the outcome of posture assessment.
The intention is not to be prescriptive about an
organization's policy in any way.
Bearing the original motivation in mind, would the following
work better?
"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. For example, potential
deployment scenarios may include,but are not limited to,
providing normal access regardless of compliance with
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").
I'm not sure that the charter actually needs to get into the modes at
all - I'm guessing what happens after NEA (i.e., what is done with the
results from NEA) has zero impact on any work being done in NEA itself.
So, why not simply state something like "Once NEA is conducted on an
endpoint, the results may be used by an organization in accordance with
any policies of the organization itself."?
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.
Again, what does it mean to be queried in a particular mode?
Based on consensus re the above, reference to the "modes" may
be able to be dropped.
Since NEA involves many different components from
different vendors,
interoperation
s/interoperation/interoperability
OK.
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.
This seems like an optimistic goal. Given that only a subset of
attributes are envisioned to be standardized and given that
the kind
of attributes are likely to be ever increasing, considering that
posture refers to hardware/software configuration of an endpoint, I
fail to see how we would practically get NEA clients and
NEA servers
from different vendors to perform any meaningful NEA procedures. In
theory, I can see how this can be slated to be a goal -
but, I have to
believe that reality would be different.
This was discussed at last BOF, and resolution was to require
that vendor-specific attributes be documented in a RFC.
Its also possible that components of a client and components
of a server are provided by same or different vendors, i.e.
interoperability is not necessarily an all or nothing proposition.
I realize that. I guess some people are convinced that the subset
standardized will be sufficient for some meaningful interoperability. I
will have to wait to see the interoperable deployments to be convinced
of that :)
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.
I assume that the mandatory to implement PT protocol must
satisfy the
criteria that will allow the NEA process to be triggered at
any time
(i.e., during or after network access). Clarifying this
would be good.
There is text in a few paragraphs above that says "on network
access and while connected, an endpoint supporting NEA
protocols can be queried for such posture information". Is
this not sufficient?
That is not necessarily putting any requirements in the choice of the
mandatory to implement protocol itself, as I see it. I believe that
stating something like "The mandatory to implement PT protocol must be
generic enough to allow the execution of the NEA procedure without
forcing the need to re-execute network access procedures".
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.
This goes back to my comment on interoperability. Unless it is
expected that there will be ongoing efforts to continually
standardize
attributes of significance to the community as the
hardware/software
configurations of devices evolve, I am afraid that we won't have
interoperability of any significance.
Ongoing standardization of attributes can be done as necessary.
This, to me, indicates that this is a WG that may never actually close
:) Again, I'll have to wait for deployments to convince myself!
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 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.
I'm not sure what the last sentence means here - everything in this
paragraph alludes to the fact that lying endpoints are out
of scope.
If the last sentence is alluding to the TCG efforts, why is it
cryptic? As currently stated, it doesn't seem to add any
value. If we
say that in order for NEA to have a meaningful use case, it
must work
together with some of the TCG stuff, then, perhaps that is
effort that
the WG must ensure gets done.
The last sentence was added as a result of the consensus
reached at the last BOF. The intent is to make sure that NEA
is compatible with emerging technologies to address "lying
endpoints" so that they can be used together if a user
chooses to do so.
TCG is one example that could place requirements on NEA to
ensure compatibility, but need not be the only one. My
understanding (although I am no expert) is that requirements
include providing a multi-round sequenced message exchange
with authentication of the server, confidentiality, and
integrity protection. Such requirements are not expected to
be onerous.
I guess the text leaves it so open-ended that it fails to add any value.
Unless we know what technologies NEA must be able to work with, how can
the protocols be designed to work with those technologies? I am
completely missing the point of this text.
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. 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.
Why is this an open issue? When the endpoint and the organization
providing network access are owned by different parties, it simply
does not seem to be viable to do any kind of configuration
assessment
on the endpoint. I think this should be stated rather clearly along
these
lines:
"NEA is limited in applicability to the case where the endpoint is
owned by the organization providing network access and
performing the
assessment. In the cases where the two belong to a
different party, it
is practically infeasible for an organization providing
network access
to perform any kind of posture assessment or related
compliance tests
on the endpoint."
The reason we left it open is to allow the working group to spend more
time exploring the range of use cases in this area to better determine
requirements and applicability. For example, it may be useful to
classify endpoints as network-managed versus user-managed versus
3rd-party managed. A user-managed endpoint may want the
choice to opt in
or opt out, say.
Not only do I not see anything in the charter or milestones that
indicates that the WG is going to spend time exploring this, I strongly
believe this WG should not be spending any time looking at this. The
trust models for the cases where the devices are not owned by the
organization performing NEA are hugely different and can take up its own
WG to actually find something that applies there, if at all. For one,
this could be considered a violation of privacy by the user of the
device. Secondly, the end user's perspective of attacks may be entirely
different from the organization's perspective in this case. Third, I
simply can't see what the organization's interests would be in
protecting a device that doesn't even belong to it. Last but not the
least, this requires the endpoint to be running an NEA client (that is
interoperable with the NEA server of the organization) - which in itself
is often an unrealistic requirement.
Organizations that provide services in their networks to end users are
worried about protecting their resources (i.e., networks, servers,
etc.). As we have agreed, NEA does not protect such resources anyway.
Plus, there is absolutely no reason such organizations should believe
that devices they don't own are in fact, truthful endpoints.
So, thinking that this WG must be looking into resolving this seems
flawed at several levels. In the interest of having a focused WG that
can get something useful accomplished, this does not make sense.
Thanks,
Vidya
Thanks
Susan
Thanks,
Vidya
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
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 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
February 2007:
* Submit NEA Requirements I-D and Evaluation I-D to IESG
as Info RFC
* Submit first draft of PA and PB specs for review
March 2007:
* Discuss unresolved issues with PA and PB specs at IETF 68
* Agree on solutions to unresolved issues with PA and PB specs
April 2007:
* Submit revised draft of PA and PB specs
June 2007
* WG Last Call on PA and PB specs
July 2007
* Resolve outstanding WGLC comments on PA and PB specs at IETF 69
August 2007:
* Submit PA and PB specs to IESG for publication as Proposed
September 2007:
* Decide how to address MTI PT, recharter if needed
_______________________________________________
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
|
|