Subject: RE: [Nea] IETF67 NEA WG Meeting summary

From: "Fergie" <[email-masked]>
Date: Tue, 14 Nov 2006 07:12:54 GMT

-- "Darryl \(Dassa\) Lynch" <[email-masked]> wrote:

>Couldn't the solution be as simple as allowing the client nodes the option
>of deciding what information they are prepared to make available and the
>network then using what is available to decide how they should be treated?
>If not enough information is provided the node can be shunted off for some
>form of remediation, if the network deems it has enough information
then the
>node can be allowed in.
>
>Both parties have choices then, what information to provide and what is
>required to be accepted.  
>

It is my understanding from the WG charter that a primary benefit
of NEA is that an administrative entity should be able to determine
the posture of an end-system without the end-systems consent (of
course, there may indeed be reasons why the opposite would be true,
too).

It would seem to me that if the end-system has the ability to
nullify that ability, then NEA would be pretty worthless.

In any event, the charter says:

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

Having read that, it would appear the issue of assessing posture
is one that is done between the the Posture Validator(s) and the
Posture Broker (where Posture attributes are aggregated), not
the NEA end-system (client) directly.

- ferg

--
"Fergie", a.k.a. Paul Ferguson
 Engineering Architecture for the Internet
 fergdawg(at)netzero.net
 ferg's tech blog: http://fergdawg.blogspot.com/

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

---

From: Khaja Ahmed <[email-masked]>
Date: Mon, 13 Nov 2006 23:40:04 -0800

It seems certain that access to the network, at least from some ISPs,
will be conditional upon providing health information.  That is the
prerogative of the ISP.  

Users who do not want to provide ISPs information about their OS, patch
level, AV used, etc. will have to use ISPs who do not require this.  

Khaja

-----Original Message-----
From: Fergie [mailto:[email-masked]] 
Sent: Monday, November 13, 2006 11:13 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Nea] IETF67 NEA WG Meeting summary

then the

- ferg

---

From: "Marcus Leech" <[email-masked]>
Date: Tue, 14 Nov 2006 08:25:04 -0600

> level, AV used, etc. will have to use ISPs who do not require this.  
For any such ISP, I'd simply assert to them that I'm running whatever OS 
it is that
  doesn't require "anti virus configuration".  I imagine that ISPs that 
adopt such policy
  will let various Linux and Unix machines to "sail right through", 
which means there'll
  be tools for Windows boxes to make them appear to be Linux machines, 
precisely to
  get around draconian and ill-considered policies of the ISPs.

---

From: Keith Moore <[email-masked]>
Date: Tue, 14 Nov 2006 09:33:52 -0500

> course, there may indeed be reasons why the opposite would be true,

well, that's completely unacceptable.  affirmative consent is a 
necessary condition, though not a sufficient one.

---

From: Keith Moore <[email-masked]>
Date: Tue, 14 Nov 2006 09:35:14 -0500

> will be conditional upon providing health information.  That is the

perhaps, but nothing says that IETF has to be a party to such nonsense 
by standardizing a mechanism to let them do so.

remember, in IETF we're required to make decisions as to what is best 
for the internet as a whole, not to give ISPs whatever they want.

---

From: "Stephen Hanna" <[email-masked]>
Date: Tue, 14 Nov 2006 09:53:36 -0500

I think we're drifting back into charter discussion.
The IETF has already chartered a group to standardize
a mechanism 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".
That's NEA.

Instead of debating whether IETF should do this, let's
redirect the discussion to how the assessment can address
privacy and other concerns. For instance, I think it is
better for the NEA server to request specific attributes than
for the NEA client to simply send all the info it has. Also,
the NEA server should authenticate itself to the NEA client
before the NEA client is asked to send attributes.

Keith, would such a system address your concerns at all?
If not, can you suggest some approaches that would?

Thanks,

Steve

---

From: "Nelson, David" <[email-masked]>
Date: Tue, 14 Nov 2006 10:01:18 -0500

Keith Moore writes...

> remember, in IETF we're required to make decisions as to
> what is best for the internet as a whole, not to give ISPs 
> whatever they want.

This thread seems to be a "Layer 9" discussion about the threat that NEA
might pose to personal freedom.  Interesting, on a philosophical level,
but not helpful in moving the WG toward its charter goals, I think.

There is a reason why NEA was targeted at enterprise environments.  In
the workplace your personal freedoms are somewhat limited.  What you do
with corporate assets, on the corporate premises, on corporate time and
in contact with fellow employees, is much more subject to regulation by
your employer than your behavior in public or at home.

I infer from your e-mail address that you may possibly work in an
environment in which "academic freedom" is at play.  Such notions don't
translate very well to the commercial work place.

In terms of the intrusiveness of NEA protocols and agents, I can only
say that they are no more intrusive than SMS (MS System Management
Services) the IT "Big Brother" application that my company uses to keep
tabs on my laptop.

So, I think we should understand that there *is* a valid set of use
cases for NEA, within the scope defined by the charter, and get on with
the business of the WG.  The fact that ISPs might "abuse" these
protocols is not a reason to abstain from standardizing them, IMHO.

---

From: Keith Moore <[email-masked]>
Date: Tue, 14 Nov 2006 10:02:40 -0500

> endpoint has been updated to satisfy the posture requirements".

uh, no..  the IETF has chartered a group to develop requirements for 
such a mechanism, not the mechanism itself.

the current discussion is entirely relevant to developing requirements.

> Keith, would such a system address your concerns at all?

for reasons already given, no.

> If not, can you suggest some approaches that would?

I don't actually know if there is a reasonable way to do what NEA wants 
to do, but I've already suggested one alternative that might be worthy 
of exploration - which is to NOT let the network ask questions about 
multiple specific attributes, but to only let it present a set of 
requirements and let the host tell it whether it meets those requirements.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 14 Nov 2006 10:10:57 -0500

> but not helpful in moving the WG toward its charter goals, I think.

strongly disagree.  the charter is for the WG to develop requirements 
for the NEA protocol.  those requirements necessarily include security 
considerations.

and the discussion has to be conducted according to IETF rules.

> your employer than your behavior in public or at home.

when the same computers are plugged into multiple environments, it 
hardly matters.  even if you accept that the enterprise network can ask 
anything it wants of its own computers, it is necessary that the NEA 
protocol not be a security risk to the host when that host connects to 
other networks.

> translate very well to the commercial work place.

IETF protocols need to work for the whole internet, not just corner cases.

> Services) the IT "Big Brother" application that my company uses to keep

yes there are lots of bad things in the world.  the fact that they exist 
does not compel IETF to standardize them.

> protocols is not a reason to abstain from standardizing them, IMHO.

again, strongly disagree.  the introduction of NEA to a host presents a 
security risk to that host and to its owner.  it's entirely appropriate 
and necessary to discuss ways of ameliorating those security risks, and 
to evaluate whether NEA can be done at all in such a way that does not 
create greater risks than the risks it is itself trying to ameliorate.

Keith

---

From: "Nelson, David" <[email-masked]>
Date: Tue, 14 Nov 2006 10:23:29 -0500

Keith Moore writes...
 
> again, strongly disagree.  the introduction of NEA to a host 
> presents a security risk to that host and to its owner.

Ah, but the charter scope applies to hosts *owned* by enterprises.  I
concede that there may be legitimate personal privacy considerations
were one to take one's personally owned host to work and attempt to
connect to the enterprise network.  There is a simple remedy to that
security concern: don't do it.  Keep your personal machine at home and
use your work machine at work, or for working while at home or on the
road.

As to your concerns about how your ISP (or some other public or
quasi-public service provider) may abuse the NEA work product to intrude
on your personal privacy, on your personal host, that is beyond the
scope of NEA.  Yes, the protocol may contain elements to address
personal privacy concerns.  As has been stated previously in this thread
(most clearly be Uri Blumenthal), your host may refuse to participate in
NEA, in which case the network provider may refuse to grant your host
network access, or may restrict network access in some way.

Anything beyond this level of protection for personal privacy is beyond
the scope of NEA.  It may be fodder for consumer protection legislation,
but that is certainly not the concern of the IETF.

---

From: "Stephen Hanna" <[email-masked]>
Date: Tue, 14 Nov 2006 10:25:55 -0500

Discussion of NEA requirements is certainly in scope.
Discussion of whether IETF should work on NEA is not.
Discussion of concerns about NEA are certainly in
scope, especially if we can translate them into
specific requirements.

Thanks for your concrete suggestion. Maybe you should
try to translate your concerns into specific requirements.
For instance, NEA clients should not be required to
disclose attributes about their own configuration.

Sorry to be a pain here. I'm just trying to turn our
conversation in a more fruitful direction.

Thanks,

Steve

-----Original Message-----
From: Keith Moore [mailto:[email-masked]] 
Sent: Tuesday, November 14, 2006 9:03 AM
To: Stephen Hanna
Cc: Khaja Ahmed; [email-masked]
Subject: Re: [Nea] IETF67 NEA WG Meeting summary

requirements and let the host tell it whether it meets those
requirements.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 14 Nov 2006 10:26:26 -0500

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

> Ah, but the charter scope applies to hosts *owned* by enterprises. 

I've addressed this topic in a reply to someone else's message, so I 
won't repeat it here except to say that I strongly disagree for reasons 
given elsewhere.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 14 Nov 2006 10:29:40 -0500

> Discussion of whether IETF should work on NEA is not.\

disagree.  one possible output of a requirements discussion is that 
there is no way to meet the requirements - that the solution space for 
the requirements is the null set.  a requirements discussion that does 
not admit that possibility is dishonest and useless.

> conversation in a more fruitful direction.

me too.  but maybe we have different ideas as to what is fruitful?

Keith

---

From: "Stephen Hanna" <[email-masked]>
Date: Tue, 14 Nov 2006 10:34:12 -0500

> not admit that possibility is dishonest and useless.

That could be an output of the requirements discussion. But we need
to have the requirements discussion first. I think that would be
fruitful. And it's the only thing that's in scope for us at the moment.
So let's talk about requirements. Do you agree that would be fruitful?

Thanks,

Steve

-----Original Message-----
From: Keith Moore [mailto:[email-masked]] 
Sent: Tuesday, November 14, 2006 9:30 AM
To: Stephen Hanna
Cc: Khaja Ahmed; [email-masked]
Subject: Re: [Nea] IETF67 NEA WG Meeting summary

Keith

---

From: "Nelson, David" <[email-masked]>
Date: Tue, 14 Nov 2006 10:38:27 -0500

Keith Moore ...

> disagree.  one possible output of a requirements discussion is
> that there is no way to meet the requirements - that the solution
> space for the requirements is the null set.

Well, from a pedantic perspective this is certainly true.

However, this is the IETF.  "E" is for "Engineering".  Engineering is
about producing useful solutions to problems.  It is clear to me that
NEA is addressing a valid problem.  I think that attempting to "rig" the
requirements so as to admit no feasible solution is effectively an
attempt to subvert the WG chartering decision, and to be obstructive.

Let's accept that there *is* a valid problem, and work to devise a
reasonable set of requirements to solve the problem and provide
generally acceptable security and privacy protection.

---

From: Keith Moore <[email-masked]>
Date: Tue, 14 Nov 2006 10:52:56 -0500

> NEA is addressing a valid problem. 

"the problem" is valid.  whether NEA is a valid solution is a different 
question.

of course, the NEA WG isn't chartered to solve "the problem", it's 
chartered to develop requirements for one possible kind of solution to 
"the problem".

(IIRC, the first step in the engineering process is stating the problem. 
so maybe we should start there before even discussing requirements?)

> I think that attempting to "rig" the requirements so as to admit no feasible solution is effectively an

I'd agree, if anyone were doing that.

Keith