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

From: IESG Secretary <[email-masked]>
Date: Tue, 17 Oct 2006 15:50:02 -0400

A new IETF working group has been proposed in the Security Area.  
The IESG has not made any determination as yet. The following UPDATED 
draft charter was submitted, and is provided for informational purposes
only. Please send your comments to the IESG mailing list ([email-masked]) 
by October 23rd.

+++

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. Note that an endpoint that is 
deemed compliant may still be vulnerable to unknown threats that may 
exist on the network. The network may thus continue to be exposed to 
such threats as well as the range of other threats not addressed by 
maintaining endpoint compliance.

Posture refers to the hardware or software configuration of an 
endpoint as it pertains to an organization's security policy. Posture 
may include knowledge that software installed to protect the machine 
(e.g. patch management software, anti-virus software, host firewall 
software, host intrusion protection software or any custom software) 
is enabled and up-to-date. On network access and while connected, an 
endpoint supporting NEA protocols can be queried for such posture
information.

An organization may make a range of policy decisions based on the 
posture of an endpoint. NEA is not intended to be prescriptive in 
this regard. Supported deployment scenarios will include, but are not 
limited to, providing normal access regardless of compliance result 
along with any recommendations for remediation ("advisory mode"), as 
well as providing restricted access sufficient for remediation 
purposes and any essential services until an endpoint is in 
compliance ("mandatory mode").

Since NEA involves many different components from different vendors, 
interoperability is important. The priority of the NEA working group 
is to develop standard protocols at the higher layers in the 
architecture: the Posture Attribute protocol (PA) and the Posture 
Broker protocol (PB). PA and PB will be designed to support a variety 
of lower layer protocols. When used with standards for lower layers, 
the PA and PB protocols will allow interoperability between an NEA 
Client from one vendor and an NEA Server from another.

Since there are already several non-standard protocols at these 
higher layers, the NEA working group will consider these existing 
protocols as candidates for the standard protocols. A requirements 
document will be written and used as a basis for evaluating the 
candidate protocols. The working group may decide to standardize one 
of the candidate protocols, use one of them as a basis for a new or 
revised protocol, or decide that a new protocol is needed.

The NEA Requirements document will include a problem statement, 
definition of terms, requirements for the PA and PB protocols, and an 
overall security analysis. It will also include generic requirements 
for the protocol transporting PA, PB: the Posture Transport protocol 
(PT). PT protocols may be standardized in other WGs since these 
protocols may not be specific to NEA. The NEA WG will identify one 
mandatory to implement PT protocol to ensure interoperability.

The PA (Posture Attribute) protocol consists of posture attributes 
that are carried between a particular Posture Collector in a NEA 
client and a particular Posture Validator in a NEA Server. The PA 
protocol is carried inside the PB protocol. A base set of standard 
posture attributes will be specified. Vendor-specific attributes 
will also be supported, but vendor-specific attributes must be 
documented in an RFC.

The PB (Posture Broker) protocol aggregates posture attributes from 
one or more Posture Collectors in an NEA client and sends them to the 
NEA server for assessment by one or more Posture Validators.

The PT (Posture Transport) protocol carries the PB protocol.

The NEA working group will not specify protocols other than PA and PB 
at this time. The expectation is that an existing protocol can be 
used for the PT.

One commonly discussed issue with NEA systems is how to handle 
compromised endpoints, whose reports of their own posture may not be 
accurate. Detecting or handling such endpoints is out of scope of the 
NEA WG. Work on PA will focus on attributes useful for assessing 
posture of those endpoints reporting accurate information. However, 
the protocols developed by the NEA WG must be designed to accommodate 
emerging technologies for identifying and dealing with lying endpoints.

Note that NEA is not chartered to develop standard protocols for 
remediation. NEA is intended to be used with new or existing tools 
that can be used in the absence of NEA. NEA can be limited in its 
applicability when the endpoint and the organization providing 
network access are owned by different parties. NEA applicability and 
security considerations will be described in the appropriate NEA
documents.

Further work in the NEA WG will be considered via the rechartering 
process after the completion of these milestones.

Milestones:

October 2006:
* Submit first draft of NEA Requirements I-D

November 2006:
* At IETF 67, discuss issues with NEA Requirements I-D
* Agree on solutions to issues with NEA Requirements I-D

December 2007:
* Submit revised requirements I-D

February 2007:
* WGLC on NEA Requirements I-D
* Deadline for submission of candidate specs for PA and PB

March 2007:
* At IETF 68, resolve outstanding issues with requirements I-D
* Report from NEA protocol evaluation team

April 2007:
* Submit NEA Evaluation I-D

June 2007:
* Submit revised NEA Evaluation I-D
* WGLC on NEA Evaluation I-D

July 2007:
* At IETF 69, review outstanding comments on evaluation I-D

August 2007:
* Submit first draft of PA and PB spec

October 2007:
* Submit revised draft of PA and PB spec
* Decide how to address MTI PT, recharter if needed

December 2007:
* At IETF70, discuss and resolve issues with PA and PB spec

February 2008:
* WGLC on PA and PB spec

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

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 23 Oct 2006 23:14:54 -0700

All,

This charter is definitely clearer on some of the points that were
discussed based on the last version, but a couple of things still remain
to be clarified. Based on several discussions that we've had lately, I
have two suggestions for further clarity: 

1. Let's add the text suggested by Harald and Lakshminath (there seemed
to be agreement on this text on the list). Quoting the change proposed: 

Replace:

"NEA can be limited in its applicability when the endpoint and the
organization providing network access are owned by different parties."

with

"NEA is applicable to computing environments of enterprises where
endpoints accessing the enterprise's network are owned and/or expected
to conform to the policies set forth by the organization that owns and
operates the network.  All other cases are outside the scope of the NEA
charter, since we do not know that NEA would be useful in such cases." 

2. On the mandatory-to-implement PT protocol, I would like to see the
clarification that the protocol must allow the NEA process to run either
at the time of network access or while connected. This clarification
seems mainly needed because there is text elsewhere in the charter about
allowing NEA runs "at network access or while connected" - if that text
is removed, this clarification won't be required. 

Thanks,
Vidya

> -----Original Message-----
> From: IESG Secretary [mailto:[email-masked]] 
> Sent: Tuesday, October 17, 2006 12:50 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) 
> 
> The IESG has not made any determination as yet. The following 
> UPDATED draft charter was submitted, and is provided for 
> informational purposes only. Please send your comments to the 
> IESG mailing list ([email-masked]) by October 23rd.
> 
> +++
> 
> Network Endpoint Assessment (NEA) architectures have been 
> implemented in the industry to assess the "posture" of 
> endpoint devices for the purposes of monitoring compliance to 
> an organization's posture policy and optionally restricting 
> access until the endpoint has been updated to satisfy the 
> posture requirements. An endpoint that does not comply with 
> posture policy may be vulnerable to a number of known threats 
> that may exist on the network. The intent of NEA is to 
> facilitate corrective actions to address these known 
> vulnerabilities before a host is exposed to potential attack. 
> Note that an endpoint that is deemed compliant may still be 
> vulnerable to unknown threats that may exist on the network. 
> The network may thus continue to be exposed to such threats 
> as well as the range of other threats not addressed by 
> Posture refers to the hardware or software configuration of 
> an endpoint as it pertains to an organization's security 
> policy. Posture may include knowledge that software installed 
> to protect the machine (e.g. patch management software, 
> anti-virus software, host firewall software, host intrusion 
> protection software or any custom software) is enabled and 
> up-to-date. On network access and while connected, an 
> endpoint supporting NEA protocols can be queried for such 
> posture information.
> 
> An organization may make a range of policy decisions based on 
> the posture of an endpoint. NEA is not intended to be 
> prescriptive in this regard. Supported deployment scenarios 
> will include, but are not limited to, providing normal access 
> regardless of compliance result along with any 
> recommendations for remediation ("advisory mode"), as well as 
> providing restricted access sufficient for remediation 
> Since NEA involves many different components from different 
> vendors, interoperability is important. The priority of the 
> NEA working group is to develop standard protocols at the 
> higher layers in the
> architecture: the Posture Attribute protocol (PA) and the 
> Posture Broker protocol (PB). PA and PB will be designed to 
> support a variety of lower layer protocols. When used with 
> standards for lower layers, the PA and PB protocols will 
> allow interoperability between an NEA Client from one vendor 
> and an NEA Server from another.
> 
> Since there are already several non-standard protocols at 
> these higher layers, the NEA working group will consider 
> these existing protocols as candidates for the standard 
> protocols. A requirements document will be written and used 
> as a basis for evaluating the candidate protocols. The 
> working group may decide to standardize one of the candidate 
> protocols, use one of them as a basis for a new or revised 
> protocol, or decide that a new protocol is needed.
> 
> The NEA Requirements document will include a problem 
> statement, definition of terms, requirements for the PA and 
> PB protocols, and an overall security analysis. It will also 
> include generic requirements for the protocol transporting 
> PA, PB: the Posture Transport protocol (PT). PT protocols may 
> be standardized in other WGs since these protocols may not be 
> specific to NEA. The NEA WG will identify one mandatory to 
> implement PT protocol to ensure interoperability.
> 
> The PA (Posture Attribute) protocol consists of posture 
> attributes that are carried between a particular Posture 
> Collector in a NEA client and a particular Posture Validator 
> in a NEA Server. The PA protocol is carried inside the PB 
> protocol. A base set of standard posture attributes will be 
> specified. Vendor-specific attributes will also be supported, 
> but vendor-specific attributes must be documented in an RFC.
> 
> The PB (Posture Broker) protocol aggregates posture 
> attributes from one or more Posture Collectors in an NEA 
> client and sends them to the NEA server for assessment by one 
> or more Posture Validators.
> 
> The NEA working group will not specify protocols other than 
> PA and PB at this time. The expectation is that an existing 
> protocol can be used for the PT.
> 
> One commonly discussed issue with NEA systems is how to 
> handle compromised endpoints, whose reports of their own 
> posture may not be accurate. Detecting or handling such 
> endpoints is out of scope of the NEA WG. Work on PA will 
> focus on attributes useful for assessing posture of those 
> endpoints reporting accurate information. However, the 
> protocols developed by the NEA WG must be designed to 
> accommodate emerging technologies for identifying and dealing 
> with lying endpoints.
> 
> Note that NEA is not chartered to develop standard protocols 
> for remediation. NEA is intended to be used with new or 
> existing tools that can be used in the absence of NEA. NEA 
> can be limited in its applicability when the endpoint and the 
> organization providing network access are owned by different 
> parties. NEA applicability and security considerations will 
> be described in the appropriate NEA documents.
> 
> Further work in the NEA WG will be considered via the 
> rechartering process after the completion of these milestones.
> 
> Milestones:
> 
> October 2006:

---

From: "todd glassey" <[email-masked]>
Date: Tue, 24 Oct 2006 04:43:02 -0700

Vidya is it your intent to build an auditing protocol without auditors and
under the formal qualifications for an Audit Personnel???

OK, cool - by the way, I would like to know how many company's any of you
have audited? Its an important question... especially for Harald. I am
betting NONE is the answer, and that speaks for itself.

My rework on the proposed change #1 below...

Todd Glassey - as a Certified Auditor and Forensic Investigator.

----- Original Message ----- 
From: "Narayanan, Vidya" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, October 23, 2006 11:14 PM
Subject: RE: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)

All,

Replace:

(TSG: THIS IS A STATEMENT OF A CONTROL, although its poorly written for
that)

with

(TSG: THIS IS A STATEMENT OF CAPABILITY) -

TSG: 1) HOW ABOUT:
---------------------
"NEA is a Policy Compliance Tool-set applicable to computing environments
across both heterogenous and homogeneous enviornment's with differing policy
constraints to them."

WHY? The issue setting a boundry at the permiter of the Organization is
inaccurate from an Auditing Perspective which the NEA is a key part of. Any
NEA designs and deployments that do not address the auditing or controls of
the Industry like COBIT DS and ME Control Activities is not likely to gain
acceptance, since this product cannot go into use, until it addresses what
in the Audit Profile and how its to work for the Audit Attestations.

So... What does the Use of NEA do for the Auditability of IT departments.
--------------------

Thanks,
Vidya

---

From: Keith Moore <[email-masked]>
Date: Tue, 24 Oct 2006 08:25:45 -0400

-------- Original Message --------

> operates the network.  

That seems overbroad, in particular because a laptop that connects to 
multiple networks cannot in general be expected to adhere to conflicting 
policies of the networks to which it connects.

As far as I can tell, this is the crux of the problem with NEA - that in 
general it's simply unreasonable for a network to demand that every host 
that connect to it conform to arbitrary policies for configuration of 
those hosts.  IETF should not be standardizing unreasonable 
expectations. And even if the behavior is in some limited set of 
circumstances reasonable (which is debatable), IMHO IETF should hesitate 
to define standards for corner cases.

(I do sympathize with the notion that the biggest threats to an 
enterprise network are from the hosts that connect directly to it, and 
so it makes sense to concentrate efforts for protecting the network at 
the points where those hosts attach to the network)

The other problem I have with this charter is one that I have with many 
charters these days - it presupposes a particular design or architecture 
  before the working group has actually met, when this should be an 
engineering decision taken by the consensus of the working group AFTER 
analysis of the problem space.

Keith

---

From: "Mike Fratto" <[email-masked]>
Date: Tue, 24 Oct 2006 12:12:21 -0400

> to define standards for corner cases.

Whether a company manageing a network demands that all hosts meet a
specific policy is a local policy issue and the charter specifically
addresses this concern:

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

I think the intent of the working group is to standardize the data
formats and protocols so that NEA components can talk together, not to
say what to do with non-compliant hosts. That is a local policy
decsion. But to get to that decision, the components first have to
communicate.

At a very high level, this isn't much different than RADIUS, which
defines the data formats and protocols between a network access device
such as modem pool and the RADIUS server. Vendor specific attributes
are supported and the standards don't attempt to provide
*meaning*--that is left upto the vendor defining the specific
attributes.

---

From: "Alan DeKok" <[email-masked]>
Date: Tue, 24 Oct 2006 12:28:33 -0400

> policies of the networks to which it connects.

  Exactly.  That's why there are provisions for non-conforming
systems.  Network access can be denied entirely, or limited to the
public (and unprotected) network.  However, 99% of systems don't move
networks, so those systems don't have a problem conforming to the
local requirements.

> those hosts.

  I'm not sure how to take this.  It's unreasonable... OK, why?  Is it
unreasonable for me to require that I know which machines are on my
network, or to deny access to machines I don't own?  Given the
remediation options outlined above, what part of controlling network
access for unknown machines is unreasonable?

> analysis of the problem space.

  I think it presupposes a particular problem, not an architecture.
The problem is:

  a) knowing who is on my network
  b) controlling who is on my network
  c) controlling the behavior of the hosts on my network.

  If any of those problems are unreasonable to solve, then I would be
*very* confused.

  The proposed NEA architecture derives directly from that problem
statement.  The *only* assumptions I see are:

  a) It's a good idea to know who's on my network
  b) It's a good idea for me to control who is on my network
  c) It's a good idea for me to control the behavior of hosts
     on my network
  d) all of the above is possible to implement
  e) Step (d) should be standardized

  Alan DeKok.
--
  http://deployingradius.com       - The web site of the book
  http://deployingradius.com/blog/ - The blog

---

From: "Alan DeKok" <[email-masked]>
Date: Tue, 24 Oct 2006 12:35:09 -0400

> *meaning*--that is left upto the vendor defining the specific

  To put it another way, many network access protocols (DHCP, RADIUS,
etc.)  have been doing posture assessment and network access control
for a very long time.  The concepts behind NEA are not new.

  The new part in NEA is the desire to do *more* than what the current
access protocols have to offer.  Even if NEA was to leverage existing
protocols to their fullest extent, we would *still* need a
standardized way to exchange the data needed to implement the "more"
part of NEA.

  Alan DeKok.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 24 Oct 2006 09:48:36 -0700

On Oct 24, 2006, at 5:25 AM, Keith Moore wrote:
> On Oct 23, 2006, at 11:14 PM, Vidya Narayanan wrote:
>>
>> discussed based on the last version, but a couple of things still  
>> remain to be clarified. Based on several discussions that we've  
>> had lately, I have two suggestions for further clarity: 1. Let's  
>> add the text suggested by Harald and Lakshminath (there seemed to  
>> be agreement on this text on the list).
>> Quoting the change proposed: Replace:
>>
>> parties."
>> with "NEA is applicable to computing environments of enterprises  
>> where endpoints accessing the enterprise's network are owned and/ 
>> or expected to conform to the policies set forth by the  
>> organization that owns and operates the network.
>
> That seems overbroad, in particular because a laptop that connects  
> to multiple networks cannot in general be expected to adhere to  
> conflicting policies of the networks to which it connects.
>
> As far as I can tell, this is the crux of the problem with NEA -  
> that in general it's simply unreasonable for a network to demand  
> that every host that connect to it conform to arbitrary policies  
> for configuration of those hosts.  IETF should not be standardizing  
> unreasonable expectations. And even if the behavior is in some  
> limited set of circumstances reasonable (which is debatable), IMHO  
> IETF should hesitate to define standards for corner cases.

Rather than immediately exchanging vendor/environment specific  
details, exchange of information related to "posture" details can be  
instead evidenced by certificates declaring:

a) an issuing service and the resources needed for the service;
b) the class of service with a service relevant time-stamp;
c) the user-host identity;
d) text describing the service;

All "posture" related details are indirectly ascertained by the  
services that an NEA server allows, requests, or permits.  The NEA  
server may publish requirements as listed "sets" of hostmaster  
certificates.  The NEA client then checks its repository for a  
matching certificate within each set to fulfill expectations.  When  
no match is found or an update is determined to be required, the user  
might be prompted to pick a service certificate for execution.  The  
resources listed in the certificate can permit the client and server  
to establish a minimal network supporting the related NEA certificate  
generating service.

This approach should be useable in any environment, and not limited  
to corporate environments or specific operating systems.  The NEA  
client/servers would not directly exchange vendor specific structured  
data.  The NEA services would handle these details (and likely  
already are).  Existing services would be adapted to this NEA  
methodology by wrapping them with script that obtains the NEA service  
certificates after successful completion, and then placing them into  
the NEA certificate repository.  Upon a service failure, the related  
service may also expunge their certificates from the client's  
repository.  A certificate approach offers a flexible method for  
notifying users and for guiding them through a selection of  
remediation/certification services.  This strategy should reduce  
current IT support requirements in any environment while also making  
minimal changes to existing services.

> enterprise network are from the hosts that connect directly to it,  
> and so it makes sense to concentrate efforts for protecting the  
> network at the points where those hosts attach to the network)
>
> The other problem I have with this charter is one that I have with  
> many charters these days - it presupposes a particular design or  
> architecture  before the working group has actually met, when this  
> should be an engineering decision taken by the consensus of the  
> working group AFTER analysis of the problem space.

Well said.

-Doug

---

From: "Nelson, David" <[email-masked]>
Date: Tue, 24 Oct 2006 13:10:36 -0400

Keith Moore writes...

> what the WG charter says and how the WG output is used are 
> different things.  IMHO we need to consider the potential 
> unintended consequences of our efforts in IETF, not just what 
> we intend.  network operators do not limit their use of 
> technology to what we write in applicability statements.

Should I infer from this sentiment that you believe that the IETF ought
to refrain from standardizing any technology that could be used by
public or private network operators to discriminate against certain
classes of clients, based on the "posture" of their hosts?

I'll point out that only certain kinds of discrimination are
undesirable, i.e. discrimination against protected classes.  Other kinds
of discrimination, e.g. helping to maintain a "safe computing"
environment within a network, are highly desirable.

---

From: Keith Moore <[email-masked]>
Date: Tue, 24 Oct 2006 12:51:42 -0400

> posture of an endpoint. NEA is not intended to be prescriptive in

what the WG charter says and how the WG output is used are different 
things.  IMHO we need to consider the potential unintended consequences 
of our efforts in IETF, not just what we intend.  network operators do 
not limit their use of technology to what we write in applicability 
statements.

> such as modem pool and the RADIUS server. 

I don't think it's a good analogy because modem pools are very 
special-purpose devices, whereas a host can potentially do anything that 
needs to communicate with something else.  For that matter, RADIUS 
doesn't have the intent of preventing some kinds of modem pools from 
connecting to the network.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 24 Oct 2006 13:08:58 -0400

> networks, so those systems don't have a problem conforming to the

do you have actual statistics to back that up?  are 99% of hosts 
produced servers or desktops rather than laptops?  and how are you 
defining a host, anyway?  sorry, it just looks like a number picked out 
of thin air.

even if the 99% figure is true today, will it be true in general in the 
future?  personally I think that desktops as we know them are dinosaurs. 
  they are too much of a security threat, too expensive to maintain, 
offer more flexibility than is needed, and are becoming a vector by 
which extortionist licensing fees can be extracted from owners.  and the 
trend seems to be toward more and more mobile devices and special 
purpose devices.  standards take a long time to produce and need to last 
a long time, so it make sense to define them in such a way as to be 
likely to continue to be useful for the foreseeable future.

>   I'm not sure how to take this.  It's unreasonable... OK, why?

because the very nature of a personal computer is one in which every 
machine is customizable to suit the needs of the individual user.  if 
the network takes away that flexibility, it also obviates the need for a 
user-programmable personal computer.  there are better (more reliable, 
more secure, more effective, cheaper) ways of providing a set of 
functions at a user terminal than to give everyone user-programmable 
machines and then have the network insist that they all have a rigidly 
controlled configuration...and the only way to really get security out 
of PCs is to rigidly control their configurations.

and furthermore if PCs continue to be user-programmable then it becomes 
possible to make NEA meaningless.  (though the protocol could make it 
difficult for a host to forge assertions about itself by having the host 
sign the assertions with a key signed by the NEA software vendor, it 
would take some significant cleverness to prevent that key from being 
exposed to an attacker on that host, particularly one with physical 
access to the host).

NEA isn't about knowing "who" is on your network in the sense of 
determining identity, it's about being able to delve into arbitrary 
details of host configuration.

> statement. 

to me it seems to presuppose much more than that, by naming the kinds of 
actors and their roles.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 24 Oct 2006 13:24:40 -0400

> classes of clients, based on the "posture" of their hosts?

I think it's dangerous territory, and IETF needs to be very careful 
about how the subject is approached.  I don't think the current NEA 
charter reflects that kind of care, and I don't think that IETF 
processes for WG adoption really facilitate that kind of care.  Within 
existing IETF structure defining the appropriate direction for a group 
like NEA probably calls for an IAB workshop - which unfortunately is a 
lot slower than you want if you're trying to ship product and have it 
blessed as a standard.

Clearly there is some potential benefit at being able to identify hosts 
that present a risk to the network to which they are attached.  But
there's a very large and unpleasant camel attached to that nose.

Keith

---

From: "Alan DeKok" <[email-masked]>
Date: Tue, 24 Oct 2006 14:29:17 -0400

> connecting to the network.

  No, but it has the explicit intent of preventing some kinds of hosts
from connecting to the network.  Current RADIUS deployments implement
almost anything you can imagine to control network access for hosts
and/or users, down to filtering the users network traffic.  Current
RADIUS deployments *already* do ad-hoc posture assessment, there are a
number of startups implementing this today.

  I don't see how NEA is such a big philosophical change from existing
RADIUS practices.

  Alan DeKok.

---

From: "Alan DeKok" <[email-masked]>
Date: Tue, 24 Oct 2006 14:35:43 -0400

Keith Moore <[email-masked]> wrote:
> do you have actual statistics to back that up?

  It's not meant to be an exact number, but it's pretty close to being
correct, in my experience.

> there are better (more reliable, more secure, more effective,
> cheaper) ways of providing a set of functions at a user terminal
> than to give everyone user-programmable machines and then have the
> network insist that they all have a rigidly controlled
> configuration...

  Yes.  And there are mistakes in IETF protocols that have been
deployed for decades, too.  What are we supposed to tell the people
who have billions of dollars invested in their current systems?  "You
got it wrong, we're not going to come up with a solution to your
problems."  ?

> to me it seems to presuppose much more than that, by naming the kinds of 

  The actors and roles are nothing new.  End-hosts, authentication
servers, administrators, etc. have all been around for years.  The NEA
names are new, because people are starting to realize that there are
classes of behavior that cannot be adequately described using the
existing names.

  Alan DeKok.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 24 Oct 2006 12:10:39 -0700

> From: Alan DeKok [mailto:[email-masked]] 
> Sent: Tuesday, October 24, 2006 11:29 AM
> To: Keith Moore
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Nea] UPDATED: WG Review: Network Endpoint 
> Assessment (nea) 
> 
> > special-purpose devices, whereas a host can potentially do anything 
> > that needs to communicate with something else.  For that matter, 
> > RADIUS doesn't have the intent of preventing some kinds of 
> modem pools 
> > from connecting to the network.
> 
>   No, but it has the explicit intent of preventing some kinds 
> of hosts from connecting to the network.  Current RADIUS 
> deployments implement almost anything you can imagine to 
> control network access for hosts and/or users, down to 
> filtering the users network traffic.  Current RADIUS 
> deployments *already* do ad-hoc posture assessment, there are 
> a number of startups implementing this today.
> 
>   I don't see how NEA is such a big philosophical change from 
> existing RADIUS practices.
> 

I can sort of buy the analogy to RADIUS, although the AAA protocols are
intended to do a lot more (the third "A" for instance). However, RADIUS
doesn't inherently claim any security properties, while NEA seems to.
RADIUS (or Diameter, for that matter) cannot really guarantee any level
of security for network access control - that is dependent on what is
carried in RADIUS (sometimes, a couple of levels down - e.g., EAP Method
over EAP over RADIUS, where the strength is really dependent on the EAP
method). Also, the strength of the second "A" in AAA depends on the kind
of authorization policies in place. AAA is just a framework facilitating
these - not a protocol that has some security claims to it. 

Vidya

---

From: "Mike Fratto" <[email-masked]>
Date: Tue, 24 Oct 2006 15:38:37 -0400

> intended to do a lot more (the third "A" for instance).

Sorry, I didn't mean to sidetrack this. My RADIUS (or DHCP, or SNMP,
etc) example demonstrates a case where a set of protocols and data
formats are designed to have extensible attributes without having to
define the meaning of those attributes apriori. For example, if an AV
vendor called FOO wants to define an attribute BAR for it's product,
the NEA specifications should allow for that without having to define
a meaning for BAR or define an action based on the presence or absense
of BAR (which is a matter of local policy). Nor are all products that
implement NEA standards required to support extensions by vendor FOO
(also, a matter of local policy).

There seems to be confusion among some about supporting a set of
protocols and formats and enforcing policy. The charter seems pretty
clear that the outut of the NEA is *not* attempting to dictate local
policy. Product support is a local policy issue.

I'll shutup now.

---

From: Keith Moore <[email-masked]>
Date: Tue, 24 Oct 2006 14:57:47 -0400

> correct, in my experience.

one of my axioms for dealing with the Internet is that people's 
experiences (and assumptions) about what is typical vary widely - no 
single person's assumptions holds true in general.  the consequence for 
protocol standards is that they need to work in the face of a variety of 
assumptions/scenarios.

> got it wrong, we're not going to come up with a solution to your

no, we say "we're going to try to give you an evolution path that 
doesn't break compatibility with the investment you've made in our 
technology".  however realize that the half-life of a computer system is 
pretty short compared to the lifetime of a successful protocol standard. 
  there's more investment in the protocols than in the hardware, and the 
protocols don't generally assume user-programmable machines on 
everyone's desks.  (a few of them predate those days)

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 24 Oct 2006 14:44:41 -0400

>   I don't see how NEA is such a big philosophical change from existing

perhaps not, but I don't see how past mistakes are a justification for 
future ones.

Keith

---

From: "Mike Fratto" <[email-masked]>
Date: Tue, 24 Oct 2006 17:08:01 -0400

> yes, but it's clear that NEA is intended to be used, and will be used,
> as a mechanism to allow local networks to implement policies based on
> machine configuration.  the question is whether if is a good thing for
> the Internet for IETF to endorse such mechanisms.

The question in this thread seems to be whether the charter is worded
satisfactorily. I think the decision to move the BoF forward and
attempt to form a working group has been made regardless of the
utility of the proposed NEA output. :P

---

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

Keith Moore wrote:
>>> remain to be clarified. Based on several discussions that we've had
>>> lately, I have two suggestions for further clarity:
>>> 
>>> 1. Let's add the text suggested by Harald and Lakshminath (there
>>> seemed to be agreement on this text on the list). Quoting the
>>> change proposed: 
>>> 
>>> Replace:
>>> 
>>> endpoints accessing the enterprise's network are owned and/or
>>> expected to conform to the policies set forth by the organization
>>> that owns and operates the network.
>> 
>> That seems overbroad, in particular because a laptop that
>> connects to multiple networks cannot in general be expected
>> to adhere to conflicting policies of the networks to which it
>> connects. 

Why not, laptops already have to conform to some policies such as the
addressing scheme in use on various networks they may attach to.  I consider
it unreasonable to support the notion any endpoint can ignore local
policies.
 
>> As far as I can tell, this is the crux of the problem with
>> NEA - that in general it's simply unreasonable for a network
>> to demand that every host that connect to it conform to
>> arbitrary policies for configuration of those hosts.  IETF
>> should not be standardizing unreasonable expectations. And
>> even if the behavior is in some limited set of circumstances
>> reasonable (which is debatable), IMHO IETF should hesitate

You consider it unreasonable, I consider the alternative unreasonable.
Enforcing local policies is already happening, just with clunky tools and in
a non-standard manner.  NEA is one tool to help standardise the processes.

>> (I do sympathize with the notion that the biggest threats to
>> an enterprise network are from the hosts that connect
>> directly to it, and so it makes sense to concentrate efforts
>> for protecting the network at the points where those hosts attach to
>> the network) 

It is really about choices, to make a decision or choice, information is
necessary, NEA assists by providing information in a standard format, or
will.

>> The other problem I have with this charter is one that I
>> have with many charters these days - it presupposes a
>> particular design or architecture
>>   before the working group has actually met, when this
>> should be an engineering decision taken by the consensus of
>> the working group AFTER analysis of the problem space.

Understand what you are saying but can't see any solutions.

Darryl (Dassa) Lynch

---

From: Douglas Otis <[email-masked]>
Date: Tue, 24 Oct 2006 14:55:40 -0700

On Oct 24, 2006, at 12:38 PM, Mike Fratto wrote:

> For example, if an AV vendor called FOO wants to define an  
> attribute BAR for it's product, the NEA specifications should allow  
> for that without having to define a meaning for BAR or define an  
> action based on the presence or absence of BAR (which is a matter  
> of local policy). Nor are all products that implement NEA standards  
> required to support extensions by vendor FOO (also, a matter of  
> local policy).

Keith made a good point about a client not being trusted to retain  
private keys.  BAR must be verifiable to have meaning.  In the case  
of an OS updates or AV utilities, a service can retain private keys,  
exchange updates, monitors results, and present signed certificates  
carrying a relevant time-stamp.  The NEA server only needs to track  
desired posture certificate expiry without understanding the  
service.  The issuer, class, and time-stamp should provide adequate  
flexibility for existing schemes.   Checking standardized generic  
fields within certificates should simplify NEA related APIs.  The  
resources for remediation or client postures can be determined  
through the use of a non-expired issuer/class/user-host posture- 
certificates.  These certificates are provided by a separate external  
service.  The issuer/class name of the certificate would determine  
what is being checked.

issuer   / class  / time     / user-host
Foobar-OS/OS:SVR:I/1161043200/[email-masked]

-Doug

---

From: Keith Moore <[email-masked]>
Date: Tue, 24 Oct 2006 16:32:10 -0400

> policy.

---

From: Keith Moore <[email-masked]>
Date: Tue, 24 Oct 2006 17:23:09 -0400

> utility of the proposed NEA output. :P

has IESG decided to charter the group even before review is complete?

Keith

---

From: Ned Freed <[email-masked]>
Date: Tue, 24 Oct 2006 15:21:17 -0700 (PDT)

> of our efforts in IETF, not just what we intend.

Keith, I have two big problems with this position.

First of all, I have grave doubts our crystal ball is up to the task of
forseeing all unintended consequences of the protocol we develope. So while I
think some consideration of consequences is OK, we also need to keep in mind
that we collectively pretty much suck at predicting the future.

Second, consequences don't just attach to the roads we take, they also attach
to the roads not taken. When we say "no" to something it often ends up being
done in an ad hoc way that can potentially be far more damaging to the network
than had we created a standard with the proper security mechanisms,
applicability statements, and so on.

I also think NEA is a good example of something that will cause a lot less
problems if we do it right than if it is done in a bad and proprietary way. I
started hearing talk about implementating NEA-like mechanisms at several large
sites long before I ever heard of NEA. I therefroe believe that mechanisms to
do this are going to be developed and deployed no matter what the IETF does.
The only question is whether or not we're going to have a say in what gets
done. I really don't want to see a situation arise where I can't use, say, my
Linux laptop somwhere because the necessary secret handshake is some
proprietary glop that only Windoze boxes can do.

				Ned

---

From: Keith Moore <[email-masked]>
Date: Tue, 24 Oct 2006 17:23:09 -0400

Keith

---

From: Ned Freed <[email-masked]>
Date: Tue, 24 Oct 2006 15:21:17 -0700 (PDT)

Ned

---

From: Keith Moore <[email-masked]>
Date: Tue, 24 Oct 2006 23:24:38 -0400

>> unintended consequences of our efforts in IETF, not just what we
>> intend.
> 
> First of all, I have grave doubts our crystal ball is up to the task
> of forseeing all unintended consequences of the protocol we develope.
> So while I think some consideration of consequences is OK, we also
> need to keep in mind that we collectively pretty much suck at
> predicting the future.

I agree.  But we don't usually have to actually predict the future in
order to make ourselves aware of the potential pitfalls associated with
something that we're thinking about doing, and to take those pitfalls 
into account in a design.  In the case of NEA those pitfalls aren't too 
hard to figure out, but nothing has been proposed to address those 
pitfalls other than inconsequential wording suggestions about the scope 
of the WG.  The WG scope isn't the problem so much as the protocol 
itself.  Figure out a way to keep the protocol from doing harm, and I'll 
be much more interested.

> Second, consequences don't just attach to the roads we take, they
> also attach to the roads not taken. When we say "no" to something it
> often ends up being done in an ad hoc way that can potentially be far
> more damaging to the network than had we created a standard with the
> proper security mechanisms, applicability statements, and so on.

I agree also that this potential exists.  One of the things that really
bothers me about our WG creation process is that a lot of fundamental
decisions about direction of a particular effort tend to be made with
zero investigation of alternatives and little or no community input.
Whatever gets written into the charter is essentially carved in stone,
and sometimes the WGs don't even pay attention to whatever limitations 
are included in their charter - they just continue with whatever they 
started doing before the charter was approved.

In the case of NEA (as in so many other cases) we (the wider community) 
are being presented with this as a done deal - either take this charter 
(modulo minor wording changes) or leave it.  I sincerely believe that 
IETF can do something useful in this general space, but I also sincerely 
doubt that NEA is the right direction.  And yet, we're already asking a 
yes or no question when it really should be a "how can we address these 
problems?" question.  Is the wrong direction better than no contribution 
from IETF in this case?  It's not entirely clear, but I suspect that in 
this case the answer is no.

And yes, I'm also aware that historically when we charter a WG to study 
a problem and draft "requirements", they tend to wallow around and not 
produce much of any use.

> I also think NEA is a good example of something that will cause a lot
> less problems if we do it right than if it is done in a bad and
> proprietary way. I started hearing talk about implementating NEA-like
> mechanisms at several large sites long before I ever heard of NEA. I
> therefroe believe that mechanisms to do this are going to be
> developed and deployed no matter what the IETF does.

I agree.  But is that really so bad?  To me it isn't axiomatic that the 
Internet is better off if every application type that is widely deployed 
has a standard protocol.  DRM is a good example - until DRM can, at a 
minimum, preserve a balance of interests between the public and 
rightsholders, the Internet is better off without standards for DRM.  A 
similar argument can be made for NEA - there needs to be a way to 
preserve a balance between the rights of host owners and the rights of 
network owners.  (one particularly chilling scenario is for a network to 
use NEA to force every host that connects to it to implement a form of 
DRM that compromises the interests of the public)

  The only
> question is whether or not we're going to have a say in what gets 
> done. I really don't want to see a situation arise where I can't use,
>  say, my Linux laptop somwhere because the necessary secret handshake
> is some proprietary glop that only Windoze boxes can do.

IMHO, that is _more_ likely to happen if NEA is standardized than if 
there are some number of proprietary solutions.

Ketih

---

From: "Nelson, David" <[email-masked]>
Date: Wed, 25 Oct 2006 11:15:57 -0400

Keith Moore writes...

> yes, but it's clear that NEA is intended to be used, and
> will be used, as a mechanism to allow local networks to 
> implement policies based on machine configuration.

Yes, that is the crux of the matter.

> the question is whether if is a good thing for

Good thing for the Internet?  Eh?  I don't understand.  One may very
well posit a question about the tradeoffs between "safe computing" and
"personal freedom".  This is clearly a Layer 9 discussion, however.  :-)

---

From: "Mike Fratto" <[email-masked]>
Date: Wed, 25 Oct 2006 12:00:38 -0400

> there are some number of proprietary solutions.

Keith, your argument is that closed solutions are more likely to
support more OS's and platforms than an open systems? Do I have that
right?

Let me blather on about OS support. Microsoft NAP will support Windows
XP, Longhorn, and Vista. That's it for now. Cisco's NAC (not the NAC
Appliance, formerly Clean Access) support Windows, Linux, and they
claim MacOSX is coming with CSA. The vendors supporting the TCG TNC
break out heavily on the Windows side. Of the 21 NAC vendors I have
talked to in the last few months (It's what I do in my day job), all
of the products support Windows from W2K onward. 5 support Linux OS's
either using a Java applet or rpc. 10 suport MacOSX. Support for
devices other than workstations and servers is even worse, dare I say
it, virtually non-existent. You should check for yourself, but I think
you will find that the reality doesn't jibe with your opinion.

What vendors tell me is they will support those other OS's when they
see demand. In other words, when someone is willing to pay for it.
What customers will often do is either not demand support and do
without, or go elsewhere. Few vendors actually add support for other
OS's after a product ships unless it is roadmapped early on. Hopefully
the work of a group like the NEA, if it is formed, will allow agents
from one vendor talk to server from another.

Standardizing communications, either using existing protocols or
developing new protocols, that any developer can use and should in
theory, allow endpoints talk to other components is going to hinder
multi-os support? :) That is a good thing (tm).

---

From: Keith Moore <[email-masked]>
Date: Wed, 25 Oct 2006 13:30:14 -0400

> support more OS's and platforms than an open systems? Do I have that

no, my argument is that networks are less likely to impose draconian
policies on hosts if there is no standard interface by which they can
implement those draconian policies.  I'm not saying that no networks
will do this (as some are already doing this), but I do think it's less
likely that networks in will do this  - particularly access networks as
opposed to enterprise networks.  (most enterprise networks are a lost
cause already, IMHO, as too many enterprises have standardized on
windows and accepted the crippling of their networks that inevitably
follows.)

Keith

---

From: "Alan DeKok" <[email-masked]>
Date: Thu, 26 Oct 2006 14:40:57 -0400

Keith Moore <[email-masked]> wrote:
> implement those draconian policies. 

  The flies in the face of 20 years of computing history.  Customers
want a solution, and vendors will supply one to them.  If there is no
standards-based solution, vendors will supply proprietary solutions.
This goes for both desktop applications and networking protocols.

  The only way to guarantee a free and open network is to build it on
free and open standards.  The alternative is that vendors build
solutions for the majority OS, and tell everyone else "too bad".
There are any number of examples of this happening over the past 3
decades.  The solution to the proprietary problem is *always* open
standards.

  Make no mistake, people *will* be deploying access controls for
their network.  The only choice in front of us now is whether those
controls are proprietary, or standards-based.

> I'm not saying that no networks
> opposed to enterprise networks.

  I'm not sure any NEA variant will be applied to access networks.

  Alan DeKok.

---

From: "Alan DeKok" <[email-masked]>
Date: Thu, 26 Oct 2006 17:53:48 -0400

Keith Moore <[email-masked]> wrote:
> my argument is that standardization of NEA as it is currently understood 
> (whether through IETF or as a vendor de facto standard) would be a bad 
> thing for the Internet community because it would enable more networks 
> to impose draconian policies that were harmful to users.

  Again, what about the owners of the networks involved?  Or the
people who own the machines the users are using?  It is perfectly
reasonable for an enterprise to control access to its network.  Doing
so across heterogeneous platforms requires standards-based solutions.

  Forcing people to authenticate themselves through PPP before they
access an ISP's services can be viewed as a draconian limitation on
their freedoms.  So?  There's a gray area... where do we draw the line?

> for instance, if NEA were defined in such a way that the protocol was 
> incapable of asking any questions of a host that were not themselves 
> standardized, or were defined in such a way that there was no way for a 
> host to sign its answers to questions (so that any host would be capable 
> of lying).  but I have a hard time seeing IETF defining NEA in that way.

  Hmm... those requirements would effectively define NEA to be useless.

> yup.  pretend it's not a problem, and maybe the problem will go away.

  Let's turn of all network access controls, then.  No relationship
with an ISP?  No problem! The IETF says authenticating yourself is a
bad idea, go ahead, surf the net without paying!  Asking via DHCP to
be allocated the IP of the local DNS server?  No problem!  Allowing
the network admin to control the network he owns is a bad idea,
allocate away!

  There has to be a happy medium in between completely open and
completely locked down.  Likewise, there has to be a happy medium
between fact-based discussion and ridicule.

  Alan DeKok.

---

From: "Alan DeKok" <[email-masked]>
Date: Thu, 26 Oct 2006 20:19:39 -0400

Keith Moore <[email-masked]> wrote:
> I don't accept as an axiom that it's perfectly reasonable for an 
> enterprise to control access to its network based on whether the hosts 
> that attach to the network are willing to run spyware.

  Giving it a negative label isn't the same as asserting it has
negative value.  Companies already require certain virus scanners to
be installed, or VPN software, etc.

  I'm not saying you're wrong, I'm playing a bit of Devil's advocate
based on conversations with people who plan on deploying it, for the
reasons I've been discussing.

> there's a broad consensus that access controls at their current level of 
> precision are useful and generally beneficial.  there's not (afaik) a 
> broad consensus that access controls at the level of precision 
> facilitated by NEA are a good thing.

  Agreed.  Many of the benefits of NEA can be achieved by simple MAC
address filtering, guest portals, 802.1x, VLAN assignment, etc.
That's NETWORK access control, as opposed to controlling network
access based on the contents of the hosts hard drive.

> maybe NEA is going down a completely wrong path.  a major premise behind 
> NEA seems to be that networks can be made more secure if host operating 
> systems and applications are kept at a current patch level.

  I would phrase that as "kept at a KNOWN configuration".  And that's
not altogther wrong, or unreasonable.  I would be happy if I could get
notified when my core router's configuration changed unexpectedly...

> now you're proposing that other kinds of hosts be crippled 
> and essentially taxed to make up for the market's lack of foresight and 
> the gross negligence of that vendor.

  That is one take on it.  Another is that a legal issue is being
solved with a technical solution.  i.e. prove the software you're
running in a publicly traded company is all legal.  Solution?
Instrument every machine on the network to tell an inventory-control
system what it's running.  That looks a whole lot like NEA, albeit
with a completely different justification.  and it has nothing to do
with security, or OS, either. :)

> However, I also see numerous potential problems associated with a
> mechanism that tries to establish that trustworthiness by examining
> the configurations of those hosts.

  Yup.  The choices I've seen are to either have *zero* information
about what's on the network, or to implement a hokey mechanism to
maybe get some potentially untrustworthy information.  That's a bad
set of alternatives...

> And there's a very real potential for NEA doing more harm than 
> good unless those problems are understood and addressed.

  I think we can characterize the problem a little more
quantitatively.  Listing problems and solutions would be good, if I
can find the time...

  Alan DeKok.

---

From: yinhan <[email-masked]>
Date: Fri, 27 Oct 2006 08:42:03 +0800

----- Original Message ----- 
From: "Alan DeKok" <[email-masked]>
To: "Keith Moore" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Friday, October 27, 2006 5:53 AM
Subject: Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea)

> the network admin to control the network he owns is a bad idea,

 Ok, a user can get access to network through a and only one ISP access network.
 But, NEA should allow a host access to more than one enterprise network
 at the same time.

---

From: Keith Moore <[email-masked]>
Date: Thu, 26 Oct 2006 17:29:01 -0400

> This goes for both desktop applications and networking protocols.

I've been involved in IETF for not quite 20 years now, and I've seen 
this argument a lot during that time.  Some vendors want to standardize 
something that is demonstrably harmful, so as to increase the available 
market for such products - and the argument is made that IETF should 
help them do so because it's better if users have the choice of which 
vendor's products they can buy to hurt themselves.  I don't buy it.

my argument is that standardization of NEA as it is currently understood 
(whether through IETF or as a vendor de facto standard) would be a bad 
thing for the Internet community because it would enable more networks 
to impose draconian policies that were harmful to users.  IETF cannot 
really influence whether a particular vendor will be able to impose a 
proprietary standard on the market, but by choosing not to standardize 
NEA it could reduce the probability of having such a standard.  since my 
belief is that any standard (whether an IETF standard or a de facto 
vendor standard) for NEA brings with it significant potential for harm, 
I argue that IETF should not encourage such standardization by 
chartering an NEA working group - at least until we understand how to 
construct a solution that has minimal potential to do such harm.

in short, standardization of a protocol is not a good thing if the 
protocol being standardized does more harm to users than good.
standardization of NEA would allow an access network to impose 
proprietary solutions on users for other protocols or applications, and 
would thereby _reduce_ the ability of users to choose the protocols or 
applications that best suited their needs.

> free and open standards. 

yes.  and an NEA standard would the ability of users to choose free and 
open standards for everything except NEA.

> controls are proprietary, or standards-based.

even if something like NEA is inevitable, it does not follow that IETF 
should encourage it.  IETF should only encourage it if by encouraging it 
IETF can significantly reduce the potential for harm.  merely having NEA 
be an IETF standard does not significantly reduce the potential for harm 
-  concrete limitations in the NEA protocol are required to do that. 
for instance, if NEA were defined in such a way that the protocol was 
incapable of asking any questions of a host that were not themselves 
standardized, or were defined in such a way that there was no way for a 
host to sign its answers to questions (so that any host would be capable 
of lying).  but I have a hard time seeing IETF defining NEA in that way.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 26 Oct 2006 19:47:00 -0400

I don't accept as an axiom that it's perfectly reasonable for an 
enterprise to control access to its network based on whether the hosts 
that attach to the network are willing to run spyware.  The reason we 
have standards for networking is so that a wide variety of hosts can 
attach to those networks and a wide variety of applications can run on 
those hosts.  NEA defeats the very purpose of network standardization.

> their freedoms.  So?  There's a gray area... where do we draw the line?

like any other decision we make in IETF - we each choose what in our 
best personal judgment is best for the Internet as a whole.  whatever 
consensus results from that set of individual choices is what we end up 
with.  I'm arguing against standardizing spyware.  I don't think it's 
hard to understand why standardized spyware is a bad idea.

>   Hmm... those requirements would effectively define NEA to be useless.

indeed.  but if we are left to choose between expending effort to 
produce something useless, expending effort to produce something 
harmful, and not expending any effort, the last option seems like the 
best one.

>   Let's turn of all network access controls, then.

> completely locked down. 

maybe we've already reached it, or something close to it.

maybe NEA is going down a completely wrong path.  a major premise behind 
NEA seems to be that networks can be made more secure if host operating 
systems and applications are kept at a current patch level.  however we 
know from empirical evidence that the number of bugs in software tends 
(after an initial decrease) to increase over time (especially if new 
features are added, as is almost inevitable for any product that 
continues to be supported).  maybe investing in an NEA solution is like 
a cat trying to chase its tail - an investment of effort that is not 
only wasted but results in additional burdens that persist long after 
the investment is made.

we got ourselves into this mess because (a) the market chose a woefully 
insecure operating system as a de facto standard, (b) the vendor of that 
woefully insecure operating system failed to implement even the most 
basic of the security recommendations in MIME and other standards, and 
(c) that same vendor waited approximately 15 years after the rest of the 
industry (i.e. after the Morris worm) to start taking security 
seriously.  now you're proposing that other kinds of hosts be crippled 
and essentially taxed to make up for the market's lack of foresight and 
the gross negligence of that vendor.  yes, it's true that security holes 
exist on virtually all platforms, but no other platform has the 
combination of gross negligence and a monoculture that makes windoze 
such a fertile ground for malware.  (and maybe vista will be better, but 
that remains to be seen...we've heard that before)

--

let's back up a bit.

I would be the first to say that the biggest threat to an enterprise 
network is from the hosts that attach to it.  I'm very sympathetic to 
the idea that a network can to a useful degree protect itself, and other 
hosts on that network, from attack if it has better mechanisms to 
establish the trustworthiness of those hosts and the software that runs 
on those hosts.  However, I also see numerous potential problems 
associated with a mechanism that tries to establish that trustworthiness 
by examining the configurations of those hosts.  What I'm saying is, 
it's not acceptable to dismiss or overlook those problems.  They're 
real.  And there's a very real potential for NEA doing more harm than 
good unless those problems are understood and addressed.  We in IETF 
have accepted a responsibility to do what we believe is best for the 
Internet as a whole, and it's hard to understand how we can be doing 
that if we're deliberately overlooking problems that have this much 
potential for harm.