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

From: "Blumenthal, Uri" <[email-masked]>
Date: Tue, 14 Nov 2006 08:55:08 -0500

>>> to me NEA seems pointless unless the responses are signed.

In one word - yes.
 
>> The responses could be certificates signed by a third-party service.
>> The affirmative answer would be a time-stamp of the service event
still
>> considered valid by the server.  This service might have a
certificate
>> exchange layer wrapped around an update mechanism, for example.
>
>the third-party service is an interesting idea if it can be used to
hide 
>details of my configuration from the network while still certifying to 
>the network that my configuration is (within broad terms) okay.  

It certainly can. However if it's an enterprise-belongin computer that
seeks a network admission - why would you prefer to disclose your
configuration to a third party over your "native" corporate IT?
Understanding that if ever such a third party evolves, it will certainly
be bound by legal agreements to disclose whatever "violations" of
whatever policy it discovers?

>still, 
>I'm not sure I'd trust any third-party to know precisely what is on my 
>machine and not misuse that information or disclose it to parties with 
>whom I don't want to share it.  

That's a good question. Who is it that you know you don't want to share
the info with? Your employer? Your government? Your ISP? And who is it
that you don't mind sharing your "internal details" with? Somebody like
VeriSign? IRS?

In a corporate environment, it's a reasonably clear cut. IT "o3ns" the
machines, and has both the legal right and the burning desire to know
what exactly is going on on them. NEA will help them know more prior to
even letting the machine on the intranet.

Outside of the corporate - it becomes really interesting.

>I'm certain that I wouldn't trust an antivirus software vendor,
>for instance, with that information - because widespread 
>investment of this kind of trust in a few such vendors would 
>make them very tempting targets for some kinds of espionage.

OK, OK - but much more important question is who you WOULD trust! Can
you think of such a party?

>> The NEA server could indicate required services by exchanging sets of
>> certificates using a hostmaster identifier.  The client would need to
>> offer one certificate with their identifier for each set.
>
>this seems too intrusive to me.  I don't want a network to know 
>precisely which services I have installed on my machine.

I can reasonably imagine a set of "prohibited" services and a set of
"required" services, whose corresponding absence and presence is to be
ascertained. I'm sure that corporate IT would indeed want to know more -
like "all the installed services".

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

---

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

> like "all the installed services".
Services like "make" and "gcc" would be considered "prohibited" in some 
environments.
  Dangerous tools, those...

The problem is that as the draconian measures become more intrusive, the 
motivation to get around
  them becomes greater and greater.  I expect this to turn into a "spy 
vs spy" game, in the same way
  that SPAM and DRM have grown into a "spy vs spy" game.   There's no 
endgame.

Turing Completeness is the enemy of all NEA/TCG-like efforts.  I would 
assert that useful computing
  devices that are without Turing Completeness, are not useful computing 
devices.   But removing
  TC-ness is the only conceivable way of short-circuiting the "spy vs 
spy" nature of the problem
  at hand...

---

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

>> the third-party service is an interesting idea if it can be used to hide 

that's a corner case.  a more general case is that the computer belongs 
to someone (maybe an enterprise, maybe not) and it probably connects to 
multiple networks, only one or two of which are owned by the same party 
that owns the computer.  the protocol has to do the right thing no 
matter which network the computer is connected to.

> whatever policy it discovers?

right - the third party might be required by a government, for instance, 
to look for things it considers illegal and subversive.  that's why I'm 
skeptical of the viability of third parties.

> that you don't mind sharing your "internal details" with? Somebody like

all good examples.

> machines

not necessarily.  I know of companies that require their employees to 
buy their own laptops, but they still insist on controlling the 
configurations of those machines if they attach to the network.

> you think of such a party?

offhand, no.

> like "all the installed services".

I'm sure they would.  I'm also sure that it's not acceptable to give it 
to them.

Keith

---

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

I'm afraid that our charter says "Detecting or handling [lying]
endpoints is out of scope of the NEA WG." A brief mention of
this topic is OK but we shouldn't spend too much time on it,
especially since the topic was thrashed over only last month
during our chartering discussion.

Clearly, there are differing opinions about whether technology
for detecting or handling lying endpoints is feasible or desirable.
But in either case, it's out of scope for NEA. We are supposed to
"focus on attributes useful for assessing posture of those endpoints
reporting accurate information." That is, we're supposed to focus
on helping healthy endpoints stay healthy.

Thanks,

Steve

-----Original Message-----
From: Marcus Leech [mailto:[email-masked]] 
Sent: Tuesday, November 14, 2006 8:31 AM
To: Blumenthal, Uri; [email-masked]
Subject: Re: [Nea] IETF67 NEA WG Meeting summary

motivation to get around

devices.   But removing

---

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

I seem to be Mr. Charter these days.

Our charter says "NEA is applicable to computing
enterprise environments, 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."

So the corporate environment described by Uri is not
a corner case. It's the only case we're allowed to consider.
Let's stop talking about fascist governments and such.
We must focus on a corporate environment where endpoints
are owned by or expect to conform to the policies set
forth by the network owner.

Thanks,

Steve

-----Original Message-----
From: Keith Moore [mailto:[email-masked]] 
Sent: Tuesday, November 14, 2006 8:57 AM
To: Blumenthal, Uri
Cc: [email-masked]
Subject: Re: [Nea] IETF67 NEA WG Meeting summary

hide 

all good examples.

offhand, no.

Keith

---

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

> endpoints is out of scope of the NEA WG." 

I fail to see what this has to do with Uri's message.

---

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

My email was a response to Marcus' email not Uri's.
You have removed the text I was responding to, which
talked about the "spy vs spy" nature of the problem,
where endpoints may lie about their configuration
and NEA servers might want to detect such lies.

Thanks,

Steve

---

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

> a corner case. It's the only case we're allowed to consider.

wrong.  it _is_ a corner case.  it might be the anticipated use case for 
NEA but it's not the only case that NEA will have to deal with, because 
  many hosts that have NEA installed will be used to connect to multiple 
networks.  the security risks associated with installing an NEA server 
on your machine and connecting to other networks have to be considered 
in a discussion of NEA requirements.

I'll give you an example of how this impacts the protocol.  let's say 
that we declare that a machine has only one owner and that any 
particular interface on the machine is either connecting to a network 
owned by the same party or a different party.  NEA should only come into 
play if the two parties are the same.  we can design a protocol to 
enforce those constraints.  the protocol could require that NEA requests 
be signed with a private key, and that NEA server implementations only 
respond to requests that are signed with a private key that matches the 
public key of the owner as configured on the machine, and furthermore 
than NEA server implementations MUST NOT support more than one owner. 
that _might_ solve the problem.

(though I doubt it because there will generally be a need to support 
multiple key pairs at any one time so that the single owner can do 
rollover from old to new keys.  but maybe there's a way around this)

> Let's stop talking about fascist governments and such.

I strongly object to your attempt to discourage this group from 
considering valid risks associated with NEA, and sincerely believe that 
by doing so you are violating IETF policy.

Keith

---

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

If there are legitimate risks to deploying NEA protocols,
then I'm perfectly OK with discussing those. But I think
those discussions must happen in the proper context.
We should not be debating whether IETF should do NEA.
Instead, we should be discussing what risks arise from
the use of NEA protocols and how those risks can be addressed.

Your discussion below about the need for NEA clients to
authenticate NEA servers before revealing configuration
information is a great example of a constructive idea
for addressing the risks of NEA protocols.

Would it be best to step back and try to enumerate the
risks that can arise from the use of NEA protocols?

Thanks,

Steve

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

Keith

---

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

> the use of NEA protocols and how those risks can be addressed.

at some point it is necessary to assess whether NEA can be designed and 
implemented in such a way that it ameliorates more risks than it 
introduces.  balance of risk is the right way to assess this, I think. 
though there's sort of a problem in that NEA might ameliorate risks for 
the network while introducing new risks for the user.

again, I think it's impossible to have a constructive discussion about 
requirements without honestly considering the possibility that a 
reasonable set of requirements results in a null solution space. 
artificially relaxing the requirements (in other words, overlooking 
known problems) so that the solution space is non-null is dishonest and 
doesn't serve the interests of the internet.

so I don't accept the constraint on debate that we shouldn't consider 
whether IETF should do NEA.  and my guess is that the reason we're only 
chartered to do requirements at this stage is that IESG hasn't yet 
decided whether we should do NEA.

our primary concern is to to do what's best for the Internet as a whole, 
not to justify NEA if after analysis it doesn't turn out to make sense. 
  that said, I do believe that the greatest risk to access networks is 
from the hosts that connect to them, and I am interested in 
understanding what mechanisms can be devised to ameliorate those risks. 
  I want to have an open mind about NEA, not to shoot it down 
preemptively.  but I want NEA proponents to have open minds also.

> risks that can arise from the use of NEA protocols?

that might be useful.  though I also think we need to have some less 
structured discussion so that everyone understands that these risks are 
real.

Keith

---

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

> OK, good. Let's talk about requirements. In the end, if we find
> (or the IESG finds) that our requirements cannot be met then
> it won't make sense to do any more NEA work in IETF. In the context
> of a requirements discussion, I have no problem with having an
> open discussion about risks introduced by NEA.

okay, here are concrete suggestions for the first couple of 
requirements.  my guess is that this is too much precision too soon, but 
we'll see how it goes.

1. NEA MUST NOT expose information about a host to any party other than 
the owner of that host.   (and a host has at most one owner)

(an alternative would be that NEA can only expose details about a host's 
configuration to host's owner, but that it could expose yes/no 
information in the sense of "I do/don't meet the requirements of your 
network" to parties other than the host's owner.  which might make NEA 
more broadly applicable, but might also open up a big can of worms 
and/or be out of scope for this WG's current charter.)

2. The NEA protocol MUST take reasonable action to ensure that 
information about the host being transmitted via the NEA protocol is not 
  disclosed to third parties who have access to the information 
presented on the wire.  (e.g. the NEA protocol exchange must be encrypted)

---

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

Thanks,

Steve

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

Keith

---

From: Khaja Ahmed <[email-masked]>
Date: Tue, 14 Nov 2006 21:03:27 -0800

Would you be OK with the following amendment to the first requirement?
	NEA MUST NOT expose information about a host to any party other
than
	the owner of that host or to parties authorized by the owner.

Khaja

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

we'll see how it goes.

  disclosed to third parties who have access to the information 
presented on the wire.  (e.g. the NEA protocol exchange must be
encrypted)

---

From: Keith Moore <[email-masked]>
Date: Wed, 15 Nov 2006 01:20:05 -0500

> 	NEA MUST NOT expose information about a host to any party other than

no, I'm not okay with that.  the problem is that people can be coerced 
into giving up their privacy if the protocol makes it easy for them to 
do that.

I'll give an example: HTTP cookies.  they weren't intended to be used as 
a means to track user behavior.  they ended up being used that way 
because (a) they were not designed with due concern for privacy and (b) 
many implementations didn't bother implementing the protections 
specified by the standards.  instead they gave users a yes or no switch: 
"do you want to enable cookies or not?"  and a lot of web sites also 
gave users a yes or no option: "either enable arbitrary cookies or don't 
use our web site".  and the web sites didn't adhere to the rules for 
using cookies either.

what I conclude from the cookie experience is that when the server and 
host don't have the same owner, the server (i.e. the network) can't be 
trusted to not abuse the ability to query hosts for fine-grained 
information if NEA gives it that ability, and NEA client (i.e. host) 
implementors can't be trusted to implement appropriate privacy 
safeguards for clients if the protocol itself isn't designed in such a 
way as to make it unlikely that networks will be able to demand such 
information from clients.

regarding NEA: what I might be okay with is giving authorized 
third-parties yes or no assurance that the host meets or does not meet 
their policies, without giving them fine-grained detail about what is 
installed on the host.  so the owner of a host could get details about 
why a host did or did not fit within a particular network's policy, but 
the network (if owned by another party than the owner of the host) could 
only get yes or no information.   I would like to see this option 
examined further.

Keith

---

From: Pekka Savola <[email-masked]>
Date: Wed, 15 Nov 2006 10:55:58 +0200 (EET)

On Tue, 14 Nov 2006, Keith Moore wrote:
> 1. NEA MUST NOT expose information about a host to any party other than the
> owner of that host.   (and a host has at most one owner)
> 
> configuration to host's owner, but that it could expose yes/no information in
> the sense of "I do/don't meet the requirements of your network" to parties
> other than the host's owner.  which might make NEA more broadly applicable,
> but might also open up a big can of worms and/or be out of scope for this WG's
> current charter.)

Actually, I think in some contexts this might need to be stronger than 
this.  For example, even if an employee's laptop is owned by the 
enterprise, some legislations (at least here in Finland) there are 
prohibitions on what the employer may (or may not) do e.g., to track 
the employee or employee's usage.

For example, it would be illegal to track which websites the user 
surfs to ("to ensure productive use of working time"), the amount of 
time keyboard/mouse is idle ("the user is not doing anything at work") 
etc.

It is not clear to me to what extent this would need to be reflected 
in the NEA protocol or requirements.  Nonetheless 'only the owner can 
get full information' might be too much in some cases.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: "Darryl \(Dassa\) Lynch" <[email-masked]>
Date: Wed, 15 Nov 2006 21:45:42 +1100

Keith Moore wrote:
<snip>
>> regarding NEA: what I might be okay with is giving
>> authorized third-parties yes or no assurance that the host
>> meets or does not meet their policies, without giving them
>> fine-grained detail about what is installed on the host.  so
>> the owner of a host could get details about why a host did
>> or did not fit within a particular network's policy, but the
>> network (if owned by another party than the owner of the host) could

I don't imagine this is totally out there although I can see it may require
some careful consideration with respect to how the attributes may follow
this and still be useful and provide enough information for judgements to be
made.

An example I can imagine is where a NEA enabled node attempts to connect and
is requested to provide information on the current anti-virus status.  A yes
or no answer can only be given where the policy is known and then a
comparison made at the node to determine if the policy is met or not.  This
shifts the onus of providing additional information to the network and away
from the node which exposes some information that may be gleened for refined
attack vectors.

My personal choice is to limit the amount of information exposed by the
network and leave the onus on the node to provide more as they are the ones
requesting access.

If the attributes are defined carefully it should be possible to reach a
reasonable compromise.

Darryl (Dassa) Lynch

---

From: "Stephen Hanna" <[email-masked]>
Date: Wed, 15 Nov 2006 08:25:20 -0500

This comment highlights the fact that there is a lot of
variation in what information should be disclosed.

On military networks, it's entirely appropriate for the
network to require a complete and verifiable inventory
of software on the endpoint (maybe also information about
recent activity, configuration, etc.). The network will
probably not be willing to divulge its access policies.

On open access networks, no information should be
required from the endpoint. Any participation in NEA
should be purely voluntary and can involve the network
sending its latest policy to the endpoint, which may
respond at its discretion. No enforcement involved.

Commercial networks lie somewhere in between. They may
be willing to grant Internet access if no information
is available on the endpoint. Access to corporate resources
will probably require some information and the amount
of information required will probably depend on the
sensitivity of the resources to be accessed (and on
local regulations, as Pekka points out).

It seems clear to me that this is an areas for local
policy. The endpoint should have a policy about what
information it is willing to disclose and to whom.
The network should have a policy about what information
it requests, whether it will divulge its policies,
and what access it is willing to grant. The requirement
for the NEA standards should be that they describe the
security and privacy concerns inherent in this system,
describe how those concerns can be addressed, and require
the protocols to include features that enable the endpoint
and network to implement whatever policy they want. Then
the endpoint and network owners can configure their
policies with confidence. One endpoint owner may disable
NEA. Another may configure a policy of "Tell nothing
but accept advice from my ISP". Others may decide to
disclose OS patch info to their corporate servers only.
The military owner may configure a policy to disclose
a full inventory but ONLY to authorized servers.

For us to decide on a one-size-fits-all policy in this
area would be impossible. If we're concerned about naive
users, we can require that endpoints ship with NEA disabled
and require explicit approval and administrative privileges
to enable it or configure policy.

Thanks,

Steve

-----Original Message-----
From: Pekka Savola [mailto:[email-masked]] 
Sent: Wednesday, November 15, 2006 2:56 AM
To: Keith Moore
Cc: [email-masked]
Subject: [Nea] privacy: exposing information to owner

> configuration to host's owner, but that it could expose yes/no
information in

---

From: Keith Moore <[email-masked]>
Date: Wed, 15 Nov 2006 09:31:09 -0500

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

> This comment highlights the fact that there is a lot of variation in
> what information should be disclosed.
> 
> On military networks, it's entirely appropriate for the network to
> require a complete and verifiable inventory of software on the
> endpoint (maybe also information about recent activity,
> configuration, etc.). The network will probably not be willing to
> divulge its access policies.
> 
> On open access networks, no information should be required from the
> endpoint. Any participation in NEA should be purely voluntary and can
> involve the network sending its latest policy to the endpoint, which
> may respond at its discretion. No enforcement involved.
> 
> Commercial networks lie somewhere in between. They may be willing to
> grant Internet access if no information is available on the endpoint.
> Access to corporate resources will probably require some information
> and the amount of information required will probably depend on the 
> sensitivity of the resources to be accessed (and on local
> regulations, as Pekka points out).
> 
> It seems clear to me that this is an areas for local policy.

I don't agree with your assessment.  Just because a network to which a
host attaches might be run by (say) the military doesn't mean that it's 
reasonable for an Internet standard to facilitate an arbitrary level of 
surveillance or even to give the user a choice about how much 
surveillance is allowed.  I don't see any way to do this that will not 
result, in practice, in users being forced to compromise their privacy 
far beyond that which is reasonable.

> The endpoint should have a policy about what information it is
> willing to disclose and to whom. The network should have a policy
> about what information it requests, whether it will divulge its
> policies, and what access it is willing to grant. The requirement for
> the NEA standards should be that they describe the security and
> privacy concerns inherent in this system, describe how those concerns
> can be addressed, and require the protocols to include features that
> enable the endpoint and network to implement whatever policy they
> want. Then the endpoint and network owners can configure their 
> policies with confidence. One endpoint owner may disable NEA. Another
> may configure a policy of "Tell nothing but accept advice from my
> ISP". Others may decide to disclose OS patch info to their corporate
> servers only. The military owner may configure a policy to disclose a
> full inventory but ONLY to authorized servers.

Strongly disagree with all of the above.  For the most part, users
aren't sophisticated enough to determine what the policies on their
hosts should be.  This makes them vulnerable to invasion of privacy -
first as individuals, as naive users succumb to pressure from networks 
to grant more access than is necessary - and then market forces force 
even the more sophisticated users to either accept this privacy erosion 
for themselves or have their access severely limited.  I've seen it 
happen more times than I can count.

> For us to decide on a one-size-fits-all policy in this area would be
> impossible.

perhaps, but that might mean that there is no reasonable solution to the
NEA approach, and a very different approach is needed.

> If we're concerned about naive users, we can require that endpoints
> ship with NEA disabled and require explicit approval and
> administrative privileges to enable it or configure policy.

doesn't solve the problem.

Keith

---

From: "Jochem van Dieten" <[email-masked]>
Date: Wed, 15 Nov 2006 15:47:40 +0100 (CET)

Stephen Hanna said:
> network are owned and/or expected to conform to the policies set
> forth by the organization that owns and operates the network. All
> other

I believe this wording of the charter does extend the scope of NEA
beyond the corporate environment: enterprise is more then just
corporate. This charter covers the academic environment where students
bring their own laptop, but connect to the enterprise network of their
institution where they are expected to conform to the policies set
forth by that institution.

In this environment it is also not realistic to expect users to "keep
your personal machine at home and use your work machine at work": the
home network in the dorm is the same enterprise network as the network
at work. And let's not forget that in this environment we already see
NEA-like solutions being deployed as we speak.

So unless I am misunderstanding the charter and the academic
environment is explicitly not covered, I do believe Keith's concerns
regarding the risk NEA poses to privacy are accurate and we should
formulate requirements to safeguard that privacy.

Jochem

---

From: "Mike Fratto" <[email-masked]>
Date: Wed, 15 Nov 2006 11:33:49 -0500

On 11/15/06, Keith Moore <[email-masked]> wrote:
> I don't agree with your assessment.

But that is the scope of the charter. Enterprises, including
corporations, academic institutions, non-profits, and govenment
entities, where the network is wholly owned by the enterprise have the
right within local laws to ask what ever they want. That is thier
local policy. You as a user, say a contractor, guest, or employee,
have the right to accept or decline thier policy. That is your local
policy. If you are on a remote network and you computer is controlled
by your enterprise, they have the right to say what will and will not
be disclosed. That is a matter for your employers policy. The output
of the NEA needs to provide ways to account for the different stake
holders without dictating local policies.

Besides, this is nothing new. Having guest users agree to an AUP is
fairly standard practice. The NEA simply facilitates the granting of
access.

> > policies, and what access it is willing to grant.
>
> hosts should be.

That is beside the point entirely. While vendors should make it easy
for end users to make a determination about what data to share, there
is no reason to compell them to do so. And even if there was a reason
to compel them to do so, then your talking UI features which I think
are out of scope. Perhaps a best practices document would be helpful
to provide guidance in cases like this, but they are not show
stoppers.

> doesn't solve the problem.

Becuase there is no problem to solve. Accpetance of interrogation is a
matter of agreeing to local policies. If the network policy is to
assess a host and your, or your employers policy is to refuse
assessments, then it is up to the network owner to decide what to do
with your computer. There is no implicit right for a computer user to
connect to a network.

---

From: "Mike Fratto" <[email-masked]>
Date: Wed, 15 Nov 2006 11:38:46 -0500

> only get yes or no information.   I would like to see this option

Nothing is gained here regarding privacy. A validation server could
glean what is installed by asking a series of questions and inferring
the response. for example:

Q: do you have software A, B, or C?
A: No
Q: do you have software D?
A: Yes

Ergo, host has software D.

And if your so concerned about privacy, the network operator has a
right to keep thier policies private so as not to give potential
attackers specific knowlege about thier protective measures.

I think a reasonable solution is one that Steve offered in the other
thread where (to summarize), the endpoint, including the user, and the
network agree on what will be shared during an assessment and then the
network bases an access control decision on that assessment.
Therefore, people with privacy concerns don't expose information and
the network operator enforces local policy.

Does that mean there may be cases where endpoints aren't allowed
access? Sure does, but privacy, like access, has it's price.

---

From: "todd glassey" <[email-masked]>
Date: Wed, 15 Nov 2006 10:14:59 -0800

SNIP -

> far beyond that which is reasonable.

Kieth - "Is Reasonable" is an objective term & what you forgot to add is
this:

"Is reasonable by my way of thinking"... something that may not be shared by
all here.

> > willing to disclose and to whom.

Funny Kieth I suggested exactly this two plus years ago as part of a policy
negotiation framework inside PKIX and an integrity suite to implement it,
which Stephen Kent and others slammed me to the mat for suggesting again and
again... funny that eh?

> > The network should have a policy

yes and that policy needs to be electronically negotiable to end-nodes that
are connecting to its Extranets or Intranet services.

> > The requirement for
> > privacy concerns inherent in this system,

Not inherent in, but rather "Security and Privacy Concerns pertaing to that
systems operation". Remember that the Privacy Concerns are not controlled by
the IETF but rather by global courts and national legislation. So the IETF's
play is not to 'pronounce something private' but rather to build processes
that can be used to implement paperless processes where there is an inherent
or built-in level of privacy specific to those law's requirements.

> > describe how those concerns
> > want.

> >Then the endpoint and network owners can configure their
> > policies with confidence.

yes. This was the whole point of the Policy Communication Protocol I
proposed to PKIX.

> > One endpoint owner may disable NEA. Another
> > ISP".

NEA could easily be tied to DHCP to prevent the installation of a lease or
in infrastructure to prevent the routing of those 'bad' or 'unquialified'
connections.

> > Others may decide to disclose OS patch info to their corporate

But the NEA has nothing to do with users. Its a set of tools to demonstrate
the continuing integrity of the systems its layered on. Its not setup (the
NEA) to serve the individual but rather that individual's computer or
workstation as a managed entity in a larger framework.

> This makes them vulnerable to invasion of privacy -

So you offer here to protect the world from what? how technical things are?
really?

> NEA approach, and a very different approach is needed.

For what - ?
    a)    Communicating policy requirements and agreeing to participate
under those terms?
    b)    For continuously analysing those systems under management and
reporting on their operational integrity? i.e. are the policies met... ; and
    c)    For raising some alarm if some stateful variable changes outside
of its policy controls?

My take is that there is a solution to the NEA approach,  the problem is in
understanding what each of the NEA flavors or 'agent-services' are to do.
One use is clearly for security, one is for configuration management, one is
for tracking use, one is for 'QoS'... etc etc etc.

so what you really want is the 'anything and everything' daemon and protocol
for it.

Again - I proposed this type of tool sometime ago in my model, but I looked
at implementing the policy control framework on a dat-0centric model that
was based on bottom-up operations. So for me the first step in this is not
in a top-level tool set but in integrating Syslog, NTP, and DNS into the
same shell or framework.

Once the messaging and event tracking system is seamless - then the addition
of the policy controls of NEA make sense to me as an Auditor.

> doesn't solve the problem.

Which problem? Is that the problem that the end-users are naive?

---

From: Keith Moore <[email-masked]>
Date: Wed, 15 Nov 2006 15:46:11 -0500

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

> right within local laws to ask what ever they want. 

no they do not.  I don't know where you get this idea, and I don't know 
why in the world you think IETF should bless any means to implement 
this.  Nor do I understand why you think such a thing would ever meet 
the rfc 2026 requirements for standardization or get rough consensus 
from this community.

we're here to do what's best for the Internet as a whole, not to build a 
surveillance mechanism to let networks spy on users.  doing so is 
completely unacceptable.  if that's what the WG thinks it's chartered to 
do, then the group should be shut down right now and stop wasting 
everyone's time.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 15 Nov 2006 15:47:18 -0500

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

> the response.

I already pointed out that the protocol would have to prevent this somehow.

> the network operator enforces local policy.

unacceptable, for reasons already given.

Keith

---

From: Frank Yeh Jr <[email-masked]>
Date: Wed, 15 Nov 2006 17:15:19 -0800

Greetings,

      IMHO this discussion of whether the protocol will enable invasion of
user's privacy is a non-sequiter.

      First of all, the NEA protocol is intended to allow the network to
transport data between two endpoints on the network with one of these being
a host and one of them being a server that will make the decision on what
level of access to give to the host. Then the server also has a means to
communicate with the network to tell it what access to allow the host and
potentially a way to remediate "violations" to policy so that subsequent
attempts at access can be allowed. Saying that the user information is
exposed to the network is actually

      There is nothing in the protocol that states WHAT the data being
transmitted between the endpoints will be, that is going to be application
specific. As Keith Moore pointed out earlier with his cookie example, just
because a protocol is designed for one thing does not mean that it will not
be used for other purposes. So what the protocol will do is allow a server
to ask a host for ANY conceivable set of data from that host and allow this
whole communication to happen in a secure network tunnel. With 802.1x as
the Layer 2 protocol, the host does not have to have layer 3 connectivity
to participate in this conversation. To me, this is the value of the
protocol. What people will say using it and what decisions they will make
based on what is said are completely beyond the scope of the protocol.

      Saying that we are going to provide a tunnel for endpoints to
communicate with each other over a standard protocol says nothing about
what the content will be, what decisions will be made based on what data,
or anything other than the fact that there is a channel for communications.

      So if the IETF does not support any protocols that could potentially
be used to transmit sensitive user data to others with or without that
user's knowledge or assent, then perhaps IP should be elilminated as it too
allows for the invasion of user's privacy. HTTP_ check, let's eliminate
that too. SSH or SSL? Those are secure but they do allow user's private
information to be transmitted across that secure tunnel to another endpoint
so guess we'd better eliminate those too.

      Ooops, sarcasm now off.

      Consider that several successive access attempts, with remediation
sessions in between, can occur before a host gets admitted to a network.
The first thing checked can be whether the host is trying to comply to the
right policy, and the first remediation pass can update the policy to the
desired one. There is also nothing to say that you could not specify
several different policies, each with different requirements and different
levels of network access based on compliance to them. So a user could get
challenged and select which policy he wanted to comply with based on the
leve l of access he desired, select the policy, get automatically
remediated to comply with the selected policy and then be assigned the
level of access indicated by the selected policy. It then becomes the
user's choice about what he wants to reveal.

      In my personal experience, you will end up with users plugging in and
being redirected to something that says that they agree with some sort of
text that specifies the terms of their network access. They will then
accept the EULA and that will eliminate any privacy issues for the network
owner. Of course, they will simply click on the EULA without reading it so
they might unknowingly be agreeing to disclosing more than they want to.

      I'd like the user experience to look something like this:

-     User plugs into the network and is authenticated and assessed. Users
are redirected to a web page that shows them the different levels of access
they can select, what access levels are required for various purposes, and
the privacy implications of selecting the various levels. When they select
a level, the must agree to a EULA that says they understand the privacy
implications of their decision.
-     Once the user selects a level, that defines the policy requirements
and then the iterative process of remediating and reassessment begins.
-     Once the user is compliant to the selected level of policy, they are
admitted and their access level is indicated.

      The user could go to an entirely different network and have to comply
with a different set of policies. He should have the option at either
network to select what he wants to disclose based on what he wants to
access.

      This is not perfect but it is significantly better than what is
currently available.

      BTW, I'd like a little more clarification as to why you think that
network owners do not have the right to ask their users anything that
locally applicable rules allow. The IETF does not dictate privacy laws. A
number of organizations sign contracts with labor unions tha say that they
cannot do things like monitor hosts to check on an employee's productivity
or attendance. They are then legally and contractually obligated to protect
that level of privacy. So if there is no applicable law and no contract
that prevents the network owner from doing so, what is it that you think
says they do not have the right?

Regards,
Frank Yeh

---

From: Keith Moore <[email-masked]>
Date: Thu, 16 Nov 2006 09:02:04 -0500

> user's privacy is a non-sequiter.

I don't think that word means what you think it means.

> transport data between two endpoints on the network with one of these
>  being a host and one of them being a server that will make the 
> decision on what level of access to give to the host. Then the server
>  also has a means to communicate with the network to tell it what 
> access to allow the host and potentially a way to remediate 
> "violations" to policy so that subsequent attempts at access can be 
> allowed. Saying that the user information is exposed to the network 
> is actually

Not sure where you were going here...

> transmitted between the endpoints will be, that is going to be 
> application specific.

Well, the protocol doesn't exist yet, and we're trying to determine
requirements for that protocol, and a necessary part of determining
requirements is to consider security issues, including privacy issues.
Clearly a consideration of privacy issues involves a discussion of WHAT
the data being transmitted between the endpoints can be.  There is an
inherent conflict between the need to provide some privacy protection
for the user and the (IMHO naive) desire to make this protocol
arbitrarily flexible for the benefit of the network operator.

> As Keith Moore pointed out earlier with his cookie example, just 
> because a protocol is designed for one thing does not mean that it 
> will not be used for other purposes. So what the protocol will do is 
> allow a server to ask a host for ANY conceivable set of data from 
> that host and allow this whole communication to happen in a secure 
> network tunnel.

This does not follow, and if the NEA group were to try to define the
protocol in that way, IMHO it would be extremely unlikely to gain IETF
consensus and subsequent standardization.  That and if I were on IESG
(I'm not) the failure of the NEA group to adequately consider privacy in
its requirements would be a clear indicator that the group should be
shut down rather than be allowed to have its charter extended to
actually develop the protocol under discussion.  Finally the failure to
consider what is best for the Internet as a whole is a violation of IETF
process which should make the group's work vulnerable to being
overturned on appeal.

> With 802.1x as the Layer 2 protocol, the host does not have to have
> layer 3 connectivity to participate in this conversation. To me, this
> is the value of the protocol. What people will say using it and what
> decisions they will make based on what is said are completely beyond
> the scope of the protocol.

Strongly disagree.  The entire purpose of a requirements discussion is 
to narrow the potential solution space and scope of the protocol.

> communicate with each other over a standard protocol says nothing 
> about what the content will be, what decisions will be made based on 
> what data, or anything other than the fact that there is a channel 
> for communications.

That would be true if that were what we were doing.  But we're not doing 
that.

> be used to transmit sensitive user data to others with or without 
> that user's knowledge or assent, then perhaps IP should be 
> elilminated as it too allows for the invasion of user's privacy. 
> HTTP_ check, let's eliminate that too. SSH or SSL? Those are secure 
> but they do allow user's private information to be transmitted across
>  that secure tunnel to another endpoint so guess we'd better
> eliminate those too.

Nope.  See, the entire point of ssh (to give an example) is to allow 
authorized users to be able to run commands under their account on the 
server machine.  ssh users are aware of this purpose, and act 
accordingly.  They don't enable ssh on their machines unless they want 
authorized users to be able to log in to their accounts over the network.

OTOH, the entire point of NEA is to allow networks to determine whether 
a host is safe to connect to the network, NOT to allow networks to 
conduct espionage on hosts that connect to their networks.

> sessions in between, can occur before a host gets admitted to a 
> network. The first thing checked can be whether the host is trying to
>  comply to the right policy, and the first remediation pass can
> update the policy to the desired one. There is also nothing to say
> that you could not specify several different policies, each with
> different requirements and different levels of network access based
> on compliance to them. So a user could get challenged and select
> which policy he wanted to comply with based on the leve l of access
> he desired, select the policy, get automatically remediated to comply
>  with the selected policy and then be assigned the level of access 
> indicated by the selected policy. It then becomes the user's choice 
> about what he wants to reveal.
> 
>  being redirected to something that says that they agree with some 
> sort of text that specifies the terms of their network access. They 
> will then accept the EULA and that will eliminate any privacy issues 
> for the network owner. 

But the network owner is not the only party whose interests need to be 
considered.

> I'd like the user experience to look something like this:

[deleted]

I don't see any reason why IETF should endorse a protocol that (a)
allows network providers to conduct arbitrarily surveillance of hosts 
and (b) trusts network providers to be honest about what kinds of 
surveillance users are being subjected to.   That's completely insecure.

>  with a different set of policies. He should have the option at 
> either network to select what he wants to disclose based on what he 
> wants to access.

I do not accept the argument that users will have adequate choice of 
networks to which to connect.  Faith in market forces to solve these 
problems is, in general, misguided.  In my experience that kind of 
argument is usually used as an excuse to justify deliberately creating a 
condition where consumers' interests are harmed.  An IETF working group 
should not be trying to create market conditions that favor network 
providers' interests over those of consumers.  And I don't think you'll 
be able to get community consensus to do that, especially not after 
various privacy groups get wind of what some people here are trying to do.

>  locally applicable rules allow. 

I'd like more clarification as to why you think that they do.  But 
that's not what's relevant.  What's relevant is why the IETF should 
endorse a protocol that allows networks to ask arbitrary questions of 
hosts, and in effect, to conduct surveillance of the internal state of 
those hosts - when such a protocol is clearly harmful to users' interests.

Keith

---

From: Douglas Otis <[email-masked]>
Date: Thu, 16 Nov 2006 12:10:20 -0800

On Nov 14, 2006, at 10:20 PM, Keith Moore wrote:

> regarding NEA: what I might be okay with is giving authorized third- 
> parties yes or no assurance that the host meets or does not meet  
> their policies, without giving them fine-grained detail about what  
> is installed on the host.

Certificates obtained from third-party services can meet this  
requirement.  These third-party services might be as simple as a web- 
site and agreeing to the AUP.  Clicking yes presents the time-stamped  
NEA certificate that is placed into the NEA repository.  The NEA  
repository should permit profiles where the user can limit which  
certificates can be seen by specific NEA servers.  This approach  
replaces modifications to DNS redirecting browsers to a specific web  
page, for example.  Not all systems will be using a browser or be  
used directly by a human.

When a provider detects malicious activity, some type of non-optional  
compliance requirement might be instantiated.  Limiting access to  
bots better ensures more draconian measures are not taken.  The  
market place of access providers is not exceedingly diverse, where I  
share some of your concerns regarding how NEA might be misused.  The  
number of systems running a cloned corporate version of Windows  
unable to apply patches is placing the network at risk.  How is that  
problem best addressed?

It seems a good method for dealing with this problem is to enable a  
means for dealing with bots in an automated fashion.  There is simply  
little a provider will do to help customers restore their pirated  
OS.  Asking for evidence of remediation from an array of third- 
parties selected by these users seems to be one such approach.  When  
there is a compliance failure, the user should be offered a list of  
choices, and not automated by default.  The provider can indicate the  
services they consider acceptable by presenting their version of the  
certificates with their hostmaster@ id.

> so the owner of a host could get details about why a host did or  
> did not fit within a particular network's policy, but the network  
> (if owned by another party than the owner of the host) could only  
> get yes or no information.   I would like to see this option  
> examined further.

The only information that might be available could be limited to  
which certs were presented together with their time-stamp.

-Doug

---

From: "Sean Convery" <[email-masked]>
Date: Thu, 16 Nov 2006 16:25:06 -0800

Hi Keith,

> surveillance users are being subjected to.   That's completely insecure.

I agree with your privacy concerns and your point that managed assets
of an organization will connect to networks that aren't managed by the
organization. This means we can't just assume a company X asset will
only connect to a company X network.

As you know, there are a host of techniques on the Internet today
which farm information from unsuspecting users and you are right to
point out that NEA is potentially a new one. Pop-ups to authorize such
queries are certainly not ideal by themselves. I am concerned that
users will tend to just click "yes" much like they do today when
connecting to a web site with an invalid certificate. However, I
fundamentally believe in the benefit NEA provides to organizations.

When I think of your objections while reading through this long
thread, I'm reminded of Bill Joy's essay "Why the Future Doesn't Need
Us." In it, he says, "The only realistic alternative I see is
relinquishment: to limit development of the technologies that are too
dangerous, by limiting our pursuit of certain kinds of knowledge."

This is an ultimately unsatisfying conclusion and Joy himself admits
as much towards the end of the essay when he writes "I'm trying to
imagine some better answers..."

What NEA is dealing with is nowhere near the magnitude of
self-replicating nano-machines and the other things Joy was concerned
with but that doesn't mean we should dismiss NEA's privacy concerns.
For me the question should be, "How do we sufficiently protect the
organization and end user from disclosing information that would be
harmful to them?"

I'm unwilling to cede NEA because we think a user prompt will simply
be bypassed. We're smart folks, I'm sure we can think of something.
Bringing this around to the requirements, I think Khaja's amendment to
your requirement seems reasonable: (NEA MUST NOT expose information
about a host to any party other than the owner of that host or to
parties authorized by the owner.)

Ensuring that the user and owner are sufficiently aware of the risk in
disclosure seems to fall into the realm of implementation. This sounds
very much like the work Kim Cameron and co. are doing with infocards
by providing ways for users to choose the profile of identity
information they are willing to provide. Can you think of a better way
to represent this requirement which still allows hosts to connect to
multiple networks?

What is happening in the marketplace today in the absence of standards
is downloadable ActiveX controls are being embedded within captive
portals at network login. In order to connect to a network you have to
agree to install this applet which scans your system for compliance.
In this situation you have no controls over what information is
provided. This is clearly bad. Standards would at least give the user
control over the client element and could configure it to disclose
only what they wanted to.

One option down the road is federation. Imagine a company X asset
connects to a company X network and gets a normal scan done: nothing
which violates your original requirement. Then at the end the asset is
provided with a certificate signed by company X stating that the
machine is running the latest patch, latest AV file, etc, whatever
company X is comfortable providing within the certificate. Then when
that asset connects to company Y's network it is authorized to present
the certificate only (which might not even list the specific AV
vendor, just that it is current). No additional information can be
sent regardless of what the user is willing to consent to. Then if X
and Y trust each other's assessments they are done.

I realize this isn't ideal, but it tries to address your concern
around novice users. I'm sure there are other ideas out there.

Thanks,

Sean

Off topic: If there are folks on the list who haven't read Bill Joy's
essay it was in Wired 8.04 and I highly recommend it:
http://www.wired.com/wired/archive/8.04/joy.html

---

From: Keith Moore <[email-masked]>
Date: Thu, 16 Nov 2006 19:58:50 -0500

Sean,

thanks for the thoughtful and detailed comments.

on reading your message I realize that trying to lump both the privacy
concerns and the user interface/user naivete concerns into a single
requirement potentially makes that single requirement overbroad and
glosses over important issues that need more detailed examination.

so I'm thinking that it should be separated along something like these
lines:

- the protocol MUST NOT release information about a host to third
parties (other than the owner) absent explicit consent by both the owner
and user to release that information to each specific party
- owners and users MUST have explicit control over the kinds of
information disclosed to third parties
- owners and users MUST be able to control the information which is
allowed to be released on a per-party basis
- owners and users MUST be able to revoke or alter previously-granted
consent
- the model by which owners and users consent to release of information
MUST be easily understood by ordinary users.  (note here that either
too-fine-grained control or too-coarse-grained control can thwart
understanding)

(MUST is probably a bit overused above, but I don't feel like doing much
much wordsmithing at present - I'm mostly trying to identify the areas
of concern.)

I don't think I agree that "Ensuring that the user and owner are
sufficiently aware of the risk in disclosure seems to fall into the
realm of implementation."  implementation clearly plays a role, but so 
does protocol design - at least in the selection of questions that a 
network can ask of a host.  I am increasingly skeptical that this can be 
done, especially if the questions that a network can ask are 
implementation specific.  I'm also skeptical that implementors can be 
trusted with presenting users with a clear picture of the risks they are 
taking - particularly when some implementors will probably have a 
conflict of interest there (say if a particular NEA implementor also 
sells other software and it wants to levy its NEA implementations to 
make sure that such software hasn't been patched, it's licenses are paid 
up, etc.) .

> This sounds very much like the work Kim Cameron and co. are doing with infocards 
> information they are willing to provide. Can you think of a better
> way to represent this requirement which still allows hosts to connect
> to multiple networks?

something like profiles is probably what is needed in order to make this 
simple enough for users to understand.

> which violates your original requirement. Then at the end the asset
> is provided with a certificate signed by company X stating that the 
> that asset connects to company Y's network it is authorized to
> present the certificate only (which might not even list the specific
> AV vendor, just that it is current). No additional information can be

worth further investigation, I think.

thanks again,

Keith

---

From: Frank Yeh Jr <[email-masked]>
Date: Thu, 16 Nov 2006 19:05:54 -0800

Greetings,

> make sure that such software hasn't been patched, it's licenses are paid

      I'm still perplexed as to why you word things as if the network is
asking the host for anything other than  the normal sort of information
that is used to establish network connections. This is all the the network
will be doing as far as direct communication with the host. The sensitive
information will, by design, be opaque to the network and only visible to a
validation server on the other end of the tunnel. This server will have a
way to communicate what access level to give to the host and a way to send
the host someplace to find out what happened and what to do next. That is
about the extent of the network's involvement.

      Okay, got that bit of irrelevance off my chest. The owner of the
network and the validation server will be the same in most cases, so access
to that information is the point and knowledge by the user of what is being
disclosed is important. I still maintain that the content of what is
transported by the network in a secure tunnel that is designed to protect
that content is not the business of the network doing the transporting. It
is a Layer 7 and above thing. There are all sorts of standard protocols
that could be used to transport private information, but there is a binary
difference in them based on the user's knowledge of what is being
transported. FTP and TELNET are voluntary, cookies are stealthy. FTP good,
cookies bad.

      So here's how stuff works in a lot of enterprises now. You have to
install the client software and there is a EULA that you agree to. You sign
an agreement to follow the policies and guidelines of the company. The
company owns the laptop you are using. When you plug in to the network that
the company owns, the client software automatically learns of any new
policy changes. You can see what the data being collected is if you want to
take the trouble to look. If you are not in compliance, you get a popup
telling you to fix it and if you don't, after a period of time your manager
gets emailed. There is no network enforcement yet, but all of the rest of
it is already being done. We have boatloads of lawyers who look at this
stuff all the time, so legally I figure this is a precedent.

      Now let's add in network enforcement. We are already transporting the
data so all we are adding is the ability to constrain network access based
on what is found. I guess what we are asking is does the network want to be
an accomplice to this sort of thing? There are already proprietary ways of
doing the network enforcement thing on top of everything else. Cisco's NAC,
MicroSoft's NAP, TCG's TNC give people a way to do this now or in the near
future. IMHO this situation would benefit from an IETF standard.

      So let's look for some middle ground. I'm hoping that you'll accept
for the sake of argument that the network cannot prevent people from doing
what you fear will be done_ invading other people's privacy to some extent.
If the network were to take an active part in doing the endpoint assessment
it might be able to better control what was being disclosed. A reasonable
example would be SNMP, where the types of data to be transported are
registered in MIBs. If there were a way to define a sort if MIB structure
to define the types of assessment data being transmitted and nothing that
was not registered could be transmitted, would that provide a better means
of control? This is outside the scope of the existing non-standard
protocols and probably outside of the charter but would it make people with
your perspective more comfortable with the idea?

      Would it be better if all of the data was analyzed on the client and
only a status was returned to the server? This is done today by some
solutions but you then run into the problem of trusting the client's
evaluation, which it turns out is better if you can protect the client with
trusted hardware. Even if all the data itself is transported, you still
have to establish trust in the client to trust the data so the status is
simpler and just as valid. In this model, the policy is sent to the client
and includes the requirements and information on how to achieve compliance.
The client evalautes itself and uses the information to get into a
compliant state before re-attempting access. Again, this is just how our
application works and it is completely outside of the scope of the
non-standard protocols we are discussing. We just liked the fact that the
validation load was distributed on the clients rather than the server for
things like black tuesdays.

> simple enough for users to understand.

      I agree. EULA's suck.

> >  and Y trust each other's assessments they are done.

      In a recent survey of fortune 500 CIO's, one response to the question
"what keeps you awake at night" was "fraud in the supply chain". Federation
is valuable and slowly happening, but how does federation help you with
your own users? You have to establish trust with them before you hand them
off to a partner who is trusting you. Wouldn't it be nice to say that the
host being handed off is known to have the latest patches and virus updates
and has scanned for viruses today? Wouldn't it be nice to demand this of
hosts being handed off to you?

> worth further investigation, I think.

      If you really feel that this protocol should dictate what content is
transported between the endpoints then I think that would be a change in
charter.

Regards,
Frank Yeh
Corporate Security Strategy Team
IBM
Tivoli Software

---

From: Keith Moore <[email-masked]>
Date: Thu, 16 Nov 2006 23:11:36 -0500

> asking the host for anything other than  the normal sort of
> information that is used to establish network connections.

because it's clear to me that some kinds of networks have
incentives to ask hosts for other kinds of information that users would
not want to divulge, and that if NEA provides them with such a
mechanism, they'll use it.

after all, the "normal sort of information...used to establish network
connections"  didn't used to require any information about the host at
all - it was just user authentication provided by the host to the
network and IP address, netmask, etc. provided back to the host.  what 
is considered "normal" has changed over time to be more intrusive. who 
is to say what network admins will consider "normal" in the future if
they're given mechanisms that allow them to ask hosts arbitrary things?

> This is all the the network will be doing as far as direct
> communication with the host. The sensitive information will, by
> design, be opaque to the network and only visible to a validation
> server on the other end of the tunnel. This server will have a way to
> communicate what access level to give to the host and a way to send
> the host someplace to find out what happened and what to do next.
> That is about the extent of the network's involvement.

anytime information about the host is exposed, whether to a network or a
validation server controlled by a third-party, I'm concerned about the
potential for misuse of that information.  you can't just assume that
the information won't be misused - you have to do threat analysis.

> install the client software and there is a EULA that you agree to.
> You sign an agreement to follow the policies and guidelines of the
> company. The company owns the laptop you are using. When you plug in
> to the network that the company owns, the client software
> automatically learns of any new policy changes. You can see what the
> data being collected is if you want to take the trouble to look. If
> you are not in compliance, you get a popup telling you to fix it and
> if you don't, after a period of time your manager gets emailed. There
> is no network enforcement yet, but all of the rest of it is already
> being done. We have boatloads of lawyers who look at this stuff all
> the time, so legally I figure this is a precedent.

legality isn't the issue.  the issue is whether NEA is something that
IETF can recommend as being good for the Internet.  there's a big
difference between what is generally beneficial and what is legal.

>  data so all we are adding is the ability to constrain network access
>  based on what is found.

who is "we"?  IETF doesn't have a protocol to do this yet, so IETF is
not already transporting this data.  IETF is looking at how to design a
new protocol to do this job.  It's naive to assume that existing
protocols that weren't designed with due consideration of user privacy
or other security issues can be tweaked to solve those problems.  (yes,
the charter does assume this, and yes, the charter is naive...but it
hardly matters because the group will have to be rechartered in light of
the requirements that get developed before it does actual protocol
design anyway)

> for the sake of argument that the network cannot prevent people from
> doing what you fear will be done_ invading other people's privacy to
> some extent. If the network were to take an active part in doing the
> endpoint assessment it might be able to better control what was being
> disclosed.

I don't expect the network to be acting on behalf of the user - I think
it's much more likely that there is a conflict between the interests of
the network operator and the interests of the user.  So I don't think
the network can be trusted to protect the user's interests.  Indeed, the
scenarios I've been looking at are ones where the network has an
interest in violating the user's privacy.

> A reasonable example would be SNMP, where the types of data to be 
> transported are registered in MIBs. If there were a way to define a
> sort if MIB structure to define the types of assessment data being 
> transmitted and nothing that was not registered could be transmitted,
>  would that provide a better means of control? This is outside the
> scope of the existing non-standard protocols and probably outside of
> the charter but would it make people with your perspective more
> comfortable with the idea?

I'm not sure, but I've been asking myself a similar question.

>  only a status was returned to the server?

another question I've been asking myself.

> This is done today by some  solutions but you then run into the
> problem of trusting the client's evaluation, which it turns out is
> better if you can protect the client with trusted hardware. Even if
> all the data itself is transported, you still have to establish trust
> in the client to trust the data so the status is simpler and just as
> valid.

this might be an aside, but pragmatically I'm not sure you can ever rely 
100% on a client's evaluation of anything.

consider two cases:

in case A a client is running an OS natively, and an NEA client under
that OS.  the NEA client looks at the host configuration and reports to
the server whether that configuration conforms to policy.

case B is like case A except that the OS is running under a virtualizer.
the NEA client still runs under that OS, but it can only see the
configuration of its virtual machine - and it thinks that it sees the
entire machine.  it reports to the server the same result as in case A.
however the machine is actually running other guest OSes that also
share the same network interface as the one that reported NEA
results....so the NEA results are fairly meaningless.

now if you really constrain the kind of hardware that is used on your
network you might be able to get around that problem, but I think that
in practice it will be difficult to impose those constraints in most
environments.

> In this model, the policy is sent to the client and includes the
> requirements and information on how to achieve compliance. The client
> evalautes itself and uses the information to get into a compliant
> state before re-attempting access. Again, this is just how our
> non-standard protocols we are discussing. We just liked the fact that
> the validation load was distributed on the clients rather than the
> server for things like black tuesdays.

makes sense.

>  transported between the endpoints then I think that would be a
> change in charter.

I think that imposing limitations on what kinds of content can be 
transported is something that should be investigated as a way to address 
the privacy issues.  As for the charter, there are lots of things in the 
current charter that I think are naive or inappropriate, but as these 
are common problems in IETF charters I don't think we need to hash them 
out here. The main thing, IMHO, is that right now we're just developing 
requirements (which I wish they had called "design goals and 
requirements").  If we end up with requirements that conflict with other 
assumptions in the charter, the charter will need to be changed, but 
that's not such a big deal as the charter has to be changed anyway to 
allow this WG to progress past the requirements definition stage.

Keith

---

From: "Darryl \(Dassa\) Lynch" <[email-masked]>
Date: Sat, 18 Nov 2006 09:45:47 +1100

Keith Moore wrote:
>> incentives to ask hosts for other kinds of information that
>> users would not want to divulge, and that if NEA provides
>> them with such a mechanism, they'll use it.

Could a solution to this concern be one of the first attributes exchanged
with NEA being to define if the connecting node is owned/controlled by the
network owner and following allowed attributes are defined by this.  So, if
the connecting node is not controlled by the network owner only a subset of
attributes will be available but if it is controlled by the network owner
then the full set of attributes will be exposed.

Darryl (Dassa) Lynch

---

From: Douglas Otis <[email-masked]>
Date: Fri, 17 Nov 2006 16:47:50 -0800

On Nov 17, 2006, at 2:45 PM, Darryl ((Dassa)) Lynch wrote:

>>> incentives to ask hosts for other kinds of information that users  
>>> would not want to divulge, and that if NEA provides them with  
>>> such a mechanism, they'll use it.
>
> Could a solution to this concern be one of the first attributes  
> exchanged with NEA being to define if the connecting node is owned/ 
> controlled by the network owner and following allowed attributes  
> are defined by this.  So, if the connecting node is not controlled  
> by the network owner only a subset of attributes will be available  
> but if it is controlled by the network owner then the full set of  
> attributes will be exposed.

If what is being asked are sets of certs identified with  
[email-masked], then the client is always able to profile  
which matching certs are provided, and decide which certs might be  
obtained.  The certs offered by the provider contains the resources  
needed by the client to obtain their version of the provider's  
desired cert.

The type of service needs to be acceptable to both the client and the  
server.

1) Can this NEA process be abused?  Yes.

2) Is the network being abused already by compromised clients?  Yes.

3) Does this NEA process provide a means to facilitate remediation?   
Yes.

4) Does this NEA process provide a means to prevent exploits before  
requisite services are obtained?  Yes.

5) Does this provide better guidance to users of which services are  
trustworthy?  Yes.

6) Does the use of third-parties and certs with a time-stamp offer  
privacy?  Depends.

Currently most obtain security updates for their software.  This can  
not be done without indicating what software is being used.  When  
scanning or scrubbing services are required, this too can not be done  
without indicating what software is being used.  The latest trusted  
computing model can also indicates what hardware and drivers are  
being used to prevent root kits and some types of virtualization from  
not being detected.  This would be a trade-off between the devil you  
know and the one you don't.

Will Keith still be able to find a provider that asks for only  
friendly certs?  Don't know.

This could be a matter of public policy as with anything of this  
nature.  Technology often gets ahead of regulation.  Waiting for the  
next crisis before any level of controls are instantiated is not  
likely to improve upon Keith's freedoms and privacy.

-Doug

---

From: Frank Yeh Jr <[email-masked]>
Date: Fri, 17 Nov 2006 19:05:08 -0800

Greetings,

> mechanism, they'll use it.

      I'm not sure we define "network" in exactly the same way, but since
the point is invasion of privacy, it doesn't really matter for this
discussion.

> they're given mechanisms that allow them to ask hosts arbitrary things?

      Fair enough.

> the information won't be misused - you have to do threat analysis.

      I admire this sort of thinking and agree to a point. The problem is
that you cannot define, categorize and control everything nor would you
want to and granularity must be balanced against value and performance.

> difference between what is generally beneficial and what is legal.

      AHA! So legality is not the issue but what's good for the internet
is... how liberating! So perhaps another way of looking at this is in the
light of the existing proprietary standards. Since there are already
generally available protocols to do this sort of thing, can we consider
whether having a standard as opposed to multiple non-standard protocols is
good for the internet?

> new protocol to do this job.

      We is the people using the non-standard protocols or doing compliance
checking without network enforcement.

> It's naive to assume that existing

      I see the protocol as protecting that data during transport and am
still uncomfortable with trying to dictate what is done with data once it
leaves the network. This sort of data is already being transported using
existing protocols, often in a somewhat less secure fashion than the
protocol would enable. If we start here, where do we stop?

> interest in violating the user's privacy.

      Semantics on "network" failing here. I see the network being
prevented from seeing data that is going to be transported between
network-attached devices. Network owner and endpoint owner might not be the
same.

> 100% on a client's evaluation of anything.

      Boy is THAT a different thread. Trusted Hardware says otherwise but
pragmatic experience says anything can be defeated somehow.

> results....so the NEA results are fairly meaningless.

      Hmmm... all the virtual machines I work with assign different unique
virtual MAC Addresses to their virtual interfaces so they can co-exist on a
LAN. They just look like multiple hosts on a hub to the network. Since we
can constrain traffic per IP, and each virtual host has a separate IP, the
real or virtual hosts each have to be in compliance and traffic can be
selectively filtered for those not in compliance. Multiple hosts connected
behind a NAT-device that is then attached to a NEA-enabled port might be a
better scenario. VM's can be configured this way and in this scenario the
host has to be compliant but the NAT'ed VM's could probably .

> in practice it will be difficult to impose those constraints in most

      And much harder to constrain the use of pure software VM's. But we
don't have to be perfect, just add value. This protocol really has more
value in keeping honest people from being duped into commiting dishonest
acts than about not being defeatable.

> the privacy issues.

      Is this a fundamental thing with all IETF protocols? It just seems
like a very idealistic but unrealistic thing to try to do. With or without
user consent, private data is being transmitted using just about every
existing network protocol imaginable. Is this a case of the genie being out
of the bottle or is NEA a different threat level for you?

> As for the charter, there are lots of things in the

      That is comforting!

Regards,
Frank Yeh