Subject: RE: [Nea] UPDATED: WG Review: Network Endpoint Assessment (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) 
> 
> 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
> 

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

---

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: Keith Moore <[email-masked]>
Date: Tue, 24 Oct 2006 12:51:42 -0400

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

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.

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

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

> Keith Moore <[email-masked]> wrote:
>   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.

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.

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

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

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

Keith

---

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 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: 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
> RADIUS practices.

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

Keith

---

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

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

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.

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

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

  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

PrecedenFrom [email-masked] Fri Oct 27 08:59:46 2006
From: "Alan DeKok" <[email-masked]>
To: Keith Moore <[email-masked]>
Date: Tue, 24 Oct 2006 14:29:17 -0400
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [Nea] UPDATED: WG Review: Network Endpoint Assessment (nea) 

  Alan DeKok.

---

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

"Mike Fratto" <[email-masked]> wrote:
> 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.

  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.

ce: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:[email-masked]?subject=unsubscribe>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>,
	<mailto:[email-masked]?subject=subscribe>
Errors-To: [email-masked]

"Mike Fratto" <[email-masked]> wrote:
> 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.

  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: "Alan DeKok" <[email-masked]>
Date: Tue, 24 Oct 2006 14:35:43 -0400

> 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: "Alan DeKok" <[email-masked]>
Date: Tue, 24 Oct 2006 12:28:33 -0400

> that connect to it conform to arbitrary policies for configuration of 

  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?

  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.

---

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

Alan DeKok.

---

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

Alan DeKok.