Re: [Nea] privacy: exposing information to owner

[Keith Moore <moore at cs.utk.edu>]

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

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.

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

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.

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

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)

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

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.

> Would it be better if all of the data was analyzed on the client and
>  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
> 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.

makes sense.

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

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

_______________________________________________
Nea mailing list
Nea at ietf.org
https://www1.ietf.org/mailman/listinfo/nea