Re: [Nea] privacy: exposing information to owner

[Frank Yeh Jr <fyeh at us.ibm.com>]

Greetings,

Keith Moore <moore at cs.utk.edu> wrote on 11/16/2006 04:58:50 PM:

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

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.

> > 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?
>
> something like profiles is probably what is needed in order to make this
> simple enough for users to understand.
>

I agree. EULA's suck.

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

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.
>
> thanks again,
>
> Keith
>
>

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

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