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?
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").
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.
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?
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.
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.
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.
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