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

From: "Susan Thomson \(sethomso\)" <[email-masked]>
Date: Thu, 5 Oct 2006 15:22:18 -0400

Hi Vidya

Thanks for your comments.

Inline ...

> -----Original Message-----
> From: Narayanan, Vidya [mailto:[email-masked]] 
> Sent: Wednesday, October 04, 2006 12:48 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [Nea] WG Review: Network Endpoint Assessment (nea) 
> 
> 
> All,
> Comments on the charter inline below.  
> 
> > -----Original Message-----
> > From: IESG Secretary [mailto:[email-masked]] 
> > Sent: Monday, October 02, 2006 7:30 AM
> > To: [email-masked]
> > Cc: [email-masked]
> > 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 
> > ([email-masked]) by October 9.
> > 
> > +++
> > 
> > Network Endpoint Assessment (nea)
> > ======================================
> > 
> > Current Status: Proposed Working Group
> > 
> > Chair(s): 
> > TBD
> > 
> > Security Area Director(s):
> > Russ Housley <[email-masked]>
> > Sam Hartman <[email-masked]>
> > 
> > Security Area Advisor:
> > Russ Housley <[email-masked]>
> > 
> > Mailing List: [email-masked]
> > 
> > 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
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/nea
> > 
> 
> _______________________________________________
> Nea mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nea
> 

_______________________________________________
Nea mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nea

---

From: Sam Hartman <[email-masked]>
Date: Thu, 05 Oct 2006 23:59:53 -0400

>>>>> "Susan" == Susan Thomson (sethomso) <[email-masked]> writes:

    Susan> regard. For example, potential deployment scenarios may
    Susan> include,but are not limited to, providing normal access

Drop the may include.  You want to have at least one or two
deployments that you commit to solving to check your requirements
against.
You can have include but are not limited if you like.

    Susan> 
    Susan> regardless of compliance with recommendations for
    Susan> remediation ("advisory mode"), as well as providing
    Susan> restricted access sufficient for remediation purposes and
    Susan> any essential services until an endpoint is in compliance
    Susan> ("mandatory mode").

I express no preference on whether or not the new or old text is
better.  I just want to commit to at least one deployment.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 6 Oct 2006 13:49:11 -0700

Hi Susan,
Please see inline.  

> From: Susan Thomson (sethomso) [mailto:[email-masked]] 
> Sent: Thursday, October 05, 2006 12:22 PM
> To: Narayanan, Vidya
> Cc: [email-masked]; [email-masked]; [email-masked]
> > > The IESG has not made any determination as yet. The 
> following draft 
> > > charter was submitted, and is provided for informational purposes 
> > > only.
> > > 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. 
> 
> > mechanisms like firewalls, access control, packet filters, IDS/IPS, 
> > etc. in any combination to appropriately protect the networks.
> > 
> 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"? 

> > > 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.
> > > 
> > 
> > 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.
> > > 
> > 
> 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
> > 
> > > 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.
> protocols will 
> > > allow interoperability between an NEA Client from one 
> vendor and an 
> > > NEA Server from another.
> > > 
> > 
> 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, 
> > > 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.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". 

> > > 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.
> > 
> 

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! 

> 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.
> > > 
> > 
> > 
> > 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. 

> > > 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.
> > > 
> > 
> > 
> > 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 
> compliance tests 
> > on the endpoint."

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

---

From: Lakshminath Dondeti <[email-masked]>
Date: Sat, 07 Oct 2006 10:42:31 -0700

At 01:42 AM 10/7/2006, Harald Alvestrand wrote:
>><snip>
>Many universities require their students to buy their own laptops, 
>but prohibit certain types of activity from those laptops (like 
>spamming, DDOS-attacks and the like). They would love to have the 
>ability to run some kind of NEA procedure to ensure that laptops are 
>reasonably virus-free and free from known vulnerabilities, and are 
>important enough in their students' lives that they can probably 
>enforce it without a complaint about "violation of privacy".
>
>Just pointing out that there's one use case with user-managed 
>endpoints where NEA is not obviously a bad idea.

My email ventures into a bit of non-IETF territory, but we are 
discussing use cases, and so I guess it's on topic.  Universities 
should be the last places to try antics like NEA.  Whereas an 
operational network would be a priority to them, it is also important 
that they allow students to experiment with new applications.  If we 
are believing that general purpose computing will be taken away from 
college students, we are indeed talking about a different world.

In any event, the bottomline is NEA as a solution to "network 
protection" is a leaky bucket at best.

NEA at best *may* raise the bar in attacking a "closed" network where 
endpoints are owned and tightly controlled by the organization that 
owns the network.

Lakshminath

>                    Harald
>Ietf mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ietf

---

From: "todd glassey" <[email-masked]>
Date: Sat, 7 Oct 2006 07:40:56 -0700

Harald - get Microsoft to buy into this idea and its done.

Todd Glassey
----- Original Message ----- 
From: "Harald Alvestrand" <[email-masked]>
To: "Narayanan, Vidya" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Saturday, October 07, 2006 1:42 AM
Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea)

> Many universities require their students to buy their own laptops, but
> prohibit certain types of activity from those laptops (like spamming,
> DDOS-attacks and the like). They From [email-masked] Sat Oct 07 15:17:46 2006
From: "todd glassey" <[email-masked]>
To: "Harald Alvestrand" <[email-masked]>,
	"Narayanan, Vidya" <[email-masked]>
Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea)
Date: Sat, 7 Oct 2006 07:40:56 -0700
Cc: [email-masked], [email-masked], [email-masked]

Harald - get Microsoft to buy into this idea and its done.

Todd Glassey
----- Original Message ----- 
From: "Harald Alvestrand" <[email-masked]>
To: "Narayanan, Vidya" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Saturday, October 07, 2006 1:42 AM
Subject: Re: [Nea] WG Review: Network Endpoint Assessment (nea)

> Many universities require their students to buy their own laptops, but
> prohibit certain types of activity from those laptops (like spamming,
> DDOS-attacks and the like). They would love to have the ability to run
> some kind of NEA procedure to ensure that laptops are reasonably
> virus-free and free from known vulnerabilities, and are important enough
> in their students' lives that they can probably enforce it without a
> complaint about "violation of privacy".
>
> Just pointing out that there's one use case with user-managed endpoints
> where NEA is not obviously a bad idea.
>
>                     Harald
>
>

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 07 Oct 2006 10:42:05 +0200

> different from the organization's perspective in this casewould love to have the ability to run

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 07 Oct 2006 10:42:05 +0200

Harald

. Third, I

                    Harald

---

From: "Susmit Panjwani" <[email-masked]>
Date: Sat, 7 Oct 2006 20:04:05 -0400

Third, I > > simply can't see what the organization's interests would be in
> > protecting a device that doesn't even belong to it.

An organization might not be interested in protecting a device that
does not belong to it but would definitely be interested in preventing
the attacks originating from such device (if compromised) when it
joins the organization network.  To cite a study that we performed at
UMD: we did a cost-benefit analysis based on the captured attacks from
within the organization, and it turns out that the organization would
benefit significantly if they  implement any trusted network access
technology.

I do realize that there would be issues in terms of user privacy and
interoperability(which this charter is trying to tackle) but just
wanted to mention that there would be significant benefits if they can
implement it. This is especially true for university environment.  As
a matter of fact I am aware of some universities/departments that were
planning to implement a home grown solution for this.

Susmit

-- 
Susmit Panjwani

PhD Candidate,
Center for Risk and Reliability,
University of Maryland
Cell: 240-460-9782

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Sun, 8 Oct 2006 10:05:03 -0700

> From: Susmit Panjwani [mailto:[email-masked]] 
> Sent: Saturday, October 07, 2006 5:04 PM
> To: Harald Alvestrand
> Cc: Narayanan, Vidya; [email-masked]; [email-masked]; [email-masked]
> An organization might not be interested in protecting a 
> device that does not belong to it but would definitely be 
> interested in preventing the attacks originating from such 
> device (if compromised) when it joins the organization 
> network.  

It appears that the NEA charter is completely misleading to some people
from what is stated in this email. As the NEA charter alludes to, NEA
does nothing to protect against compromised devices. Also, as has been
agreed, NEA is not a protection mechanism for the network - it is meant
to be a protection mechanism for compliant, truthful and as yet
uncompromised end hosts against known vulnerabilities. 

Any network, in its own best interests, must assume that it has lying
and compromised endpoints connecting to it and that there are unknown
vulnerabilities on any NEA-compliant devices connecting to it. Any kind
of protection that addresses these general threats that the network may
be exposed to at any time will simply obviate the need for NEA from the
network perspective. 

A network operator that thinks the network is getting any protection by
employing NEA is clearly ignoring the obvious real threats that the
network is exposed to at any time. 

This is what I meant when I said that the charter is unclear and it must
explicitly state that NEA is not meant as a protection mechanism of any
sort for the network. 

Vidya

> To cite a study that we performed at
> UMD: we did a cost-benefit analysis based on the captured 
> attacks from within the organization, and it turns out that 
> the organization would benefit significantly if they  
> implement any trusted network access technology.
> 
> I do realize that there would be issues in terms of user 
> privacy and interoperability(which this charter is trying to 
> tackle) but just wanted to mention that there would be 
> significant benefits if they can implement it. This is 
> especially true for university environment.  As a matter of 
> fact I am aware of some universities/departments that were 
> > > > 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.
> > > >
> > >
> > >
> > > 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.
> > virus-free and free from known vulnerabilities, and are important 
> > enough in their students' lives that they can probably enforce it 
> > without a complaint about "violation of privacy".
> >

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Sun, 8 Oct 2006 10:14:41 -0700

> From: Lakshminath Dondeti [mailto:[email-masked]] 
> Sent: Saturday, October 07, 2006 10:43 AM
> To: Harald Alvestrand; Narayanan, Vidya
> My email ventures into a bit of non-IETF territory, but we 
> are discussing use cases, and so I guess it's on topic.  
> Universities should be the last places to try antics like 
> NEA.  Whereas an operational network would be a priority to 
> them, it is also important that they allow students to 
> experiment with new applications.  If we are believing that 
> general purpose computing will be taken away from college 
> students, we are indeed talking about a different world.
> 

I agree. Even in a controlled environment, there is bound to be
software/hardware that does not quite support NEA or specific posture
attributes. In a university environment, while some basic posture
reporting is feasible, there is bound to be a lot of software/hardware
that does not support any NEA parameters. The protection that even the
endhost may be getting from NEA is quite limited. 

> protection" is a leaky bucket at best.

The charter must be clarified to dispel this myth about NEA protecting
the network from anything.  

Vidya

> NEA at best *may* raise the bar in attacking a "closed" 
> network where endpoints are owned and tightly controlled by 
> the organization that owns the network.
> 
> Lakshminath
> 
> 
> >                    Harald
> >
> >

---

From: "Darryl \(Dassa\) Lynch" <[email-masked]>
Date: Mon, 9 Oct 2006 07:20:27 +1000

Hi Vidya

Narayanan, Vidya wrote:
>>>>> Third, I simply can't see what the organization's interests would be
in
>>>> does not belong to it but would definitely be interested in
>>>> preventing the attacks originating from such device (if
>>>> compromised) when it joins the organization network.
>> 
>> It appears that the NEA charter is completely misleading to
>> some people from what is stated in this email. As the NEA
>> charter alludes to, NEA does nothing to protect against
>> compromised devices. Also, as has been agreed, NEA is not a
>> protection mechanism for the network - it is meant to be a
>> protection mechanism for compliant, truthful and as yet

True the NEA doesn't "do" anything to protect against compromised devices
but it does assist in limiting the known compromises on endpoint devices by
being a mechanism for the checking and reporting on compliance to what ever
network policy is in place including virus and patch levels.  As a network
administrator I already deploy mechanisms for doing just this, but at a
higher level than the NEA charter indicates.  To me the difference is
between being reactive or proactive.  Compliance testing I already run
occurs after an end node has joined the network, with NEA the possibility is
for compliance checking before being allowed onto the network so isolation
and immediate remediation is possible.

>> Any network, in its own best interests, must assume that it
>> has lying and compromised endpoints connecting to it and
>> that there are unknown vulnerabilities on any NEA-compliant
>> devices connecting to it. Any kind of protection that
>> addresses these general threats that the network may be
>> exposed to at any time will simply obviate the need for NEA from the
>> network perspective. 

Reliance on one protection or reporting mechanism is not enough.  We need a
lot of varied tools to cover all the bases and minimise risk.

>> A network operator that thinks the network is getting any
>> protection by employing NEA is clearly ignoring the obvious
>> real threats that the network is exposed to at any time.

No, NEA would just be one more tool used to improve overall security and
minimise risk.  It would be at a different level to the tools some of
already deploy.

>> This is what I meant when I said that the charter is unclear
>> and it must explicitly state that NEA is not meant as a
>> protection mechanism of any sort for the network.

I don't believe the Charter needs to delve into this at all.  If some people
see it as part of their protection mechanisms, so be it.

Darryl (Dassa) Lynch

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 08 Oct 2006 21:21:30 +0200

> endpoints are owned and tightly controlled by the organization that 
Posture checking is certainly a leaky bucket. It doesn't protect all 
kinds of endpoint, it doesn't protect the endpoints against all kinds of 
threats, and it doesn't protect much of anything against a smart, 
resourceful attacker who is deeply familiar with the NEA system in use 
and is interested in investing considerable resources in attacking or 
circumventing it.

But (to recycle a very old simile) the fact that I can open the locks of 
most doors with a crowbar doesn't mean that locks are not useful. 
Organizations that have deployed products that do something like what 
NEA is talking about have reported that their TCO is reduced.

                        Harald

---

From: Susan Harris <[email-masked]>
Date: Mon, 9 Oct 2006 08:59:13 -0400 (EDT)

I believe this mail should have gone to Sue Hares.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 9 Oct 2006 09:29:37 -0700

Hi Darrly, 

<snip>

> >> 
> >> It appears that the NEA charter is completely misleading to some 
> >> people from what is stated in this email. As the NEA 
> charter alludes 
> >> to, NEA does nothing to protect against compromised 
> devices. Also, as 
> >> has been agreed, NEA is not a protection mechanism for the 
> network - 
> >> it is meant to be a protection mechanism for compliant, 
> truthful and 
> >> as yet uncompromised end hosts against known vulnerabilities.
> 
> True the NEA doesn't "do" anything to protect against 
> compromised devices but it does assist in limiting the known 
> compromises on endpoint devices by being a mechanism for the 
> checking and reporting on compliance to what ever network 
> policy is in place including virus and patch levels.  

I'm not sure what you mean by "known compromises" - did you mean known
vulnerabilities? If so, yes - I was not questioning the role of NEA in
dealing with known vulnerabilities on truthful endpoints. 

The discussion was about using NEA as a protection mechanism for the
network and that doesn't make sense to me and as I understand from
Susan, that is not the intention of the charter either. 

> As a 
> network administrator I already deploy mechanisms for doing 
> just this, but at a higher level than the NEA charter 
> indicates.  To me the difference is between being reactive or 
> proactive.  Compliance testing I already run occurs after an 
> end node has joined the network, with NEA the possibility is 
> for compliance checking before being allowed onto the network 
> so isolation and immediate remediation is possible.
> 
> >> vulnerabilities on any NEA-compliant devices connecting to it. Any 
> >> kind of protection that addresses these general threats that the 
> >> network may be exposed to at any time will simply obviate the need 
> >> for NEA from the network perspective.
> 
> Reliance on one protection or reporting mechanism is not 
> enough.  We need a lot of varied tools to cover all the bases 
> and minimise risk.
> 

This is repitition at this point - but, when a network has mechanisms to
protect itself against lying endpoints and unknown vulnerabilites, that
should cover protection against truthful ones with known
vulnerabilities. Otherwise, the network is obviously not adequately
protected against the broader set of threats. So, one would employ NEA
in their networks to protect the end hosts attaching to the network, not
the network itself. 

> protection 
> >> by employing NEA is clearly ignoring the obvious real threats that 
> >> the network is exposed to at any time.
> 
> No, NEA would just be one more tool used to improve overall 
> security and minimise risk.  It would be at a different level 
> to the tools some of already deploy.
> 
> >> This is what I meant when I said that the charter is 
> unclear and it 
> >> must explicitly state that NEA is not meant as a 
> protection mechanism 
> I don't believe the Charter needs to delve into this at all.  
> If some people see it as part of their protection mechanisms, 
> so be it.
> 

That is a terrible approach to take, given how misleading the charter
obviously has been to many. The charter must be clear about what the WG
is doing and what is out of scope. 

Vidya

---

From: "Darryl \(Dassa\) Lynch" <[email-masked]>
Date: Tue, 10 Oct 2006 07:08:08 +1000

Harald Alvestrand wrote:
<SNIP>
>> Posture checking is certainly a leaky bucket. It doesn't
>> protect all kinds of endpoint, it doesn't protect the
>> endpoints against all kinds of threats, and it doesn't
>> protect much of anything against a smart, resourceful
>> attacker who is deeply familiar with the NEA system in use
>> and is interested in investing considerable resources in
>> attacking or circumventing it.

NEA itself may not offer any protection, it is more an informational tool
from my perspective.  How that information may be used could lead to some
protection but that would vary with each deployment.

>> But (to recycle a very old simile) the fact that I can open
>> the locks of most doors with a crowbar doesn't mean that locks are
>> not useful. Organizations that have deployed products that do
>> something like what NEA is talking about have reported that their
>> TCO is reduced. 

In these days of information overload I still maintain, the more information
available the better it is.

Darryl (Dassa) Lynch

---

From: Russ Housley <[email-masked]>
Date: Wed, 11 Oct 2006 10:18:53 -0400

>any policies of the organization itself."?

Discussions with the IAB and IESG prior to external review lead to 
the addition of the modes discussion.  The point is that some 
networks will demand compliance to grant full access, and other 
networks will simply notify that host that they are not in 
compliance.  A host my not want to change the configuration to gain 
compliance.  That is acceptable in the second case, but not the first.

Russ

---

From: "todd glassey" <[email-masked]>
Date: Wed, 11 Oct 2006 09:51:41 -0700

Russ - I agree that something like a global NEA is necessary - just not that
a new protocol is necessary to implement it. So let me ask...

So then why not pass a new configuration mode model with SNMP - the point is
that while the idea of some agent that could actually collect these separate
logs and service records from the various 'aspects of compliance' built into
the operating models of the system in question, is no new one.

Tripwire's does this already. COPS and FREMONT can be made to with CRON and
their configuration files. SNORT, AIDE, Heck they can even use SysLogNG as
the transport for their log data which might also make sense as an
addition...  Or SCP/SFTP if they wanted to.

The point is that while NEA is a good collective idea at the altitude the
idea was hatched at, there are already things that do the NEA component
functions today, and that can be aggregated together into a homogeneous
utility environment without redesigning the wheel again.

I don't dispute that the end goal of what the Creator's of the NEA idea
wanted to accomplish is not good. It is clearly. But the issue is whether
its necessary to have in the form they have proposed so far when other very
similar and more widely deployed transports exist for the Inter-Nodal
Communications Model that NEA purports to want to create.

Again - SNMP and Syslog/SysLogNG can do allot of this already. Why not just
add an Node-Integrity Reporting Process to either of  them. From an Audit
Perspective this would be a powerful addition to the SysLog protocols since
it would better anchor them

Just my 35c.

Todd Glassey

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 11 Oct 2006 11:53:31 -0700

Hi Russ, 

> From: Russ Housley [mailto:[email-masked]] 
> Sent: Wednesday, October 11, 2006 7:19 AM
> To: Narayanan, Vidya
> Discussions with the IAB and IESG prior to external review 
> lead to the addition of the modes discussion.  The point is 
> that some networks will demand compliance to grant full 
> access, and other networks will simply notify that host that 
> they are not in compliance.  A host my not want to change the 
> configuration to gain compliance.  That is acceptable in the 
> second case, but not the first.
> 

I don't disagree with the above. But, I was mainly wondering what impact
any of these decisions may have on NEA itself? Aren't these just
post-NEA actions? 

In general though, I have far less problems with this text than I do
with the idea of NEA somehow protecting networks or NEA being performed
on endpoints that is not owned by the organization performing NEA. 

Regards,
Vidya

---

From: Russ Housley <[email-masked]>
Date: Wed, 11 Oct 2006 17:01:46 -0400

Both need to be accommodated.  I do not know if there will be an 
impact on the protocol to ensure that both are accommodated.

Russ

---

From: Douglas Otis <[email-masked]>
Date: Wed, 11 Oct 2006 14:33:56 -0700

On Oct 11, 2006, at 2:01 PM, Russ Housley wrote:

>>>> 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."?
>>>
>>> Discussions with the IAB and IESG prior to external review lead  
>>> to the addition of the modes discussion.  The point is that some  
>>> networks will simply notify [the] host that they are not in  
>>> compliance.  A host my not want to change the configuration to  
>>> gain compliance.  That is acceptable in the second case, but not  
>>> the first.
>>
>> I don't disagree with the above. But, I was mainly wondering what  
>> impact any of these decisions may have on NEA itself? Aren't these  
>> just post-NEA actions?
>>
>> In general though, I have far less problems with this text than I  
>> do with the idea of NEA somehow protecting networks or NEA being  
>> performed on endpoints that is not owned by the organization  
>> performing NEA.

The latter mode seems the most interesting.  Rather than seeing this  
as an endpoint auditing or information gathering mechanism, this can  
also serve as a means to notify endpoints of an "apparent" lack of  
compliance, where an endpoint must then use a service that provides a  
"certificate" of compliance.  This process may need to be repeated as  
needed, where remediation may be part of the process.  This mechanism  
could supplement browser redirection as a notification mechanism,  
especially when the endpoint is not running a browser.

-Doug

---

From: Leif Johansson <[email-masked]>
Date: Mon, 16 Oct 2006 10:46:16 +0200

> endpoints are owned and tightly controlled by the organization that
Lets not forget that when (not if) NEA/NAP/NAC is deployed the IDSen
people have deployed today to
solve the lying-client-problem by scanning for common/current
vulnerabilities as part of the network admission
process will have to interface with PDPs part of a NEA intfrastructure.

    Cheers Leif

---

From: Lakshminath Dondeti <[email-masked]>
Date: Mon, 16 Oct 2006 03:16:10 -0700

>process will have to interface with PDPs part of a NEA intfrastructure.

Could you rephrase please?  I am afraid I don't understand what you 
are saying.

Oh, and lying endpoint problem cannot be solved by scanning for 
common vulnerabilities!  In fact, the two have no relation whatsoever.

Lakshminath

---

From: Leif Johansson <[email-masked]>
Date: Wed, 18 Oct 2006 15:15:27 +0200

> Could you rephrase please?  I am afraid I don't understand what you
It has been pointed out on this list that the main deliverable from NEA
might well turn out to
be the way host postures are described - the schema if you will. I'm
positive that if someone
deployes NEA/NAP/NAC etc the admin will want to combine data from the
on-client
posture client with information from external IDS (etc) services to a
common Policy Decision
Point. That means that a reason to do NEA is to get this schema
standardized even if some
people who care about lying clients to never use and/or trust client
posture clients.
> Oh, and lying endpoint problem cannot be solved by scanning for common
> vulnerabilities!  In fact, the two have no relation whatsoever.
They have the single relation of both expressing claims about the state
of a host.  

       Cheers Leif